Robert Hancock, Henning Schulzrinne (editors) IETF#63 – Paris August 2005

1. GxxxS* – The NSIS Transport Layerdraft-ietf-nsis-ntlp-07.txtSlides: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-07.ppt Robert Hancock, Henning Schulzrinne (editors) IETF#63 – Paris August 2005 * (insert your favourite protocol name here)

2. Overview • Overall Status • What's changed since -06 • Remaining issues

3. Overall Status • Version -06 seemed in good shape • … and no structural changes in -07 • Based on interop results: • 3 open technical points (solution proposed) • Other minor clarifications • Seem to be approaching WGLC point

4. New in Version -07 Loose-End MRM Upstream Query Error Handling Details State Machine Description

5. Loose-End MRM • Functionality: “find an ‘edge’ node in direction XXX” • Initially for NAT control • See also: draft-stiemerling-nsis-natfw-mrm • New section 5.8.2(protocol impact), C.4.1.2 (MRI format) • About 2 pages of text LE-MRM Review Notes

6. Upstream Query • Functionality: signalling localisation • Usually around flow receiver • Definition of how to encapsulate and transmit an upstream Query, section 5.8.1.3 • Message receiver has discretion whether to proceed with routing state setup • Default policy restricts to 1 IP hop (by TTL checking) • Could also be used for e2e “Please set up RR state”

7. Error Messages • Added text on general error message format, error message processing and encapsulation, and error message catalogue • Still need to add pointers in message processing rules for some cases • Will take some experiences from implementers

8. State Machine Description • Diagrams updated • Information that used to be on the web (tables, processing logic) now integrated into draft • Could be too detailed • Especially handling of timeout transitions and no-transition events

9. Open in Version -07 See http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index

10. On-Reverse-Path Threat • There is a (soluble)residual threat • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue17 • An attacker on the reverse path manipulates the Response to hijack the routing state from the Querying node • There is also a related cut&paste attack, using a valid response with the ‘wrong’ Query • Could be prevented by additional payloads, but: • Not clear if we should bother; we rely on MA security to prevent similar attacks • Proposal: document as residual threat

11. Channel Security Choice • Selection of mandatory-to-implement MA security protocol • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue29 • Front runners: xTLS, IPsec v-whatever • TLS issues: • Widely available; nice APIs; implement in user space; already working and interoperable • Currently TCP/SCTP only; mainly restricted to certificate-based authentication • But: DTLS and pre-shared key extensions now with the RFC editor • IPsec issues: • Widely available; wide choice of authentication infrastructures; works with any transport; better protection against attacks on the transport itself • Horrible APIs (or none at all); may have to access kernel operation • Proposal: TLS • Open: any additional options to be worked out (e.g. direction of setup)

12. NAT Traversal Aspects • Three separate subjects • How to run through a non-GxxxS-aware NAT • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue24 • Proposal: defer to separate document • Impact on GIMPS of traversing a GxxxS-aware NAT • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue22 • Text already included (would like validation) • What a GxxxS-aware NAT should do • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue23 • Proposal: defer to separate document

13. Configuration Data Format • How to convey / negotiate port number information where there is > 1 way to use a protocol in a messaging association • E.g. could want TCP with or without TLS • Note: MA port numbers can be agile; needn’t be well known or registered • Solution proposed • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue14 • Need rapid feedback from implementers

14. Clarifications/Refinements • Interaction between R bit, cookies & message type • R bit takes precedence • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue57 • How to describe message source on the first NTLP hop • Is it the signalling or flow source? (It’s both) • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue58 • The MRI depends on message direction • E.g. different for different messages in a handshake • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue59 • If you have a choice of NLIs, which one to use • Default policies can be described, and their implications • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue61

15. Specification Finalisation • IANA Considerations • NB Formal policies only • Technical criteria are document separately • Text proposed: • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue60 • MUST-ification • Current language needs to be formalised

16. … and finally … The one you’ve all been waiting for:

17. What Should We Call It? • Some ‘consumer resistance’ to GxxxS • Alternatives … • GASP, LUMPS, GIST, Shingou, Aizu, STAMP, SHRIMP, STRIP, STRAP, CHIMP, SINGOP, SHINSIS, GASTRIC, SPLAT, PIGS, GERM, GEMS, SETUP, MOPPLE, GUTS, TRIM, MEST, STORM, NST, previous proposals (CSTP, CASP), RSVPv2, “the NTLP”, “NSIS”, other non-random combinations of S/R/T/M/U/G/P/N/I…