0 NAT/Firewall NSLP IETF 62th – March 2005 draft-ietf-nsis-nslp-natfw-05.txt Martin Stiemerling, Hannes Tschofenig, Cedric Aoun

1 IPR Claim Received IPR claim of Nortel December 14th Nortel Networks U.S. Patent No. 6,772,210, entitled "Method and apparatus for exchanging communications between telephone number based devices in an internet protocol environment", may contain claims that are believed may be necessary for practicing the resulting IETF Standard based on this Internet Draft. Claim is here  We are not lawyers, but there MAY be prior art!

2 Editorial Changes in -05 Several editorial changes  Moved Miquel to the author’s list in the text body  Integrated many comments from Elwyn Merged Query message into a single section  Was Section and Aligned object format presentation to GIMPS I-D Added in Section 3.5 the compatibility bits described in GIMPS  NATFW NSLP limits usage to MANDATORY, OPTIONAL, FORWARD  REFRESH bit combination not used, NFs do not refresh on their own

3 Editorial Changes in -05 Changed Response Type Object to Proxy Support Object Removed scoping object (not needed anywhere) NOTIFY (per WG decision – IETF 61)  Removed NOTIFY target object  NOTIFY messages are sent upstream only (Section 3.3.5) Added appendix on "Object ID allocation for testing" Added text about how REA is activated to Section Updated security considerations

4 Security Consideration Section Update Resolved remaining issues in the NAT/FW threats document  see mailing list, data receiver behind a NAT NAT/FW threats document incorporated into main document  Was draft-fessi-nsis-natfw-threats-02 Updated threat model and security solution text  GIMPS security between neighboring NSLP nodes  Usage of authorization tokens  Authentication and authorization of an initiator towards non-neighboring nodes based on CMS Open issues:  Mobility handling and security (based on old I-D)  More details  Security object formats

5 Protocol Changes in -05 Introduced notion of ‘deny’ policy rules Reworked Section and (proxy mode)  Section Proxy Mode for Data Receiver behind NAT  Section Proxy Mode for Data Sender behind Middleboxes  Proxy mode is no longer the default mode (see later) Added DSInfo description to section about REA  Information about data sender  Limit possible CREATE message senders and local filters Since REA incorporates the DSInfo semantics, the TRIGGER message has been removed Added section about finding upstream firewalls (UCREATE)  Section Proxy Mode for Data Receiver behind Firewall More details on next slides...

6 Proxy Mode - NR side Data receiver behind NAT

7 Issues on DR behind NAT Proxy Mode Issues with not using the proxy mode as default  NI+(i.e. NR) needs to know the NATFW NSLP capabilities  Impact on applications as they would need to advertise their NSIS capabilities Proxy mode used and far endhost supports the NSLP how to handle the existing NSLP sessions triggered by the REA?  One created by a CREATE message sent by the Edge NAT  one created by a CREATE message sent by the far endhost’s NI  DR to decide whether the proxy mode signaling session needs to be terminated based on an e2e signaling session.

8 On the Security of Data Receiver behind a NAT Data Sender NAT/ FW Data Receiver Treat the signaling sessions (1) and (2) independently (authorization issue) Do not update state established on the NAT/FW (created by the proxy mode signaling session) based on an e2e signaling session. Proxy mode triggers a CREATE to deal with routing asymmetry and firewalls between the NAT/FW and the DR. (1) End-to-End Signaling (2) Proxy Mode Signaling

9 Proxy Mode - NI side Data sender behind NAT or Firewall

10 Blocking Traffic Proxy Mode for Data Receiver behind Firewall Used to block particular incoming data flows

11 Open Issues Security Details on UCREATE  Protocol details just new  Need review  Multihomed scenarios: several Firewalls parallel There is an issue tracker You can register yourself a the tracker! A diff between -04 and -05 at: