GIMPS

1
GIMPS The NSIS Transport Layerdraft-ietf-nsis-n
tlp-02.txt Slides http//nsis.srmr.co.uk/reh/dr
aft-ietf-nsis-ntlp-02.ppt

• Robert Hancock, Henning Schulzrinne (editors)
• NSIS Interim Meeting
• Roke Manor Research, U.K.
• June 2004

2
Overview

• Status
• Issues closed
• Additions
• Issues to close (we hope)
• Issues still open (problematic ones)
• Includes issues being ignored for now
• Next steps

3
Status

• Version -02 release literally days ago
• Accounts for early review comments
• See accompanying email and change log
• Closes some open issues of detail
• New material on formats and API etc.
• Modified description of message routing
• Initial proposal on protocol negotiation

4
Early Review Comments

• From Alex (see http//www.tschofenig.com/nsis/IETF
  59/nsis-zinin-ietf59.ppt)
• Q Why per-flow routing info in NTLP?
• A More explanation added at end of 4.1.1
• Q Suggests flow based routing?
• A This is a misunderstanding in any case,
  related developments have changed the text (see
  change number 6)
• From Dave (see http//www.ietf.org/mail-archive/we
  b/nsis/current/msg03809.html)
• Q Flow definition excludes multicast, splitting
• A Definitions modified, see change number 1
• Q How do you handle not-on-path proxies
• A We don't - clarified proxy definition in 3.2
• Q Why a hop count rather than a VIA header?
• A The rationale is in the mailing list archive
  for March we haven't put this in the document in
  the interest of brevity. (However, there is
  improved text on loop handling, see change number
  8)
• Q The D-mode messages have to follow the data
  flow
• A Yes, existing text on the subject has been
  gathered (from the rest of the document) into
  section 5.3
• Q Does having GIMPS do NAT traversal hijack
  signaling application role?
• A This is still open for discussion. The text in
  section 6.3 is clear on this. It needs discussion
  with the NATFW people (i.e. it is not just a
  GIMPS issue) at the moment, the NATFW NSLP
  regards handling NAT traversal aspects of
  non-NATFW NSLPs as out of scope, so the boundary
  is consistent
• Q Tunneling nit

5
Closed Issues
6
Closed Issue Teardown

• Was section 8.7 in -01 draft
• Q Should there be a GIMPS message which says
  remove state for flow/session XXX?
• A No. Rationale
• GIMPS state is cheap, soft-state should be OK
  even with long timers
• NSLP state is expensive (and can be torn down by
  signalling application messages)
• The NSLP can indicate to GIMPS locally that state
  is no longer needed
• Securing the transaction is tricky
• You could add it later if you wanted it

7
Closed Issue Single Shot Message Support

• Was 8.8 in -01 draft
• Q Should there be a special class of message
  transfer for reliable, secure single message
  delivery
• A No. Rationale
• Doing this properly may not be much more
  lightweight than the full C-mode experience
• Once retransmission and backoff are accounted for
• Its just an optimisation over standard C-mode
• API allows GIMPS to know when this might be
  useful the possibility
• You could add it later (given D-mode negotiation)

8
Closed Issue Mandatory Reverse Routing State

• Was 8.10 in -01 draft
• Q Does a GIMPS node always store reverse routing
  state for a flow, or only if an NSLP wants it to?
• A The latter. Rationale
• This was always the intention. The issue was a
  hangover from old considerations about how to
  handle intermediaries (-00 version)

9
New Material
10
General Bit Level Formats

• New in -02 additional material in Appendix C
• Follows discussion between NSLP GIMPS authors
• Highlights
• NSLP message header message type flags only
• Version implicit in NSLPID
• Objects are Type-Length-Value
• Type is a flat space (common to all of NSIS)
• Length number of 32 bit words in Value
• Any padding defined in Type-specific Value format
• Errors are carried in an object with TypeError
• Value field contains a severity level, error
  number, and number-specific information
• Open issues in 8.11

11
Abstract GIMPS API (I)

• New Appendix D
• Strictly informational purpose is to firm-up
  functional split between NSLPs and GIMPS, not to
  define interface
• GIMPS design decisions are (mostly) not visible
• e.g. C/D-mode distinction, GIMPS hop count
• Overall, structured like very clever UDP
  sockets API
• More control parameters, more event notifications

12
GIMPS API (II) Primitives
Any NSLP
SendMessage MessageReceived SetStateLifetime
RecvMessage MessageDeliveryError NetworkNotificati
on SecurityProtocolAttributesRequest
GIMPS

