Robert Hancock, Henning Schulzrinne (editors) IETF#58 – Minneapolis November 2003
description
Transcript of Robert Hancock, Henning Schulzrinne (editors) IETF#58 – Minneapolis November 2003
NSIS Transport Layerdraft-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 – MinneapolisNovember 2003
Overview
Purported Status (by section) Major Issues
‘Explicit messaging association’ approach
Intermediary issues Less Major 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 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
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
SecurityProtocols
(TLS, IPsec)
SignallingApplication - midcom
SignallingApplication -QoS
NS
LP
lev
el
NT
LP
lev
el
IP
SignallingApplication - ANO
GIMPSGIMPS Message Encapsulation GIMPS State Maintenance
UDP TCPDCCP SCTP
IP
...which includes management of all of this
Focus of specificationis this
Design Approach (2/4) Message flows within a node:
IP Forwarding
IP HostProcessing
IP Router AlertProcessing
IP HostProcessing
IP Router AlertProcessing
ConnectionMode
Processing
ConnectionMode
Processing
Datagram ModeProcessing
Datagram ModeProcessing
Datagram mode = unsecured UDP (basically;maybe also raw IP)Connection mode = anything else (that uses'connections' or 'associations')
(Receive side) (Transmit side)
SignallingApplications
GIMPS Processing
Red = 2205-likeGreen = additional transport/security functionsHeavy = GIMPS specificWhite = 'Standard' other protocols
Downstream
Upstream
Design Approach (3/4) Routing state is
set 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)
QueryingNode
RespondingNode
"GIMPS-query"(Downstream datagram mode, UDP+RAO)
Flow Direction
"GIMPS-response"
Mes
sagi
ng a
ssoc
iatio
ns c
an b
e us
ed f
rom
her
e on
war
ds(if
ava
ilabl
e)
Mes
sagi
ng a
ssoc
iatio
ns c
an b
e se
tup
fro
m h
ere
onw
ards
(if
desi
red)
Final handshake
Install upstreamstate
(optimistic)
Installdownstream
state
Install upstreamstate (cautious)
Use and setup ofmessaging associations isonly weakly coupled torouting state setup status
Prompting and securing routingstate setup is controlled by thepresence of special GIMPSpayloads
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)
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)
Flow direction
GIMPS
NSLP-X(1)
GIMPS
NSLP-Y
GIMPS
NATPolicy-based
forwarderGIMPS
miniNSLP-X
GIMPS
NSLP-X(2)
Messaging Association Messaging Association Messaging Association
“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”
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 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)
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 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…
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? 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?
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
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 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?)
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 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
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?