GIMPS
Sponsored Links
This presentation is the property of its rightful owner.
1 / 21

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


  • 86 Views
  • Uploaded on
  • Presentation posted in: General

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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)


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 …


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


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


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-ntlp-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!


  • Login