GIMPS * – The NSIS Transport Layer draft-ietf-nsis-ntlp-05.txt Slides:...
-
Upload
arron-anderson -
Category
Documents
-
view
218 -
download
1
Transcript of GIMPS * – The NSIS Transport Layer draft-ietf-nsis-ntlp-05.txt Slides:...
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 – MinneapolisMarch 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
Different rules for where messages should go (includes
signalling about new types of flow)
Add new MRM
Additional transport/security protocol performance
Add new protocol layer, extend SP and
NAO formats
Do something we can’t even imagine yet
Make a new NTLP
Add new data types to a message
Define a new TLV (or use an existing one
from another NSLP)
Add new (usually optional) protocol operations
Define a new message type
Do something we can’t even imagine yet
Make a new NSLP(Do anything you
like within the overall NSIS
structure)
This is where the question of ‘extensibility
flags’ (to influence processing of ‘new’ objects) comes in
Extend GIMPSExtend an NSLP
Add an NSLP
Extend NSIS
Extensibility in NSIS
Versioning issue
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
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…
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.ht
ml 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-ntl
p-issues/issue17
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)