Robert Hancock, Henning Schulzrinne (editors) NSIS Interim Meeting – Munich May 2005

1. GIMPS* – The NSIS Transport Layerdraft-ietf-nsis-ntlp-06.txtSlides: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-06.ppt Robert Hancock, Henning Schulzrinne (editors) NSIS Interim Meeting – Munich May 2005 * (still room to insert favourite protocol name here, if you can think of one)

2. Overview • What's changed since -05 & what's open in -06 • Grouped by subject area: • Security Issues • "Transport" Issues • Routing State Management • Message Formats • Explanatory Material • Layering/Extensibility • Other stuff

3. Security Issues • Analysis of cookie requirements - 8.5 • includes abstract “example” • Open issue: on-reverse-path threat • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue17 • Address validation - 4.1.2/D.3 • Open issue: channel security selection. • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue29

4. Security I: Cookies (1/3) • Section 8 (in general) and section 8.5 (summary) identifies the threats to be mitigated by “non-administrative” security • Mainly to do with GIMPS routing state protection • Messaging associations protected “internally” • Messaging association negotiation protected by sip-sec agree-like mechanisms • Flooding; state poisoning; some replays; … • (Very) detailed analysis in issue tracker • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue17 • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/file1/GIMPS%20Cookies.htm

5. Security I: Cookies (2/3) • Section 8.5 says what implementors need to do • Q-Cookie: basically, a unique cryptographically random number • R-Cookie: more complicated, for example R-Cookie = liveness data + hash (locally known secret, Q-Node NLI, MRI, NSLPID, reception interface, liveness data) • Questions: • More pairs of eyes needed to look for issues • How much detail/precision to put in the draft

6. Security I: Cookies (3/3) • 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 • Can be prevented by additional payloads • Not clear if we should bother • There are other on-path attacks which we rely on MA security to prevent

7. Security II: Address Validation • GIMPS can say something about whether the node ‘N’ sending a signalling message has the ‘right’ to signal about an address ‘A’ • Specifically: A is assigned to N or not? • Noted in 4.1.2, D.3 • Two API attributes: • Is the signalling source a flow endpoint? • Has a return routability check been carried out? • Note: No protocol changes • Don’t want to get into CGAs etc.

8. Security III: Channel Security • Need to decide on mandatory-to-implement messaging association security protocol • Front runners: xTLS, IPsec v-whatever • TLS issues: • Widely available; nice APIs; implement in user space • Currently TCP/SCTP only; mainly restricted to certificate-based authentication • IPsec issues: • Widely available; wide choice of authentication infrastructures; works with any transport • Horrible APIs (or none at all); may have to access kernel operation • Open for discussion …

9. "Transport" Issues • Clarified rules for messaging association lifetime/refresh - 4.4.3 • Open: API fix for Query & stateless handling • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue44 • Open: Epoch change monitoring • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue43

10. Transport I: MA Liveness • Need a mechanism to agree MA lifetime • Basically: avoid the initiator tearing it down while the responder still wants it • Basic design: “I can tear an MA down if: • A) I no longer want it • B) You haven’t recently said you still want it” • And I define the timescale of ‘recently’ • Lifetime requested in Stack-Configuration-Data object at MA setup • New GIMPS-MA-Hello message says “I still want it” without referring to any specific flow

11. Transport II: Stateless Handling • Two issues about GIMPS/NSLP interaction • API hook to allow node to process a message without creating routing state (Source-SII) • How to handle NSLP data in a Query • Current API allows an NSLP to cause very strange message sequences, and what happens to NSLP data in a Query is not defined • Possible approach: GIMPS says “what should I do with this data for which there is no routing state?”, NSLP says … • A) Accept the routing state • B) Request routing state validation and here is a response • C) Drop out of the routing state and forward this payload • Note: no protocol changes

