The Next Steps in Signaling Working Group is responsible for standardizing an IP signaling protocol with QoS signaling as the first use case. This working group will concentrate on a two-layer signaling paradigm. The intention is to re-use, where appropriate, the protocol mechanisms of RSVP, while at the same time simplifying it and applying a more general signaling model.
The existing work on the requirements, the framework and analysis of existing protocols will be completed and used as input for the protocol work.
NSIS will develop a transport layer signaling protocol for the transport of upper layer signaling. In order to support a toolbox or building block approach, the two-layer model will be used to separate the transport of the signaling from the application signaling. This allows for a more general signaling protocol to be developed to support signaling for different services or resources, such as NAT & firewall traversal and QoS resources. The initial NSIS application will be an optimized RSVP QoS signaling protocol. The second application will be a middle box traversal protocol. An informational document detailing how Differentiated Services can be signaled with the QoS Signaling protocol will be made.
Security is a very important concern for NSIS. The working group will study and analyze the threats and security requirements for signaling. Compatibility with authentication and authorization mechanisms such as those of Diameter, COPS for RSVP (RFC 2749) and RSVP Session Authorization (RFC 3250), will be addressed.
It is a non-goal of the working group to develop new resource allocation protocols. Traffic engineering is out of scope of this WG. Additionally, third party signaling is out of scope of this WG. New mobility and AAA protocols are out of scope of the WG. However, the work produced in this Working Group should work with existing IETF mobility and AAA protocols, including (but not limited to) Mobile IP, Seanoby Context Transfer, etc. An applicability statement will be written to discuss the applicability of NSIS protocols in mobile environments.
NSIS also welcomes participation and expression of requirements requirements from non-IETF standards organization members, for instance 3GPP, 3GPP2 and ITU-T.
Goals and Milestones:
Submit 'Signaling Requirements' to IESG for publication as an
Submit 'Next Steps in Signaling: Framework' to IESG for
publication as Informational RFC
Submit 'Analysis of Existing Signaling Protocols' to IESG as
Submit 'RSVP Security Properties' to IESG as Informational RFC
Submit 'NSIS Threats' to IESG as Informational RFC
Submit 'NSIS Transport Protocol' to IESG for publication for
Submit 'NSIS QoS Application Protocol' to IESG for publication
for Proposed Standard
Submit 'NSIS QoS Specification Template' to IESG for
publication as an Informational RFC
Submit 'NSIS Middle Box Signaling Application Protocol' to IESG
for publication for Proposed Standard
Submit 'Applicability Statement of NSIS Protocols in Mobile
Environments' to the IESG as an Informational RFC
Submit 'Differentiated Service Signaling on the Internet' to
the IESG for publication as an Informational RFC
Changes in -04
- API validated by NSLP designers
- message format tweaks, new error object
- outline of IANA section content
- completed negotiation protocol description
- text on retransmission and rate limiting
-> NSLP must define how flags can be set
- current status: more or less like RSVP, using 2 bits
- using refresh class requires security awareness
- using mandatory class is not mandatory (can be negotiation/policy decision)
Protocol design finalization
Topics not yet addressed
- GIMPS unaware NATs: Give up? Document?
Henning: Can't do anything about internals. Propose to focus on NAT traversal at
transport layer itself.
Robert: Biggest problems is IP source address selection.
Hannes: Suggest to look at text in migration document
Robert: Need to scope down the problem.
- D-mode encapsulation: working assumption is UDP
- source address selection
- firm up on RAO and NSLPID (affects load on non-interested routers)
- proxy mode
removed section on CREATE on previously pinned down path
Robert: How do you know the notify address is reachable?
Martin: Agree, propose to remove.
What direction should they be sent?
- Close pinholes: is closing firewall pinholes a useful functionality? Does it
apply to NAT as well?
Hannes: Doesn't work in generic case, but seemed useful in discussion.
John: Need to work more on this and get input from the group.
Robert: No solution for this, except in constrained topologies
Hannes: Some proposals exist in the research area (e.g., secure i3, Hi3).
- Open issues
discussion about firewall/NAT state transfer: requested for mobile hosts
other open issues in NATFW NSLP issue tracker
Security Threats for the NATFW NSLP - 5 min (Hannes)
update with 1 new threat
in the document: number of threats, requirements derived from them, some threats
cannot be addressed in NSIS
- particular threat: routing asymmetry
sender not authorised to open pinhole, receiver not sure which one to open on
how does receiver know there is a sender that isn't authorised
proposal: delay authorisation
problem: no meaningful end-to-end security mechanism in NSIS
- next steps
GIMPS security between NSLP neighbours
AAA between non-neighbouring nodes
Martin: Support view: important to read and comment. Security solution is
Loose End Message Routing Method for NATFW NSLP - 5 min (Martin)
- present mobility effects on GIMPS and NSLPs for basic scenarios
- identified issues
different types of crossover nodes
path update/local repair operations are different
CRN more easily detected at GIMPS layer
path update may lead to signalling overhead and latency
immediate removal of state on old path is not always desired
John: Open issues should be discussed on mailing list
Mobile IPv6 - NSIS Interaction for Firewall traversal - 15 min (Franck Le)
route prevalence and route persistence: paths strongly dominated by single
route, significant site-to-site variations, suggests nsis could benefit from
different types of route changes: location, timing, ...majority without total
hop count change, caused by route splitting and load balancing (splitting:
second-order route changes)
- accuracy of measuring path characteristics
- impact of multi-homing
- NSIS concerned route changes
inter-AS route changes
intra-AS route changes: ingress, egress, midpoint
mixed deployment model likely:
1) AS model: central NE in each AS
2) entry model
3) border nmodel
4) edge model
- goal: secure communication layer for unreliable datagram transport
- TLS only works over reliable transport
- approach: DTLS, as close as possible to TLS as possible because easy to work
with and easy to deploy.
* minimal required changes
* avoid making improvements
- same protocol flow as TLS
- provide reliability for the handshake phase
- stateless processing of application data records
* one thing had to be thrown away: support for stream ciphers
=> same key management, very similar API, can import TLS extensions easily and
easy to build based on TLS implementation
But: only TLS authentication mechanisms, session oriented (messages not
standalone, need handshake first), two-party
Question: does it make sense for NSIS?
Hannes: Perfect choice for NSIS, because hop-by-hop and disadvantages are not
really a disadvantage
Bob Braden: Might want to add congestion control (DCCP). Have you thought about
Slides are available at
Sven goes through an overview of the main changes in -05:
additional ack mechanisms
information on using gimps service interface
added default for refresh timer
mailing list discussion: add default state installation ack
flag to get explicit confirmation from next hop
explicit feedback mechanism for faster recovery on route change
thought experiment on extensibility flags
look at how flags might map to objects qos nslp
some resultant questions:
are these extensibility flags or criticality flags?
do they apply only to later extensions to the protocol?
should all objects in the base spec be C (critical)?
what do the flags apply to?
are flag settings bound to the object type?
can you, e.g., apply different flag combinations to object depending on message
that it is being used in?
might you set different flags based on object contents?
AAA - long standing next steps point
not progressed very far
John: what part of AAA are you looking at?
Hannes: should say "authentication"
Sven: authentication/authorisation -
2-party/3-party - does not affect qos nslp
Hannes: makes a difference from a framework perspective, but not basic protocol
Sven: reuse of GIMPS channel security is possible if connection mode and
main issue is gimps service interface
Bob: What about COPS?
Hannes: sven is talking about qosnslp, not backend reference to third party
Bob: another word you need to mention is policy;
Sven: other mechanisms:
token-based approach - not much needed from qos nslp
eap-encapsulation approach (from authz i-d)
next steps: progress aaa, clarify qspec/qsp, review/comment on state diagrams
QoS-NSLP Qspec Template - 15 min (Cornelia Kappler)