GIMPS* – The NSIS Transport Layer
draft-ietf-nsis-ntlp-03.txt
Slides: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-03.ppt
Robert Hancock, Henning Schulzrinne
(editors)
IETF#60 – San Diego
August 2004
* (insert favourite protocol name here)
Overview

Status



Issues





Reminder of previous update status
What has changed since June
Handling transport features
Protocol extensibility
Other open points
Minor/closable issues (we hope)
Next steps
Status: I


Version -02 released June
Closes some open issues of detail







More general description of NSIS message formats
Description of service interface to NSLPs (“GIMPS API”)
Cleaned up description of GHC/TTL/RAO/NSLPID handling
Restructured presentation of message routing methods
Initial proposal on protocol negotiation


Removed teardown functionality
Removed “single shot” message transport
Reverse routing state made optional
New material


(as of -02 [June] version)
Caused some discussion
Taking account of early review comments
Status: II

More formal definition of GIMPS transport service attributes




When GIMPS handshake messages can be sent over existing associations
Outline formats for Stack-Proposal and Node-Addressing objects
Added more detail on GIMPS-aware NAT traversal


Also added discussion on message bundling options
Added more detail on C-mode setup processing


(as of -03 [today] version)
This is now possible (although most details are currently left to the
imagination of the implementor)
Various additional clarifications following comments at Interim meeting
and on mailing list
Added some new open issues


Handling security interactions between GIMPS and signalling applications
What set of extensibility flags to include in the basic object format
Major Issue 1: C Mode
Protocol Configuration
C-Mode Protocol Discovery

A lot of options are conceivable


Several cannot be ruled out permanently
Several are potentially useful optimisations


Security protocol negotiation introduces its own
vulnerabilities


Hard to introduce in a backwards compatible way
Strategy: Define a simple negotiation mechanism initially
and postpone extensions


E.g. whether or not SigComp “shim” is present
Concepts based on IKE, SIP security agreement
See section 6.6
Protocol Negotiation Overview



Stack-Proposal: sequence
of Profiles
Profile: stack of ProtocolLayers
Protocol-Layer: protocol
name and security /
configuration options


Responding Node
GIMPS-Query:
Stack-Proposal-Q
(fixed for interface and NSLPID)
Node-Addressing-Information
(parameters for possible protocols)
Add new setup mechanisms
by defining new protocollayers
GIMPS-Response:
Stack-Proposal-R
(fixed for interface and NSLPID)
Node-Addressing-Information’
(updated object from query)
Mutable for NAT traversal
GIMPS-Confirm (in C-mode):
Stack-Proposal-R (echoed)
Addressing information in
a separate object

Querying Node
Negotiation Concerns

Too much transport flexibility is Bad


In particular, NSLPs might evolve which could only work
in specific GIMPS configurations
Approach

Define transport attributes more precisely: Section 4.1
defines what applications can and cannot demand




Messages can be Reliable or Non-Reliable
Reliable messages for a given Session-ID are delivered in order
Prioritisation influences node-local scheduling within these
constraints
‘Negotiation’ is one-off discovery of peer capabilities
Next Steps


Work out if this approach is OK with everyone
If it is:


Refine details of object formats and processing
Remove open issue on C-mode configuration flexibility
(section 8.5)


Remove open issue on variant setup sequences (section
8.6)


Becomes an implementation issue
Become semi-trivial future extensions
Defer all but the simplest actual configurations for now

I.e. UDP and “forwards-TCP” only
Major Issue 2: Protocol
Extensibility
Message Extensibility


Discussed in section 8.11 (cf. Appendix C)
Capability encoding: how to signal
mandatory/optional/whatever aspects in new objects



Lessons from SIP/Diameter/IPv6/RSVP/…
Preliminary analysis discovered ~10 flags people might like to set
General point: this is only a GIMPS problem because of the
adoption of a shared object space



i.e. GIMPS spec will have the IANA words for Type
Most extensibility issues aren’t actually relevant to GIMPS directly
NSLPs must define how they process these flags
Extensibility Flags

Should there be a ‘Critical’ bit?



Should there be a ‘Propagate’ bit?



“If you can’t process me, the whole message is in error”
Cf. SIP approach: anything new which is mandatory must be
negotiated
“I am relevant to the rest of the path as well”
Maybe some other scoping mechanism would be better
Should there be a ‘Refresh’ bit?



“Include me in local repair/refresh messages”
(Depends on P)
Some denial-of-service/implementability concerns
Other topics not yet addressed
NSIS-Unaware NATs


Probably a tricky subject
To make progress:

Need to adopt some general starting point


Specifically: work out how to re-use STUN? What
about other transport encapsulations?
Need to work out what classes of NAT
behaviour to support


Symmetric, cone, ...
Depends on likely prevalence in deployment?
Common NSLP Functions

Discussed extensively on mailing list. Current
possibilities:







Precedence and pre-emption (!)
Reserve/commit separation
Fate sharing between flows, applications
AAA interactions
Route recording and other diagnostics
Resource sharing
None are being addressed in GIMPS
Minor/Closable Issues
D-Mode Encapsulation


Discussed in section 8.2/8.3/8.4
Need to firm up on UDP vs. raw IP


Need to firm up on source IP address selection


(or not)
Flow source address or signalling source address? (Or
both?)
Need to firm up on RAO/NSLPID IANA
considerations
Message Scoping


Discussed in section 8.7
Scoping is about helping NSLPs send messages
like “Send this as far as the edge of this network
but no further”


Cf. sending to the edge of an aggregation region
Could be punted purely up to NSLPs


Issue is robustness in partial deployments
Even that can be fixed by allowing GIMPS to do filtering
Special Routing Methods


Discussed in section 8.8/8.9, including:
To support NATFW “Reserve” mode



MRM = send towards any public IP address
Needed? What are the MRM attributes?
Explicit routing

Discussed on mailing list



TE-like usage is probably not relevant to NSIS
Make-before-break/pre-installation may be relevant (for mobile
or high-availability requirements)
Preconfigured routing in constrained topologies
Others

Protocol name: discussed in section 8.1


D-mode rate limiting: discussed in section 8.10


and periodic mailing list flurries
Probably re-use material from other protocols
Inter-layer security policy: discussed in section
8.12

Could be more of a node policy configuration and API
issue (limited impact on other parts of protocol design)
Next Steps
Concrete Points



API validation-by-walkthrough this week
Add detail on some specific isolated issues
Other progress depends on feedback



Some points e.g. extensibility discussion need
experience more than NSIS expertise
NSIS-unaware NAT problem needs decisions on
scenarios
Specification restructuring may be wanted

Need to decide what ‘background’ stays in/goes where
General Message

The basic protocol structure is just about finalised


Remaining questions have generally isolated
impact, or are implementation issues


C-mode protocol issue is the main open part
… 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)
Status after San Diego??

Something implementable


Timetable for WG snapshot?


Possibly by imaginative software engineer?
Unofficial status
Any other priorities?