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 To do

8.12 Additional Discovery Mechanisms

To do