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