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

1. GIMPS – The NSIS Transport Layerdraft-ietf-nsis-ntlp-02.txtSlides: http://nsis.srmr.co.uk/~reh/draft-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/IETF59/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/web/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 • 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

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

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 Type=“Error” • 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 • 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 SendMessage MessageReceived SetStateLifetime RecvMessage MessageDeliveryError NetworkNotification SecurityProtocolAttributesRequest GIMPS

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

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?