12. Transport III: Node Restart • What to do when a node restarts • Discussion on issue tracker  GIMPS sorts itself out correctly • That is: routing state and messaging associations are re-established • Signalling messages continue to be delivered • Question: should GIMPS provide this interesting information to NSLPs? • Would require some extra GIMPS functionality to avoid false positives, e.g. epoch counter

13. Routing State Management • Clarified rules for routing state lifetime/refresh - 4.4.3 • Routing state now keyed by SID - 3.4 • Open issue: “edge-probing” MRM • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue8 • Open issue: upstream Query for path-coupled MRM • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue19

14. RSM I: Lifetime/Refresh • Section 4.4.3 now says what the lifetimes mean and how they should be interpreted • RS-Validity-Time part of NLI object • Previously was a separate object • The Responding node may delete the RS if it has not been refreshed within the RS-Validity-Time in the GIMPS-Response • It’s up to the Querying node to initiate the refresh operation within the lifetime, add jitter, retransmit etc.

15. RSM II: State keyed by SID • Section 3.4 makes it explicit that routing state uses the SID as a key • Previously ambiguous • Normally it will not change if the SID changes, but … • Including the SID prevents some DoS attacks • Normally there should be only one SID for any given MRI/NSLPID anyway • i.e. no additional state storage requirements

16. RSM III: Edge-Probing MRM • Still in Martin’s draft • https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12471 • http://www.ietf.org/internet-drafts/draft-stiemerling-nsis-natfw-mrm-01.txt • Propose to add new section 5.7.2 • Will have MRI format (5.7.2.1) and Query encapsulation (5.7.2.2)

17. RSM IV: Upstream Query • The ability to initiate routing state from the receiver • Start at http://www1.ietf.org/mail-archive/web/nsis/current/msg04537.html • Very useful for some deployment environments, need to decide how far to go • Proposal: • Support of Query is optional (response mandatory) • Define encapsulation format • Explain how to fill it in going only one IP hop • Define precedence w.r.t. downstream Query • Provide health warnings for more general usage

18. Message Formats • TLVs must be in order • Numerous clarifications to MRI format • Split NAO into NLI & SCD • Protocol identifiers vs. (IP) protocol numbers • Not going to discuss any more details here

19. Explanatory Material • Message Routing - 3.3 • Describes MRM concept in general • Sessions - 3.4 • Describes SIDs and their role • Message Type/Encapsulation - 5.5 • Explains how different messages can be encapsulated • State Formalism (outline) – 6 • Currently just STDs, will add tables and processing rules shortly

20. Layering/Extensibility • Removed text about NSLP versioning - C.1 • Specialised NSIS TLV format discussion to GIMPS – C.3 • Specialised Error object to GIMPS - C.4.10 • Open issue: Interface to extensibility draft

21. Layering I: NSLP Versions • Previous versions included text about NSLP versioning w.r.t. NSLPIDs • Not entirely clear that these statements were correct • Version -06 solves this by removing the text • Problem is shifted to extensibility draft • GIMPS knows about NSLPIDs • Related to RAO/NSLPID interactions (5.3.3)

22. Layering II: TLV Formats • Previous version asserted text of C.3 as defining TLV format (including A/B extensibility flags) for all parts of the NSIS protocol suite • Version -06 restricts the scope to GIMPS • Defines GIMPS handling of AB combinations {00, 01, 10} • Discussion of TLV format for NSLPs will be in the extensibility draft

23. Layering III: Error Object • Previous version included generic error object in C.5 • Version -06 restricts the scope of this object to GIMPS • Implication: error codes and classes are now GIMPS specific • Removed error-source-identifier element – all GIMPS messages have single-hop scope • Added new GIMPS-Error message type, still need encapsulation rules

24. Other Issues • Open issue: NAT traversal • Probably: create new draft? Also depends on implementation • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue22 • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue23 • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue24 • Open issue: MA Service demultiplexing • Probably: depends on implementation experiments • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue14 • Open issue: Error catalogue • Probably: will generate as by-product of message processing rules • Open issue: Protocol name • Probably: will leave it up to someone else • http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue1