GIMPS * – The NSIS Transport Layer draft-ietf-nsis-ntlp-04.txt Slides: Robert Hancock, Henning Schulzrinne (editors) IETF#61 – Washington November 2004 * (insert favourite protocol name here, if you can think of one)

Overview Status What has changed since August Issues Protocol extensibility (still) Design finalisation (including security issues) Other open points Minor/closable issues (we hope) Next steps

Status API validated by NSLP designers Some minor tweaks and extensions Message format tweaks; new error object Different structure of ABNF description Extensibility flags (see later) Outline of what needs to be in IANA section Completed protocol negotiation description Re-written (clearer!) text on association setup rules and message sequences Added text on retransmission and rate limiting

Major Issue 1: Protocol Extensibility

Different rules for where messages should go (includes signalling about new types of flow)  Add new MRM Additional transport/security protocol performance  Add new protocol layer, extend SP and NAO formats Do something we can’t even imagine yet  Make a new NTLP Add new data types to a message  Define a new TLV (or use an existing one from another NSLP) Add new (usually optional) protocol operations  Define a new message type Do something we can’t even imagine yet  Make a new NSLP (Do anything you like within the overall NSIS structure) This is where the question of ‘extensibility flags’ (to influence processing of ‘new’ objects) comes in Extend GIMPS Extend an NSLP Add an NSLP Extend NSIS Extensibility in NSIS Versioning issue

Object Extensibility Discussed in Appendix C.3.2 Capability encoding: how to signal mandatory/optional/whatever aspects in new objects Lessons from SIP/Diameter/IPv6/RSVP/… Discovered ~10 flags people might like to set A GIMPS problem because of the shared object space i.e. GIMPS spec will have the IANA words for “Type” Most issues aren’t relevant to GIMPS directly NSLPs must define how they are allowed to set and interpret these flags (GIMPS must too)

Current Status From C.3.2 (roughly), leading 2 bits of “type” field are interpreted as follows: 00 (Mandatory): If the object is not understood, the entire message containing it must be rejected with an error indication. 01 (Ignore): If the object is not understood, it should be deleted and then the rest of the message processed as usual. 10 (Forward): If the object is not understood, it should be retained unchanged in any message forwarded as a result of message processing, but not stored locally. 11 (Refresh): If the object is not understood, it should be incorporated into the locally stored signaling application state for this flow/session, forwarded in any resulting message, and also used in any refresh or repair message which is generated locally.

Rationale Looks like 2205+, using leading 2 bits of type field as indicator RSVP defined 3 extension classes All 3 got used; some specs used all 3 at once Could do with more background info on the subject But: NSIS layering means RSVP experience not directly applicable Mailing list discussion to split one class Using ‘refresh’ class needs security awareness Using ‘mandatory’ class is not mandatory Can always discover/negotiate extended capabilities as a policy in the NSLP design instead

Major Issue 2: Protocol Design Finalisation (Not so much an open issue as ‘work to be getting on with’)

Background Basic structure of protocol operation not changed for 4 months Mainly refinements, clarifications, isolating particular corner cases, extensibility Time to get a bit more formal Message processing/State transition rules Denial of service/overload analysis Error conditions and notifications Integrating channel security

Activities Define message processing rules & state transition diagrams Input from reference implementation Input to MPRs and informative text on cookie handling Revised API and additional protocol layer descriptors New “dense” specification section 6-ish Overview of error conditions, protocol parameters Security analysis Two aspects: Denial of service/overload handling Channel security integration

Other topics not yet addressed

GIMPS-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?

Minor/Closable Issues

D-Mode Encapsulation Discussed in section 9.2/9.3/9.4 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?) Need to firm up on RAO/NSLPID IANA considerations

Message Scoping Discussed in section 9.6 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 Related issue: knowing what scope a message came from Could be punted purely up to NSLPs Issue is robustness in partial deployments Even that can be fixed by allowing GIMPS to do filtering Different NSLPs will have different boundaries anyway Proposal: drop as a potential GIMPS function Need a common NLSP-level object instead

Special Routing Methods Discussed in section 9.7/9.8, including: To support NATFW “Reserve” mode MRM = send towards a public IP address See Martin’s draft (later?) Explicit routing TE-like usage is probably not relevant to NSIS Make-before-break/pre-installation may be relevant (for mobile or high-availability requirements) Preconfigured routing in constrained topologies May be needed for NATFW “Deny” action

GIMPS-Aware NAT Processing The objects exist in the specification to make traversal possible Most details of the objects are left opaque Precise NAT processing doesn’t change the rest of the protocol Actual processing example could be written up to get a reality check The detailed transformation rules are quite complex May want to cross-check NAT binding management model with NATFW NSLP

Route-Change Handling General discussion in section 6.1 probably needs updating Comparison with expectations of NSLP authors What is provided by GIMPS vs. what they have to do Looking for detailed analysis and comments from ‘mobility and multihoming gang’ Also, architecture decision on which layer to propagate route change notifications at In fact, applies to error conditions in general

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 Message scoping None are being addressed in GIMPS

Others Protocol name: discussed in section 8.1 And periodic mailing list flurries IP TTL management and detection Proposal: this is needed Just need to work out the details General guidance on object ordering Lost GIMPS-confirm handling

Next Steps

General Message The basic protocol structure is just about finalised Remaining questions have generally isolated impact, or are implementation issues … we hope (with some justification: e.g. NAT work has happened in background) Refinements will take place as a result of Paper validations (mobility work, NSLP checking) Experimental implementations (started already)

Next Priorities Design finalisation Need some decisions on specification structure and level of detail In parallel with implementation work See later Further input on any of the other open issues is always appreciated!