1. NATFW NSLP Status draft-ietf-nsis-nslp-natfw-12.txt M. Stiemerling, H. Tschofenig, C. Aoun, and E. Davies stiemerling@netlab.nec.de NSIS Working Group, 66th IETF meeting

2. 3GPP2 and NSIS Network Firewall Configuration & Control Protocol (NFCCP)  "Requirements for Firewall Configuration Protocol” ( draft-bajko-nsis-FW-reqs-04.txt )  Presentation of the NATFW NSLP at the Jan 17th meeting by John  TSG-X, PSN, WG 3.1  Slides are here http://www.stiemerling.org/ietf/nsis/3gpp2/3gpp2_nsis_natfw_overview_final.ppt 3GPP2 WG is in favour of the path-coupled NSIS approach NSIS NATFW NSLP is the NFCCP! Discussion between NATFW NSLP authors and 3GPP2 group are on-going

3. Status draft-ietf-nsis-nslp-natfw-11  After IETF-65 version for WGLC  Received comments editorial & technical draft-ietf-nsis-nslp-natfw-12  First changes after WGLC comments  Mainly editorial changes due to WGLC  Diff is here  http://www.stiemerling.org/ietf/nsis/draft-ietf-nsis-nslp-natfw- 12-diff-to-11.html NATFW issue tracker https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/ https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/

4. Some Issues Who is defining the NSLP object space?  It is not in GIST! Signaling Destination Address (SDA) selection appendix  Quite old  Needs to be reworked  Input is welcome! Terminology issues  NSLP signaling vs. Application signaling  Different “modes”  Signaling exchanges  Etc.

5. REA Naming Contest REA = Reserve External Address (REA) Past: Used to get external address/port at NAT  Name was 100% fit  But semantics changed over time Now:  Used to get external address/port at NAT  Used to install firewall rules for inbound traffic  Used in proxy mode usage Name seems to inappropriate! Need new name but no idea... REA naming contest (reanco)  Starts today July 12th  Runs until August 3rd 8am EST  Send suggestions to NSIS WG mailing list  Prize: Six-pack of local beer at next IETF in San Diego  All legal things apply here: participants must be older than 18 or 21 years (depending on location of IETF and the local laws), no guarantees, not entitled for anything, must be at the next IETF meeting, etc...

6. NAT-PT Support Draft -12 unspecified about NAT-PT usage (RFC 2766). Past revisions had text specifying NAT-PT NAT-PT support has been removed  One of the reasons is http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to- exprmntl-03.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to- exprmntl-03.txt Where to go with NAT-PT support? Overall tendency (list opinion): Do not support NAT-PT  Not really recommended...  There is no known deployment to us. Keep “Remove NAT-PT”.

7. DTINFO Issues Carries additional information for REA  Port numbers  Transport protocol  Basically all things not in the LE-MRM DTINFO_IPv4 ambiguity issues  Usage not fully specified  Editorial changes needed DTINFO_IPv4 MAY be included  But required in many cases (above 50%)  Change to MUST and wildcard fields (if needed)

8. DTINFO_IPv6 DTINFO_IPv6 was removed  Same as DTINFO_IPv4  Removed due to removal of NAT-PT support  Caused confusion DTINFO_IPv6 could be used for back-to- back NAT-PT: Proposal: Keep removed.

9. TRACE Semantics TRACE: a request message to trace all involved NATFW NSLP nodes in a particular signaling session. Defined simple semantics Defined object Overall semantics still shaky.

10. TRACE Issues Which type of information should be conveyed?  Currently: IPv4 or IPv6 addresses  Support for any “identifier”* included NATs: which IP to report? Why are you only allowed to TRACE from the session owner? Many more... Asked for well-defined semantics on May 11 Still no proposal for semantics Give YOUR input and discussions NOW Without input TRACE needs to be removed!

11. Thank you! Question?