GIMPS * – The NSIS Transport Layer draft-ietf-nsis-ntlp-05.txt Slides: Robert Hancock, Henning Schulzrinne (editors) IETF#62 – Minneapolis March 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 GIMPS Extend 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 archive/web/nsis/current/msg04537.htmlhttp://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 “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 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 issues/issue17 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!