GIMPS* – The NSIS Transport Layer

draft-ietf-nsis-ntlp-05.txt Slides: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-

05.ppt

Robert Hancock, Henning Schulzrinne (editors)

IETF#62 – MinneapolisMarch 2005

* (still room to insert favourite protocol name here, if you can think of one)

Overview Status

What has changed since November Issues

Protocol extensibility (still, again) Additional routing state setup methods

Loose end routing Upstream query

Design finalisation STDs/STTs, NAT issues, cookie handling

Minor/closable issues (we hope) See the tracker!

Next steps

What has changed… API extended to handle security interactions

Partly implemented for TLS case Changed message formats

Explicit message type identification ABNF rewritten

Encapsulation options pinned down Defined as not semantically significant

IP TTL measurement and reporting Proper handling of lost GIMPS-Confirm message

Major Issue 1: Protocol Extensibility

NB: These slides are not changed since Washington …

Different rules for where messages should go (includes

signalling about new types of flow)

Add new MRM

Additional transport/security protocol performance

Add new protocol layer, extend SP and

NAO formats

Do something we can’t even imagine yet

Make a new NTLP

Add new data types to a message

Define a new TLV (or use an existing one

from another NSLP)

Add new (usually optional) protocol operations

Define a new message type

Do something we can’t even imagine yet

Make a new NSLP(Do anything you

like within the overall NSIS

structure)

This is where the question of ‘extensibility

flags’ (to influence processing of ‘new’ objects) comes in

Extend GIMPSExtend an NSLP

Add an NSLP

Extend NSIS

Extensibility in NSIS

Versioning issue

Object Extensibility Discussed in Appendix C.3.2 Capability encoding: how to signal

mandatory/optional/whatever aspects in new objects Lessons from SIP/Diameter/IPv6/RSVP/… Discovered ~10 flags people might like to set

A GIMPS problem because of the shared object space i.e. GIMPS spec will have the IANA words for “Type” Most issues aren’t relevant to GIMPS directly NSLPs must define how they are allowed to set and

interpret these flags (GIMPS must too)

Current Status From C.3.2 (roughly), leading 2 bits of “type” field are

interpreted as follows: 00 (Mandatory): If the object is not understood, the entire

message containing it must be rejected with an error indication.

01 (Ignore): If the object is not understood, it should be deleted and then the rest of the message processed as usual.

10 (Forward): If the object is not understood, it should be retained unchanged in any message forwarded as a result of message processing, but not stored locally.

11 (Refresh): If the object is not understood, it should be incorporated into the locally stored signaling application state for this flow/session, forwarded in any resulting message, and also used in any refresh or repair message which is generated locally.

Rationale Looks like 2205+, using leading 2 bits of

type field as indicator RSVP defined 3 extension classes All 3 got used; some specs used all 3 at once

Could do with more background info on the subject But: NSIS layering means RSVP experience not directly

applicable Mailing list discussion to split one class Using ‘refresh’ class needs security awareness Using ‘mandatory’ class is not mandatory

Can always discover/negotiate extended capabilities as a policy in the NSLP design instead

Major Issue 2: Additional Routing State

Setup

Requirements New methods to define what the route of a

signalling message should be Edge-NAT discovery

See Martin’s draft-stiemerling-nsis-natfw-mrm-01.txt Variant route types (backup, pro-active)

For mobile/high-availability environments The ability to initiate routing state from the

receiver Start at

http://www1.ietf.org/mail-archive/web/nsis/current/msg04537.html

Current Status v05 describes forwards path setup coupled

to a real (source destination flow) only Same as classical RSVP

New routing methods require a new MRM v05 tells you how (v06 will clarify) Send text!

Destination source state setup requires encapsulation rules for GIMPS-Query Send text!

New Routing Methods What you have to do to define a new message

routing method (MRM) Currently in section 9.2

Define the format of the MRI Include what you mean by ‘upstream’ and ‘downstream’

Define how GIMPS-Query messages should be encapsulated and routed for this MRI

For one or both of upstream/downstream Define any filtering or other security mechanisms

that should be used to validate the MRI in a Query message.

Define how to process the MRI in a NAT.

Destination Source Setup

Need to explain how to send the initial GIMPS-Query message upstream Rest of the protocol description is unchanged

Result of restructuring in -05 Needs corresponding text in the current

section 5.3.2.2 “Query Encapsulation for the Path-Coupled

Message Routing Method” Basically about source/destination address

selection, other parts of the IP header, ICMP and NAT handling…

Major Issue 3: Design Finalisation

Design Finalisation Three strands of work: State transition analysis and message

processing rules NAT traversal (GIMPS-aware case)

Current mechanisms are broken in some cases

Cookie handling Requirements on the mechanism and

(informational) solutions

State Transition Stuff Several activities (supporting implementations)

draft-fu-nsis-ntlp-statemachine-01.txt http://nsis.srmr.co.uk/nsis/gimps-state-machines.ht

ml Stylistically quite different

Machine structure, level of detail, event classification

Implementation discussions later this week Would like to incorporate this material into the next

version (in some form) Will use it to pull out the bulk of the error conditions

GIMPS-Aware NATs Plan informative text on how this really works

MRI and NAO processing How to fill out the NAT-traversal object (examples) Scenarios (including nested NATs, both traversal

directions) State installation at paranoid responder when C

mode is used for the Confirm Currently broken

May need to move to a separate document?? Examples are loooooooooooong …

Cookie Handling Query/Responder cookies are relied on for

several purposes Avoid DoS (flooding, state poisoning) attacks Avoid handshake hijack by off-path nodes Correlate different stages of the handshake Defer state installation at responder

Need to formalise the set of requirements and give examples for implementation Text will go to issue tracker soon http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntl

p-issues/issue17

Next Steps

General Message The basic protocol structure is just about

finalised Remaining questions have generally isolated

impact, or are implementation issues … we hope (with some justification: e.g. NAT

work has happened in background) Refinements will take place as a result of

Paper validations (mobility work, NSLP checking) Experimental implementations (started already)

Next Priorities

Design finalisation Need some decisions on specification

structure and level of detail In parallel with implementation work

See later Further input on any of the other open

issues is always appreciated!