NSIS Transport Layer draft-ietf-nsis-ntlp-00.txt Slides: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-00.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

• 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
• Its 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 its 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-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
• Stack analysis (for messaging associations)

15
The End
16
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

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 cant 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 its 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