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

2. Document Status General protocol semantics quite stable  Except NOTIFY, TRACE, and REA-F Draft undergoes all over text finishing Supplementary documents are closed  Migration draft  Intra-realm draft  Security threats  LE-MRM Diff to -07 http://www.stiemerling.org/ietf/nsis/draft-ietf-nsis-nslp-natfw-08-diff-to-07.html http://www.stiemerling.org/ietf/nsis/draft-ietf-nsis-nslp-natfw-08-diff-to-07.html NATFW issue tracker https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/ https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/

3. Issue Solved (1) Authentication and Authorization of NOTIFY messages (I25)  NOTIFY messages MUST only be forwarded if they have received in an already established messaging association for the particular session. NOTIFY messages MUST NOT be accepted and handled(forwarded) if they are received outside a session and messaging association. RESERVE mode handling with multiple CREATEs (I22, I20)  Introduced NONCE object  Can differentiate between proxy CREATE (has NONCE) and NI CREATE Missing Transport Layer Port information for REA (I48)  Port information missed - fixed.

4. Issue Solved (2) Session ownership (I7)  -07 had purposed built key (PBK) approach  Considered too heavy weight during last meeting  Removed PBK  Relies now on session ID Exact semantics of UCREATE (I38)  As agreed: Now a REA for firewalls (REA-F)  Like REA but with path-coupled MRM Keep Port Parity field/semantics (I28) Port Range Parameter Field (I29)  Usage of RFC 3605 (I29 & I28)

5. Open Issues in Tracker 24 issues in tracker  4 marked as critical  4 marked as urgent  2 marked as bug  14 marked as feature or wish Most issues are editorial things to fix Some are done and waiting for final confirmation (mail to list!) Here are the problems...  Message sequence number wrap around (I47)  NOTIFY storms (56)

6. MSN wrap around Message sequence numbers  End-to-end significance  Chosen per session  Chosen randomly by NI/NI+  QoS’ RSN has local significance NI/NI+ reboots are detected easily  New SID + MSN  Neighbour reboot detection not needed, all dependent on NI/NI+ 07: Once the MSN has reached the maximum value, the next value it takes is zero. 08: Implement RFC 1982 Serial Number Arithmetic, Section 3.2 comparison

7. NR NI NF2NF1NF3 NSLP Session Notification Storms Single NATFW session NF3 fails NF2 detects and sends 1 NOTIFY NOTIFY X

8. NR NI NF2NF1NF3 NSLP Session X NOTIFY Notification Storms Single NATFW session NF3 fails NF2/NF3 are responsible for X sessions NF2 detects and sends X NOTIFY back to NF1

9. Notification Storm NI/NI+ is session root Asynchronous notifications are sent to NI/NI+ Storm affects more core than edge  Will occur between core NAT/Firewall  Will fade out towards the Nis Mitigation needed  Draft says: may generate NOTIFY  An aggregated NOTFIY for all sessions

10. Diagnosis Removed old QDRQ part  Defined an extension set of diagnosis/query capabilities  No real use cases New lightweight diagnosis  Called: TRACE  Traceroute of NATFW NSLP in a session  Returns list of NATFW nodes  Nodes MAY add their identifiers  Not every node/network may reveal this information  Identifiers = IP addresses  Needs considerations about scoping

11. Way Forward Snapshot version is available here (pre 09):  http://www.stiemerling.org/ietf/nsis/snapshot/ http://www.stiemerling.org/ietf/nsis/snapshot/  Contains all comments by Elwyn  Currently editorial changes to -08 Fixing urgent/critical/bug issues first Talking with 3GPP2 group (Gabot et all) about their requirements Publish new revision by mid of December

12. Thank you! Question?