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



Less Major Issues


‘Explicit messaging association’ approach
Intermediary issues
From section 8
Openings for specific inputs
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



7. Security Considerations



Covers NATs, routing, transition etc.
At current level of detail, follows directly from f/w (if
you believe 3/4/5)
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)
NSLP
level
Signalling
Application -QoS
Signalling
Signalling
Application - ANO
Application - midcom
GIMPS Message Encapsulation
NTLP level

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
UDP
DCCP
SCTP
Security
Protocols
(TLS, IPsec)
IP

IP
GIMPS State Maintenance
TCP
GIMPS
Focus of specification
is this
...which includes management of all of this
Design Approach (2/4)

Message flows within a node:
Design Approach (3/4)

(and what sort,
and how many,
and when they
are torn down
again)
Flow Direction
Querying
Node
Responding
Node
Use and setup of
messaging associations is
only weak ly coupled to
routing state setup status
"GIMPS-query"
(Dow nstream datagram mode, UDP+RAO)
Install upstream
state
(optimistic)
"GIMPS-response"
Install
dow nstream
state
Final handshake
Prompting and securing routing
state setup is controlled by the
presence of special GIMPS
payloads
Install upstream
state (cautious)
Messaging associations can be set
up from here onwards (if desired)

Routing state is
set up as in 2205
When rtg. state
exists, policy
dictates when
messaging
associations are
set up and used
Messaging associations can be used from here onwards
(if available)

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


Reality check would be nice
Some transport protocols need additional header
information
“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)
“Intermediary” Issues (2/3)
NSLP-X
(1)
NSLP-Y
GIMPS
GIMPS
NAT
Messaging Association

GIMPS
Flow direction
Policybased
forwarder
Messaging Association
mini
NSLP-X
GIMPS
NSLP-X
(2)
GIMPS
Messaging Association
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)
“Intermediary” Issues (3/3)

Possible solutions:

Ban intermediaries




Replace channel security (use CMS ‘partial signing’
between outer peers)
Drop strict requirement for flow control and reliability



All NSLP nodes implement complete functionality
NATs are GIMPS unaware (use STUN or explicit midcom
NSLP)
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”
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
Openings for Specific Inputs

Routing/mobility/multihoming analysis


NSIS-[un]aware NAT traversal analysis



Especially 6to4 details, anycast tunnels
Can section 7 be made more precise?
Validation against NSLP work


STUN or alternative NSIS datagram modes?
v4/v6 transition analysis


See Thursday, also network multihoming
Including proxy operations, receiver initiation
scenarios
Stack analysis (for messaging associations)
The End
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
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
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?
8.3 Encapsulation and
Addressing for D-Mode

Assume UDP (or raw-IP) only


Flow sender or signalling sender as source
address?



No DCCP, IPsec, …
Or implementation issue?
Need a well-known port?
Details on traffic class, flow label…
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)
8.5 Messaging Association
Flexibility

How many to allow and how many
different sorts?



Which should be the ‘MUST’ to implement?


Many different possible stack configurations
Policies for using different parallel associations
(decision needed eventually)
Do we end up with another ISAKMP?
8.6 Messaging Association
Setup Message Sequences


Allow the MA to be setup upstream as well
as downstream?
When to propagate the GIMPS-query


When to propagate the MA setup


Relative to other stages in the process
Relative to other stages in the process
Interactions between MA setup and
discovery exchange
8.7 Connection Mode
Encapsulation

See above (main slides on ‘intermediary
issues’)
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?
8.9 Datagram Mode
‘Transport’

How to control retransmission in d-mode



Should it be extended to provide one-shot
message transfer to NSLP?


Needed if downstream message is lost
Congestion issue
Or ‘c-mode or nothing’
Congestion control in general (rate limits?)
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…
8.11 Mandatory or Optional
Reverse Routing State

To do
8.12 Additional Discovery
Mechanisms

To do