Transcript PPT Version
NSIS NAT/Firewall NSLP <draft-ietf-nsis-nslp-natfw-01.txt> Martin Stiemerling, Hannes Tschofenig, Miquel Martin, Cedric Aoun [email protected] NSIS WG, 59th IETF Content • Current Changes in -01 Reorder sections Mainly editorial changes • Stacking • Policy rule lifetime handling • NATFW reserve address or ‘find the last NAT’ Stacking: Problem Sales/HR Alice NAT Stacking 137.121.5.8 ISP x 10.1.2.3 NAT1 NATFW2 Trudy Bob Preferred Path!!! Foo.com 192.168.1.2 NAT3 Need to avoid this path from being taken Max Stacking • Record external addresses at each traversed NAT Unless it reaches edge NAT Proposal made during last IETF meeting Sales/HR Alice NAT Stacking 2-REA:[10.1.2.3|192.168.1.3] 4-REA:[10.1..2.3|192.168.1.3|137.121.5..8] 10.1.2.3 1-REA:[10.1.2.3] 137.121.5.8 3-REA:[10.1..2.3|192.168.1.3|137.121.5.8] NAT1 Bob Foo.com ISP x NATFW2 Trudy 192.168.1.2 NAT 3 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) 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 OK Create (lt=120min) 1 NSIS Initiator NF/Middlebox 120min too long Set to 60 min OK Create (lt=60min) 2 NF/Middlebox NSIS Receiver 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 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 More Questions or Comments? Thanks.