1. NSIS Transport Layer draft-ietf-nsis-ntlp-00.txt Slides: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-00.ppthttp://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-00.ppt Robert Hancock, Henning Schulzrinne (editors) IETF#58 – Minneapolis November 2003

2. Overview Purported Status (by section) Major Issues ‘Explicit messaging association’ approach Intermediary issues Less Major Issues From section 8 Openings for specific inputs

3. 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…)

4. 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

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

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

7. 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)

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

9. 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 Reality check would be nice Some transport protocols need additional header information

10. “Intermediary” Issues (1/3) If ‘full’ NSLP peers communicate directly over 1 GIMPS hop, life if beautiful It is trivial for GIMPS to provide a well-defined, transport & security service for the signalling application As soon as ‘partly dumb’ intermediaries want to read/modify objects, life is ugly Channel security terminates half-way It’s practically impossible to exercise flow control except in trivial topologies Overload turns into message drops (i.e. unreliability)

11. “Intermediary” Issues (2/3) Ideally the messaging association would go from node 1 – node 2; it’s broken by, for example: GIMPS-aware NATs (to re-write flow-id) NSLP nodes implementing a functionality subset (PBFs handled as part of discovery process)

12. “Intermediary” Issues (3/3) Possible solutions: Ban intermediaries All NSLP nodes implement complete functionality NATs are GIMPS unaware (use STUN or explicit midcom NSLP) Replace channel security (use CMS ‘partial signing’ between outer peers) Drop strict requirement for flow control and reliability NSLPs have to be able to receive always (and load shed); intermediaries can drop packets Hope that this only happens in pathological scenarios Tunnel mode encapsulations (draft section 5.3) “Cure worse than the disease”

13. 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

14. Openings for Specific Inputs 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 Stack analysis (for messaging associations)

15. The End

16. Origins ‘Starting NTLP work’ (Slide @ 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

17. 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

18. 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?

19. 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…

20. 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. 3175 considerations (message rewriting)

21. 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?

22. 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

23. 8.7 Connection Mode Encapsulation See above (main slides on ‘intermediary issues’)

24. 8.8 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?

25. 8.9 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?)

26. 8.10 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…

27. 8.11 Mandatory or Optional Reverse Routing State To do

28. 8.12 Additional Discovery Mechanisms To do