GIMPS*

1
GIMPS The NSIS Transport Layerdraft-ietf-nsis-
ntlp-05.txt Slides http//nsis.srmr.co.uk/reh/d
raft-ietf-nsis-ntlp-05.ppt

• Robert Hancock, Henning Schulzrinne (editors)
• IETF62 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 cant 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 cant 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 arent 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 Martins draft-stiemerling-nsis-natfw-mrm-01.t
  xt
• 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/nsi
  s/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.h
  tml
• 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-nt
  lp-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!