Natfw nslp status draft ietf nsis nslp natfw 08 txt
This presentation is the property of its rightful owner.
Sponsored Links
1 / 12

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


  • 70 Views
  • Uploaded on
  • Presentation posted in: General

NATFW NSLP Status draft-ietf-nsis-nslp-natfw-08.txt. M. Stiemerling, H. Tschofenig, C. Aoun [email protected] 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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Natfw nslp status draft ietf nsis nslp natfw 08 txt

NATFW NSLP Statusdraft-ietf-nsis-nslp-natfw-08.txt

M. Stiemerling, H. Tschofenig, C. Aoun

[email protected]

NSIS Working Group, 64th IETF meeting


Document status

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/


Issue solved 1

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.


Issue solved 2

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)


Open issues in tracker

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)


Msn wrap around

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


Notification storms

NSLP

Session

NOTIFY

NF1

NF2

NF3

NR

NI

Notification Storms

  • Single NATFW session

  • NF3 fails

  • NF2 detects and sends 1 NOTIFY

X


Notification storms1

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


Notification storm

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


Diagnosis

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


Way forward

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


Natfw nslp status draft ietf nsis nslp natfw 08 txt

Thank you!

Question?


  • Login