GxxxS * – The NSIS Transport Layer draft-ietf-nsis-ntlp-07.txt Slides: Robert Hancock, Henning Schulzrinne (editors) IETF#63 – Paris August 2005 * (insert your favourite protocol name here)

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

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

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

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

Upstream Query Functionality: signalling localisation Usually around flow receiver Definition of how to encapsulate and transmit an upstream Query, section 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”

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

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

Open in Version -07 See bin/roundup.cgi/nsis-ntlp- issues/index

On-Reverse-Path Threat There is a (soluble) residual threat 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

Channel Security Choice Selection of mandatory-to-implement MA security protocol 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)

NAT Traversal Aspects Three separate subjects How to run through a non-GxxxS-aware NAT issues/issue24 issues/issue24 Proposal: defer to separate document Impact on GIMPS of traversing a GxxxS-aware NAT issues/issue22 issues/issue22 Text already included (would like validation) What a GxxxS-aware NAT should do issues/issue23 issues/issue23 Proposal: defer to separate document

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 issues/issue14 issues/issue14 Need rapid feedback from implementers

Clarifications/Refinements Interaction between R bit, cookies & message type R bit takes precedence How to describe message source on the first NTLP hop Is it the signalling or flow source? (It’s both) The MRI depends on message direction E.g. different for different messages in a handshake If you have a choice of NLIs, which one to use Default policies can be described, and their implications

Specification Finalisation IANA Considerations NB Formal policies only Technical criteria are document separately Text proposed: issues/issue60 issues/issue60 MUST-ification Current language needs to be formalised

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

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…