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

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

  • Uploaded on
  • Presentation posted in: General

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

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

Robert hancock henning schulzrinne editors ietf 62 minneapolis march 2005

GIMPS* – The NSIS Transport Layerdraft-ietf-nsis-ntlp-05.txtSlides:

Robert Hancock, Henning Schulzrinne (editors)

IETF#62 – Minneapolis

March 2005

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



  • 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

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

Major Issue 1: Protocol Extensibility

NB: These slides are not changed since Washington …

Extensibility in nsis

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

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

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.



  • 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

Major Issue 2: Additional Routing State Setup



  • 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

Current status1

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

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

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

Major Issue 3: Design Finalisation

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

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

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


Next steps

Next Steps

General message

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

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