GIMPS – The NSIS Transport Layer

draft-ietf-nsis-ntlp-02.txt Slides: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-

02.ppt

Robert Hancock, Henning Schulzrinne (editors)

NSIS Interim MeetingRoke Manor Research, U.K.

June 2004

Overview

Status Issues closed Additions Issues to close (we hope) Issues still open (problematic ones)

Includes issues being ignored for now Next steps

Status

Version -02 release literally days ago Accounts for early review comments

See accompanying email and change log Closes some open issues of detail New material on formats and API etc. Modified description of message routing Initial proposal on protocol negotiation

Early Review Comments From Alex (see http://www.tschofenig.com/nsis/IETF59/nsis-zinin-ietf59.ppt) Q: Why per-flow routing info in NTLP? A: More explanation added at end of 4.1.1 Q: Suggests flow based routing? A: This is a misunderstanding; in any case, related developments have changed the text (see change number 6)

From Dave (see http://www.ietf.org/mail-archive/web/nsis/current/msg03809.html) Q: Flow definition excludes multicast, splitting A: Definitions modified, see change number 1 Q: How do you handle not-on-path proxies A: We don't - clarified proxy definition in 3.2 Q: Why a hop count rather than a VIA header? A: The rationale is in the mailing list archive for March; we haven't put this in the document in the interest of

brevity. (However, there is improved text on loop handling, see change number 8) Q: The D-mode messages have to follow the data flow A: Yes, existing text on the subject has been gathered (from the rest of the document) into section 5.3 Q: Does having GIMPS do NAT traversal hijack signaling application role? A: This is still open for discussion. The text in section 6.3 is clear on this. It needs discussion with the NATFW

people (i.e. it is not just a GIMPS issue); at the moment, the NATFW NSLP regards handling NAT traversal aspects of non-NATFW NSLPs as out of scope, so the boundary is consistent

Q: Tunneling nit A: Text in 6.4 adjusted accordingly Q: Does 8.2 really rule out raw-IP? A: The text in 8.2 on the subject has been expanded to say why. Q: Aggregation is per-interface, not per-node A: Text in 8.4 on aggregation handling adjusted accordingly

Closed Issues

Closed Issue: Teardown Was section 8.7 in -01 draft Q: Should there be a GIMPS message which

says ‘remove state for flow/session XXX’? A: No. Rationale:

GIMPS state is cheap, soft-state should be OK even with long timers

NSLP state is expensive (and can be torn down by signalling application messages)

The NSLP can indicate to GIMPS locally that state is no longer needed

Securing the transaction is tricky You could add it later if you wanted it

Closed Issue: Single Shot Message Support Was 8.8 in -01 draft Q: Should there be a special class of message

transfer for reliable, secure single message delivery

A: No. Rationale: Doing this properly may not be much more

lightweight than the full C-mode experience Once retransmission and backoff are accounted for

It’s just an optimisation over standard C-mode API allows GIMPS to know when this might be useful

the possibility You could add it later (given D-mode negotiation)

Closed Issue: Mandatory Reverse Routing State Was 8.10 in -01 draft Q: Does a GIMPS node always store

reverse routing state for a flow, or only if an NSLP wants it to?

A: The latter. Rationale: This was always the intention. The

issue was a hangover from old considerations about how to handle intermediaries (-00 version)

New Material

General Bit Level Formats New in -02; additional material in Appendix C

Follows discussion between NSLP & GIMPS authors Highlights:

NSLP message header = message type & flags only Version implicit in NSLPID

Objects are Type-Length-Value Type is a flat space (common to all of NSIS) Length = number of 32 bit words in Value Any padding defined in Type-specific Value format

Errors are carried in an object with Type=“Error” Value field contains a severity level, error number, and

number-specific information Open issues in 8.11

Abstract GIMPS API (I) New Appendix D

Strictly informational: purpose is to firm-up functional split between NSLPs and GIMPS, not to define interface

GIMPS design decisions are (mostly) not visible e.g. C/D-mode distinction, GIMPS hop count

Overall, structured like ‘very clever’ UDP sockets API More control parameters, more event

notifications

GIMPS API (II): Primitives

SendMessage parameters: NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, NSLP-Id, Session-ID, MRI, Direction, SII-Handle, Transfer-Attributes, Timeout, IP-TTL

RecvMessage parameters: [NSLP-Data, NSLP-Data-Size,] NSLP-Id, Session-ID, MRI, Direction, SII-Handle, Transfer-Attributes, IP-TTL, Original-TTL

Bold parameters are the ones that change from message to message (mostly)

Any NSLP

GIMPS

SendMessage

MessageReceived

SetStateLifetime

RecvMessage

MessageDeliveryError

NetworkNotification

SecurityProtocolAttributesRequest

GHC and IP-TTL Handling Cleaned up as a result of message looping discussion

[Conclusion of discussion: counters are preferred over Via-header; recorded route could also be examined if present]

Details are in section 4.2.4 Need to handle RAO/NSLPID mismatch Need to allow for fast-path implementation differences

RAO NSLPID TTL GHC

No match Can’t happen Decrement; forward message

Ignore

Match No match Decrement; forward message

Decrement

Match Match Locally delivered Decrement

C-Mode Protocol Negotiation A lot of options are conceivable

Several cannot be ruled out permanently Several are potentially useful optimisations

Security protocol negotiation introduces its own vulnerabilities Very hard to introduce in a backwards

compatible way Strategy: Define a simple negotiation

mechanism initially and postpone extensions Concepts based on IKE, SIP security agreement

New section 6.6

Protocol Negotiation Overview Stack-proposal:

sequence of profiles Profile: stack of

protocol-layers Protocol-layer: protocol

name and security / configuration options

Add new setup mechanisms by defining new protocol-layers

Addressing information in a separate object

Mutable for NAT traversal

Querying Node

Responding Node

GIMPS-Query: stack-proposal-Q(fixed for interface and NSLPID)

GIMPS-Response: stack-proposal-R(fixed for interface and NSLPID)

Handshake: echo stack-proposal-R

Message Routing Methods Multiple possible ways for GIMPS to route a

signalling message Current case: “follow the path of the flow with this flow

identifier” Also discussed: “find the next NAT in the direction of

X”, explicit routing, etc. Two ‘presentational’ changes

Rename FRI MRI, current case of MRI includes Flow Identifier

Clearly identify parts of the protocol specification which depend on the message routing method

No new message routing methods defined so far!

How to define a new MRM Steps tentatively outlined in section 8.9

Define the format of the MRI for the new message routing method type.

Define how D-mode messages should be encapsulated and routed corresponding to this MRI.

Define any filtering or other security mechanisms that should be used to validate the MRI in a D-mode message.

Define how the MRI format is processed on passing through a NAT.

May still need some fine tuning and tidying Still need to decide whether to introduce new

ones

Issues on the Verge of Closure?

RAO and NSLP Considerations Issue is discussed in section 8.4

Reflects sensitivity of interception discussion Trade off between coarse-grained RAO

allocation (“any NSIS message”) and fine-grained (“exactly this NSLP”)

Still needs translation into IANA language Still needs discussion on aggregation level

issue (cf. RSVP vs. RSVP_E2E_IGNORE)

MA Flexibility Open issue on stacking issues in 8.5 and

setup flexibility in 8.6 Proposal: agree the negotiation

mechanism (needed anyway) Then, defer all but the simplest stacking

capabilities and setup sequences Still need to check node ability to

implement sensible policies On re-use of associations, multiple

associations, ...

Open Issues

Special Routing Requirements

Discussed in section 8.9, including: To support NATFW “Reserve” mode

MRM = send towards any public IP address

Needed? What are the MRM attributes? Explicit routing

Discussed on mailing list Not clear if this is relevant to NSIS

Not planning to develop NSIS-TE any time soon

D-Mode Encapsulation

Discussed in section 8.3 Need to firm up on UDP vs. raw IP

(or not) Need to firm up on source IP

address selection Flow source address or signalling

source address? (Or both?)

NSIS-Unaware NATs Probably a tricky subject To make progress:

Need to adopt some general starting point Specifically: work out how to re-use STUN?

What about other transport encapsulations? Need to work out what classes of NAT

behaviour to support Symmetric, cone, ... Depends on likely prevalence in deployment?

Message Scoping Discussed in section 8.7 Scoping is about helping NSLPs send

messages like “Send this as far as the edge of this network but no further” Cf. sending to the edge of an

aggregation region Could be punted purely up to NSLPs

Issue is robustness in partial deployments

Message Encoding

Discussed in section 8.11 (cf. Appendix C) Object ordering: fixed or free (or in-

between?) Capability encoding: how to signal

mandatory/optional/whatever aspects Affected by adoption of shared object

space Lessons from SIP? Diameter?

Common NSLP Functions Discussed extensively on mailing list.

Current possibilities: Precedence and pre-emption (!) Reserve/commit separation Fate sharing between flows, applications AAA interactions Route recording and other diagnostics Resource sharing

None are being addressed in GIMPS

Next Steps

Plans for San Diego Finalise if possible the ‘nearly closed’

issues Look for at least a pro/con evaluation on

some of the problematic issues Expert review might be nice Aim to have a simple question to be answered

Make real progress on the NAT issue and error conditions (not complete solution)

Validate the API (by NSLP authors, I hope)

Status after San Diego??

Something implementable Possibly by imaginative software

engineer? Timetable for WG snapshot?

Unofficial status Any other priorities?