1 / 12

NATFW NSLP Status draft-ietf-nsis-nslp-natfw-08.txt

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. Document Status. General protocol semantics quite stable Except NOTIFY, TRACE, and REA-F Draft undergoes all over text finishing

mohammad-jennings
Download Presentation

NATFW NSLP Status draft-ietf-nsis-nslp-natfw-08.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NATFW NSLP Statusdraft-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 -07http://www.stiemerling.org/ietf/nsis/draft-ietf-nsis-nslp-natfw-08-diff-to-07.html • NATFW issue trackerhttps://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. NSLP Session NOTIFY NF1 NF2 NF3 NR NI Notification Storms • Single NATFW session • NF3 fails • NF2 detects and sends 1 NOTIFY X

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

  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/ • 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?

More Related