1 / 21

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

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 – Minneapolis March 2005. * (still room to insert favourite protocol name here, if you can think of one ).

ailish
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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!

More Related