Date post: | 30-Dec-2015 |
Category: |
Documents |
Upload: | mary-mitchell |
View: | 217 times |
Download: | 3 times |
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?