GIMPS * – The NSIS Transport Layer draft-ietf-nsis-ntlp-06.txt Slides: 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)

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

Security Issues Analysis of cookie requirements includes abstract “example” Open issue: on-reverse-path threat issues/issue17 issues/issue17 Address validation /D.3 Open issue: channel security selection. issues/issue29 issues/issue29

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 issues/file1/GIMPS%20Cookies.htm issues/file1/GIMPS%20Cookies.htm

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

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

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.

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 …

"Transport" Issues Clarified rules for messaging association lifetime/refresh Open: API fix for Query & stateless handling issues/issue44 issues/issue44 Open: Epoch change monitoring issues/issue43 issues/issue43

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

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

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

Routing State Management Clarified rules for routing state lifetime/refresh Routing state now keyed by SID Open issue: “edge-probing” MRM issues/issue8 issues/issue8 Open issue: upstream Query for path-coupled MRM issues/issue19 issues/issue19

RSM I: Lifetime/Refresh Section 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.

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

RSM III: Edge-Probing MRM Still in Martin’s draft ommand=id_detail&id= ommand=id_detail&id= stiemerling-nsis-natfw-mrm-01.txt stiemerling-nsis-natfw-mrm-01.txt Propose to add new section Will have MRI format ( ) and Query encapsulation ( )

RSM IV: Upstream Query The ability to initiate routing state from the receiver Start at archive/web/nsis/current/msg04537.htmlhttp://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

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

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

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

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)

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

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

Other Issues Open issue: NAT traversal Probably: create new draft? Also depends on implementation Open issue: MA Service demultiplexing Probably: depends on implementation experiments 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