• SendMessage parameters NSLP-Data,
  NSLP-Data-Size, NSLP-Message-Handle, NSLP-Id,
  Session-ID, MRI, Direction, SII-Handle,
  Transfer-Attributes, Timeout, IP-TTL
• RecvMessage parameters NSLP-Data,
  NSLP-Data-Size, NSLP-Id, Session-ID, MRI,
  Direction, SII-Handle, Transfer-Attributes,
  IP-TTL, Original-TTL
• Bold parameters are the ones that change from
  message to message (mostly)

13
GHC and IP-TTL Handling

• Cleaned up as a result of message looping
  discussion
• Conclusion of discussion counters are preferred
  over Via-header recorded route could also be
  examined if present
• Details are in section 4.2.4
• Need to handle RAO/NSLPID mismatch
• Need to allow for fast-path implementation
  differences

RAO NSLPID TTL GHC
No match Cant happen Decrement forward message Ignore
Match No match Decrement forward message Decrement
Match Match Locally delivered Decrement
14
C-Mode Protocol Negotiation

• A lot of options are conceivable
• Several cannot be ruled out permanently
• Several are potentially useful optimisations
• Security protocol negotiation introduces its own
  vulnerabilities
• Very hard to introduce in a backwards compatible
  way
• Strategy Define a simple negotiation mechanism
  initially and postpone extensions
• Concepts based on IKE, SIP security agreement
• New section 6.6

15
Protocol Negotiation Overview
Querying Node
Responding Node

• Stack-proposal sequence of profiles
• Profile stack of protocol-layers
• Protocol-layer protocol name and security /
  configuration options
• Add new setup mechanisms by defining new
  protocol-layers
• Addressing information in a separate object
• Mutable for NAT traversal

GIMPS-Query stack-proposal-Q(fixed for
interface and NSLPID)
GIMPS-Response stack-proposal-R(fixed for
interface and NSLPID)
Handshake echo stack-proposal-R
16
Message Routing Methods

• Multiple possible ways for GIMPS to route a
  signalling message
• Current case follow the path of the flow with
  this flow identifier
• Also discussed find the next NAT in the
  direction of X, explicit routing, etc.
• Two presentational changes
• Rename FRI ? MRI, current case of MRI includes
  Flow Identifier
• Clearly identify parts of the protocol
  specification which depend on the message routing
  method
• No new message routing methods defined so far!

17
How to define a new MRM

• Steps tentatively outlined in section 8.9
• Define the format of the MRI for the new message
  routing method type.
• Define how D-mode messages should be encapsulated
  and routed corresponding to this MRI.
• Define any filtering or other security mechanisms
  that should be used to validate the MRI in a
  D-mode message.
• Define how the MRI format is processed on passing
  through a NAT.
• May still need some fine tuning and tidying
• Still need to decide whether to introduce new ones

18
Issues on the Verge of Closure?
19
RAO and NSLP Considerations

• Issue is discussed in section 8.4
• Reflects sensitivity of interception discussion
• Trade off between coarse-grained RAO allocation
  (any NSIS message) and fine-grained (exactly
  this NSLP)
• Still needs translation into IANA language
• Still needs discussion on aggregation level issue
  (cf. RSVP vs. RSVP_E2E_IGNORE)

20
MA Flexibility

• Open issue on stacking issues in 8.5 and setup
  flexibility in 8.6
• Proposal agree the negotiation mechanism (needed
  anyway)
• Then, defer all but the simplest stacking
  capabilities and setup sequences
• Still need to check node ability to implement
  sensible policies
• On re-use of associations, multiple associations,
  ...

21
Open Issues
22
Special Routing Requirements

• Discussed in section 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
• Not clear if this is relevant to NSIS
• Not planning to develop NSIS-TE any time soon

23
D-Mode Encapsulation

• Discussed in section 8.3
• 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?)

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

25
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

26
Message Encoding

• Discussed in section 8.11 (cf. Appendix C)
• Object ordering fixed or free (or in-between?)
• Capability encoding how to signal
  mandatory/optional/whatever aspects
• Affected by adoption of shared object space
• Lessons from SIP? Diameter?

27
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

28
Next Steps
29
Plans for San Diego

• Finalise if possible the nearly closed issues
• Look for at least a pro/con evaluation on some of
  the problematic issues
• Expert review might be nice
• Aim to have a simple question to be answered
• Make real progress on the NAT issue and error
  conditions (not complete solution)
• Validate the API (by NSLP authors, I hope)

30
Status after San Diego??

• Something implementable
• Possibly by imaginative software engineer?
• Timetable for WG snapshot?
• Unofficial status
• Any other priorities?