1. NSIS NAT/Firewall NSLP Martin Stiemerling, Hannes Tschofenig, Miquel Martin, Cedric Aoun stiemerling@netlab.nec.de NSIS WG, 59th IETF

2. Content Current Changes in -01  Reorder sections  Mainly editorial changes Stacking Policy rule lifetime handling NATFW reserve address or ‘find the last NAT’

3. Stacking: Problem Alice Bob Trudy NAT1 NATFW2 Sales/HR ISP x NAT3 Max Foo.com Need to avoid this path from being taken NAT Stacking 10.1.2.3 192.168.1.2 137.121.5.8 Preferred Path!!!

4. Stacking Record external addresses at each traversed NAT  Unless it reaches edge NAT  Proposal made during last IETF meeting Alice Bob Trudy NAT1 NATFW2 Sales/HR ISP x NAT 3 Max Foo.com NAT Stacking 10.1.2.3 192.168.1.2 137.121.5.8 1-REA:[10.1.2.3] 2-REA:[10.1.2.3|192.168.1.3] 3-REA:[10.1..2.3|192.168.1.3|137.121.5.8] 4-REA:[10.1..2.3|192.168.1.3|137.121.5..8]

5. Stacking: Pros and Cons Pros  End hosts can (probably) optimise their data flow route  End hosts could learn about NAT location  Actually sort of NAT trace route Cons  Probably reveals topology to users and other hosts  NATFW messages will grow on-path  Each NAT includes its IP addresses  Security problem  malicious NAT may change IP address information of already passed NATs)

6. Policy rule lifetime handling Lifetime is associated to each policy rule  Policy rule removed automatically after lifetime expiration  Soft-state maintenance through prolong message Current: End-to-end lifetime maintenance  NSIS Initiator chooses lifetime  NATFW NSLP can accept or deny complete request, no way of telling acceptable lifetime Planned: End-to-end take what you want  Initiator proposes lifetime  NATFW NSLP may change to proposal to their needs on the way  Initiator can accept or cancel policy rule Create (lt=120min) NSIS Initiator NF/Middlebox NSIS Receiver 12 OK 120min too long Set to 60 min Create (lt=60min) OK

7. Policy Rule Lifetime Handling Current lifetime process  Simple  NI must start trying (polling) to find the right lifetime value  Can result in several create message attempts Propose lifetime process  More parts of the message change (not only flow information changes)  NI gets immediately minimum acceptable lifetime  Probably only one message and middleboxes are configured

8. Find the last NAT NATFW reserves external address message  Reserves IP address/port at most external NAT (edge NAT)  Gives host a chance to receive data originated in public network  Usable for example for SIP (early media) Currently NATFW NSLP is searching for the last NAT  Give NSLP message a target (SIP server) and the last NAT will return public address  Reuse reservation for later create message coming from public network Is it appropriate to let the NSLP find the last NAT?  Reserve message is send to fake target  Reserve message runs opposite way of data to come later Or is it ‘special routing’ better done by the NTLP

9. More Questions or Comments? Thanks.