1 / 28

Robert Hancock, Henning Schulzrinne (editors) IETF#58 – Minneapolis November 2003

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

amalie
Download Presentation

Robert Hancock, Henning Schulzrinne (editors) IETF#58 – Minneapolis November 2003

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NSIS Transport Layerdraft-ietf-nsis-ntlp-00.txtSlides: http://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 isset up as in 2205 • When rtg. state exists, policy dictates when messaging associations areset up and used • (and what sort,and how many,and when theyare 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 • 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 • General desire to be able to avoid forcing reverse routing state storage • E.g. NSLP only sends on-path messages downstream • Should it be optional for GIMPS nodes to store it? • Issue of ‘holes’ preventing e.g. error reports • May be alternative mechanisms for allowing the lightweight intermediary

  28. 8.12 Additional Discovery Mechanisms • In some circumstances, different discovery approaches may be useful: • “Discovery” = “filling in the routing state” • By knowing there is only one router on the link • By knowing a recorded route of all possible GIMPS nodes on the path • Allows receiver to initiate signalling for a particular signalling application • By inspection of link-state topology database • Which should be considered further?

More Related