Robert Hancock, Henning Schulzrinne (editors) IETF#62 – Minneapolis March 2005

1. GIMPS* – The NSIS Transport Layerdraft-ietf-nsis-ntlp-05.txtSlides: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-05.ppt Robert Hancock, Henning Schulzrinne (editors) IETF#62 – Minneapolis March 2005 * (still room to insert favourite protocol name here, if you can think of one)

2. 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

3. 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

4. Major Issue 1: Protocol Extensibility NB: These slides are not changed since Washington …

5. Extensibility in NSIS Extend NSIS Extend GIMPS Add an NSLP Extend an NSLP Versioning issue Different rules for where messages should go (includes signalling about new types of flow)  Add new MRM Do something we can’t even imagine yet  Make a new NSLP (Do anything you like within the overall NSIS structure) Additional transport/security protocol performance  Add new protocol layer, extend SP and NAO formats Add new (usually optional) protocol operations  Define a new message type This is where the question of ‘extensibility flags’ (to influence processing of ‘new’ objects) comes in Add new data types to a message  Define a new TLV (or use an existing one from another NSLP) Do something we can’t even imagine yet  Make a new NTLP

6. 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)

7. 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.

8. 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

9. Major Issue 2: Additional Routing State Setup

10. 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

11. 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!

12. 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.

13. 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…

14. Major Issue 3: Design Finalisation

15. 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

16. State Transition Stuff • Several activities (supporting implementations) • draft-fu-nsis-ntlp-statemachine-01.txt • http://nsis.srmr.co.uk/nsis/gimps-state-machines.html • 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

17. 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 …

18. 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-ntlp-issues/issue17

19. Next Steps

20. 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)

21. 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!