NSIS Transport Layer draft-ietf-nsis-ntlp-00.txt Slides: Robert Hancock, Henning Schulzrinne (editors) IETF#58 – Minneapolis November 2003

Overview Origins Purported Status (& outline of operation)? Major Issues ‘Explicit messaging association’ approach (& a hum?) Encapsulation options Less Major Issues Openings for Inputs

Origins ‘Starting NTLP work’ IETF#56) Framework (and Requirements) I-Ds 2 initial drafts at IETF#57 Some discussion in Vienna and on list Some expert review Detail from one used to expand ‘conceptual description’ of the other Plus a lot more explanation and examples Still not yet a complete protocol design

Status & Outline (1/2) 1. Introduction (& 2. Terminology) Basically follows from f/w – assumed  3. Design Methodology How 2205-like transport is extended with ‘real’ transport/security protocols to provide 2747/2961-like functionality – basically an ‘extended strawman’ 4 [Overview of Operation] & 5 [Formats] mainly provide more discussion of the implications of 3.1 WG needs to commit to the approach of 3.1, or some alternative (in scope of the charter…)

Status & Outline (2/2) 6. Advanced Protocol Features Covers NATs, routing, transition etc. At current level of detail, follows directly from f/w (if you believe 3/4/5) 7. Security Considerations Allocation of threats and solutions At current level of detail, follows directly from f/w (if you believe 3) 8. Open Issues Basically questions about detailed aspects of 4/5

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 Tarted-up version of Fig. 2 here (stack diagram)

Design Approach (2/4) Message flows within a node: Tarted-up version of Fig 3. Here (distinguish 2205 world and ‘better’ world)

Design Approach (3/4) Routing state is set up as in 2205 When routing state exists, policy dictates when messaging associations are set up and used (these two operations are actually largely decoupled) Improved version of Fig. 4 here (clearer about decoupling of when MAs are set up)

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’ ?

Formats General approach: a message is a header + a bundle of TLV-encoded objects Some objects can be signalling application payloads No fundamental difference between connection/datagram modes Some datagram messages need IP Router Alert Option setting Preferred (?) method for message interception Some transport protocols need additional header information

Encapsulations How far should a messaging association go? Further = ‘better’ service to protocol user Further = more problems for intermediates Can trade these off by making messaging encapsulation more complex In extreme case, handle discovery overhead problem too Peak-and-trough diagram here (App. C)

Three Options Three options for connection mode Raw: simple, but all processing nodes terminate all messaging associations Explicit PtP: more complex, NAT/’NSLP-lites’ don’t require MA to be terminated Implicit PtP: more complex, all signalling automatically finds route changes Which to allow (or >1?) Impacts subsequent tradeoffs in NTLP/NSLP split ‘Real’ answer is a new protocol, but out of scope…

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 Connection Mode Encapsulation 8.8 GIMPS State Teardown 8.9 Datagram Mode Retries & Single Shot Message Support 8.10 GIMPS Support for Message Scoping 8.11 Mandatory or Optional Reverse Routing State 8.12 Additional Discovery Mechanisms Could knock up a slide for each in short order…?

Openings for Input Routing/mobility/multihoming analysis See Thursday, also network multihoming NSIS-[un]aware NAT traversal analysis STUN or alternative NSIS datagram modes? v4/v6 transition analysis Especially 6to4 details, anycast tunnels Can section 7 be made more precise? Validation against NSLP work Including proxy operations, receiver initiation scenarios