NATFW NSLP Status draftietfnsisnslpnatfw08'txt

1
NATFW NSLP Statusdraft-ietf-nsis-nslp-natfw-08.tx
t

• M. Stiemerling, H. Tschofenig, C. Aoun
• stiemerling_at_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/d
  raft-ietf-nsis-nslp-natfw-08-diff-to-07.html
• NATFW issue trackerhttps//kobe.netlab.nec.de/rou
  ndup/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
Notification Storms

• Single NATFW session
• NF3 fails
• NF2 detects and sends 1 NOTIFY

X
8
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?