NSIS Transport Layer draft-ietf-nsis-ntlp-01.txt Slides: Robert Hancock, Henning Schulzrinne (editors) IETF#59 – Seoul March 2004

Overview Status Structure basically unchanged since –00 Some significant changes, some more detail Nearly implementable in a benign environment Changes and Open Issues Intermediaries/Topology/Layer Binding More explanation/detail/simplifications Route change handling Security analysis and documentation Everything else from Section 8 What next…

Intermediaries / Topology / Layer Binding -00 considered allowing intermediate nodes within a session To process an NSLP subset or go through NATs Handled by tunnelled C-mode encapsulations -01 avoid/prohibits these cases Split-level NSLP: must use >1 signalling sessions If NATs are handled in GIMPS, wrap this up with the route discovery process Route recording functionality disappears

Further Issues Should we tighten the rules: require NSLP peers be 1 GIMPS hop apart GIMPS and NSLP topologies are ‘conformant’ Spec. allows this but does not enforce it Some security and routing implications How actually do to NAT traversal Requirements depend on deployment Need to work with NATFW people NSIS-unaware NAT case is especially hard

Messaging Details Worked example in 3.3 Already stimulated some interesting clarifications Decoupled state management for routing and messaging Fragmentation restricted to reliable transports Can’t do it with UDP/DCCP Strawman message formats added 5.1, 5.2, Appendix C Probably many open issues here Addressing flexibility, optional or mandatory fields, level of wildcarding …

Route Change Handling Still following FW assumption: “Anyone can hint; NTLP detects; NSLP repairs” Details relate to: What is detected (and at which node) At what node notifications are delivered Document contains strawman proposal Needs review by NSLP people “Is this what is useful?” Needs review by mobility people (compatibility)

Security Basic picture of how GIMPS provides security for itself is clear Basically handling routing state integrity and DoS prevention Architectural open issues remain: Whether to allow NSLP to bind to GIMPS security How to analyse joint security of NSLP & GIMPS How to capture security protocol ‘profiles’ for different environments Basically 3 sides of the same coin Need face time here to work out how to proceed

Other Open Issues See Section 8! 8.1 Protocol Naming 8.2 General IP Layer Issues 8.3 Encapsulation and Addressing for Datagram Mode 8.4 Intermediate Node Bypass and Router Alert Values 8.5 Messaging Association Flexibility 8.6 Messaging Association Setup Message Sequences 8.7 GIMPS State Teardown 8.8 Datagram Mode Retries & Single Shot Message Support 8.9 GIMPS Support for Message Scoping 8.10 Mandatory or Optional Reverse Routing State 8.11 Additional Discovery Mechanisms 8.12 Alternative Message Routing Requirements 8.13 Congestion Control in Datagram Mode

The End

Backup Slides Old Design Approach pictures (from –00 presentation) 1 slide on each official ‘open issue’ from section 8 of the –01 draft

Design Approach (1/4) Various ways to get required additional functionality into 2205-like approach Currently: build a new messaging framework which incorporates 2205 functions and existing transport/security protocols

Design Approach (2/4) Message flows within a node:

Design Approach (3/4) Routing state is set up as in 2205 When rtg. state exists, policy dictates when messaging associations are set up and used (and what sort, and how many, and when they are torn down again)

Design Approach (4/4) Implications (among others): + Re-use existing transport/security technology + No ‘new’ protocol development + Additional functionality scales like #peers, not #flows/sessions 0 Time/space overhead: little/no impact (given the functionality that is being achieved) - Nodes have to implement (non-trivial) transport/security protocols - Processing at intermediaries gets harder - Routing state maintenance stops being ‘free’ ?

8.1: Protocol Naming GIMPS (General Internet Messaging Protocol for Signaling) GIST (Generic Internet Signaling Transport) LUMPS (Lightweight Universal Messaging for Path associated Signaling) Other combinations of G/C, I, P, S, M, R, T, S (again) Remember Atlanta: NTLP is a stupid name and we promise not to use it for the real protocol

8.2 General IP Layer Issues UDP or raw-IP Interception on protocol number (raw-IP) or assume RAO (either) Rely on UDP checksum or include our own Getting through NSIS-unaware NATs Implementation issues (can't easily do raw IP i/o, or can’t control TTLs via UDP) Aim for one choice?

8.3 Encapsulation and Addressing for D-Mode Assume UDP (or raw-IP) only No DCCP, IPsec, … Flow sender or signalling sender as source address? Or implementation issue? Need a well-known port? Details on traffic class, flow label…

8.4 Intermediate Node Bypass and RAO Values Assume interception on RAO present (and RAO value) Reality check? How to assign values to protect routers from high volumes of ‘irrelevant’ signalling messages? 2+ aggregation options – need input requirements from NSLP work Cf considerations (message rewriting)

8.5 Messaging Association Flexibility How many to allow and how many different sorts? Many different possible stack configurations Policies for using different parallel associations Which should be the ‘MUST’ to implement? (decision needed eventually) Do we end up with another ISAKMP?

8.6 Messaging Association Setup Message Sequences Allow the MA to be setup upstream as well as downstream? When to propagate the GIMPS-query Relative to other stages in the process When to propagate the MA setup Relative to other stages in the process Interactions between MA setup and discovery exchange

8.7 GIMPS State Teardown Is this needed explicitly? What is the cost of leaving it up? How do you know when it is no longer needed? E.g. to send NSLP teardowns (more important) Potential race conditions in mobility scenarios RSVP comparison: what is the value of PATH TEAR? Is there any fate sharing between GIMPS and NSLP state?

8.8 Datagram Mode ‘Transport’ How to control retransmission in d-mode Needed if downstream message is lost Congestion issue Should it be extended to provide one-shot message transfer to NSLP? Or ‘c-mode or nothing’ Congestion control in general (rate limits?)

8.9 GIMPS Support for Message Scoping Which layer knows about network edges? Some applications need this Should it be a service provided by GIMPS? Rationale: it’s the GIMPS layer which has better access to clues about infrastructure configuration Aggregation boundaries, IP TTL, GHC…

8.10 Mandatory or Optional Reverse Routing State Wanted by NSLPs which want to be lightweight in per-flow state requirements Not clear if this is done at protocol level… “don’t store reverse state for this message” … or at implementation/API level “I will never send reverse messages for that flow” May need to be added to datagram mode description Needs very careful analysis of error conditions

8.11 Additional Discovery Mechanisms Should we consider other discovery mechanisms Compared to RAO+interception approach Examples Closer integration with routing protocols Configuration of topology constraints Can apply both to upstream and downstream Would require repeating the routing state integrity security analysis

8.12 Alternative Message Routing Requirements Some additional desires for message routing Pre-installation on backup or predicted path May be out of scope now but providing it later probably shouldn’t break the protocol NATFW “inbound reservation” message Not clear if this can be disguised as a normal message Teardown on old path (QoS-NSLP SII issue) Can be done inside implementation if topology conformance is strictly enforced

8.13 Congestion Control in Datagram Mode How? How conservative/how aggressive? Any way to use ECN? Needs more scenarios and analysis Current baseline assumption is that datagram mode can be cautious May be inappropriate for NSLPs that want to use it to shunt large volumes of data around