GIMPS*

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

• Robert Hancock, Henning Schulzrinne (editors)
• IETF61 Washington
• November 2004

(insert favourite protocol name here, if you
can think of one)
2
Overview

• Status
• What has changed since August
• Issues
• Protocol extensibility (still)
• Design finalisation (including security issues)
• Other open points
• Minor/closable issues (we hope)
• Next steps

3
Status

• API validated by NSLP designers
• Some minor tweaks and extensions
• Message format tweaks new error object
• Different structure of ABNF description
• Extensibility flags (see later)
• Outline of what needs to be in IANA section
• Completed protocol negotiation description
• Re-written (clearer!) text on association setup
  rules and message sequences
• Added text on retransmission and rate limiting

4
Major Issue 1 Protocol Extensibility
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 Protocol Design Finalisation

• (Not so much an open issue as work to be getting
  on with)

10
Background

• Basic structure of protocol operation not changed
  for 4 months
• Mainly refinements, clarifications, isolating
  particular corner cases, extensibility
• Time to get a bit more formal
• Message processing/State transition rules
• Denial of service/overload analysis
• Error conditions and notifications
• Integrating channel security

11
Activities
Input from reference implementation
Security analysisTwo aspects
Define message processing rules state
transition diagrams
New dense specification section 6-ish
Denial of service/overload handling
Channel security integration
Overview of error conditions, protocol parameters
Input to MPRs and informative text on cookie
handling
Revised API and additional protocol layer
descriptors
12
Other topics not yet addressed
13
GIMPS-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?

14
Minor/Closable Issues
15
D-Mode Encapsulation

• Discussed in section 9.2/9.3/9.4
• Need to firm up on UDP vs. raw IP
• (or not)
• Need to firm up on source IP address selection
• Flow source address or signalling source address?
  (Or both?)
• Need to firm up on RAO/NSLPID IANA considerations

16
Message Scoping

• Discussed in section 9.6
• 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
• Related issue knowing what scope a message came
  from
• Could be punted purely up to NSLPs
• Issue is robustness in partial deployments
• Even that can be fixed by allowing GIMPS to do
  filtering
• Different NSLPs will have different boundaries
  anyway
• Proposal drop as a potential GIMPS function
• Need a common NLSP-level object instead

17
Special Routing Methods

• Discussed in section 9.7/9.8, including
• To support NATFW Reserve mode
• MRM send towards a public IP address
• See Martins draft (later?)
• Explicit routing
• 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
• May be needed for NATFW Deny action

18
GIMPS-Aware NAT Processing

• The objects exist in the specification to make
  traversal possible
• Most details of the objects are left opaque
• Precise NAT processing doesnt change the rest of
  the protocol
• Actual processing example could be written up to
  get a reality check
• The detailed transformation rules are quite
  complex
• May want to cross-check NAT binding management
  model with NATFW NSLP

19
Route-Change Handling

• General discussion in section 6.1 probably needs
  updating
• Comparison with expectations of NSLP authors
• What is provided by GIMPS vs. what they have to
  do
• Looking for detailed analysis and comments from
  mobility and multihoming gang
• Also, architecture decision on which layer to
  propagate route change notifications at
• In fact, applies to error conditions in general

20
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
• Message scoping
• None are being addressed in GIMPS

21
Others

• Protocol name discussed in section 8.1
• And periodic mailing list flurries
• IP TTL management and detection
• Proposal this is needed
• Just need to work out the details
• General guidance on object ordering
• Lost GIMPS-confirm handling

22
Next Steps
23
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)

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