Robert Hancock, Henning Schulzrinne (editors) NSIS Interim Meeting – Munich May 2005
Post on 14-Jan-2016
48 Views
Preview:
DESCRIPTION
Transcript
GIMPS* – The NSIS Transport Layer
draft-ietf-nsis-ntlp-06.txt Slides: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-
06.ppt
Robert Hancock, Henning Schulzrinne (editors)
NSIS Interim Meeting – MunichMay 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 - 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
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
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
iMac
Bad
Guy
Her
e
GIMPS-Query
GIMPS-Response
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 - 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-ntl
p-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 - 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-ntl
p-issues/issue19
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.
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 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)
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
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 - 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
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 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
top related