NSIS Transport Layer draftietfnsisntlp00'txt Slides: http:nsis'srmr'co'ukrehdraftietfnsisntlp00'ppt

1
NSIS Transport Layerdraft-ietf-nsis-ntlp-00.txt
Slides http//nsis.srmr.co.uk/reh/draft-ietf-nsi
s-ntlp-00.ppt

• Robert Hancock, Henning Schulzrinne (editors)
• IETF58 Minneapolis
• November 2003

2
Overview

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

3
Origins

• Starting NTLP work (Slide _at_ IETF56)
• Framework (and Requirements) I-Ds
• 2 initial drafts at IETF57
• 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

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

5
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

6
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)
7
Design Approach (2/4)

• Message flows within a node

Tarted-up version of Fig 3. Here (distinguish
2205 world and better world)
8
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)
9
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
• ?

10
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

11
Encapsulations
Peak-and-trough diagram here (App. C)

• 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

12
Three Options

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

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
• Could knock up a slide for each in short order?

14
Openings for Input

• Routing/mobility/multihoming analysis
• See Thursday, also network multihoming
• NSIS-unaware 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