GIMPS – The NSIS Transport Layer draft-ietf-nsis-ntlp-02.txt Slides: Robert Hancock, Henning Schulzrinne (editors) NSIS Interim Meeting Roke Manor Research, U.K. June 2004

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

Status Version -02 release literally days ago Accounts for early review comments See accompanying 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

Early Review Comments From Alex (see Q: Why per-flow routing info in NTLP? A: More explanation added at end of 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 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 A: Text in 6.4 adjusted accordingly Q: Does 8.2 really rule out raw-IP? A: The text in 8.2 on the subject has been expanded to say why. Q: Aggregation is per-interface, not per-node A: Text in 8.4 on aggregation handling adjusted accordingly

Closed Issues

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

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 It’s 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)

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)

New Material

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 Type=“Error” Value field contains a severity level, error number, and number-specific information Open issues in 8.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

GIMPS API (II): Primitives 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) Any NSLP GIMPS SendMessage MessageReceived SetStateLifetime RecvMessage MessageDeliveryError NetworkNotification SecurityProtocolAttributesRequest

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 Need to handle RAO/NSLPID mismatch Need to allow for fast-path implementation differences RAONSLPIDTTLGHC No matchCan’t happenDecrement; forward message Ignore MatchNo matchDecrement; forward message Decrement Match Locally deliveredDecrement

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

Protocol Negotiation Overview 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 Querying NodeResponding Node 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

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!

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

Issues on the Verge of Closure?

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)

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,...

Open Issues

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

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

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?

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

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?

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

Next Steps

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)

Status after San Diego?? Something implementable Possibly by imaginative software engineer? Timetable for WG snapshot? Unofficial status Any other priorities?