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:
Done
Submit 'Signaling Requirements' to IESG for publication as an
Informational RFC.
Done
Submit 'Next Steps in Signaling: Framework' to IESG for
publication as Informational RFC
Done
Submit 'Analysis of Existing Signaling Protocols' to IESG as
Informational RFC
Done
Submit 'RSVP Security Properties' to IESG as Informational RFC
Done
Submit 'NSIS Threats' to IESG as Informational RFC
Apr 05
Submit 'NSIS Transport Protocol' to IESG for publication for
Proposed Standard
May 05
Submit 'NSIS QoS Application Protocol' to IESG for publication
for Proposed Standard
May 05
Submit 'NSIS QoS Specification Template' to IESG for
publication as an Informational RFC
Jun 05
Submit 'NSIS Middle Box Signaling Application Protocol' to IESG
for publication for Proposed Standard
Sep 05
Submit 'Applicability Statement of NSIS Protocols in Mobile
Environments' to the IESG as an Informational RFC
Sep 05
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
Extensibility
-> 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.
Closeable issues
- D-mode encapsulation: working assumption is UDP
- source address selection
- firm up on RAO and NSLPID (affects load on non-interested routers)
Robert: Load sharing. However, problem is ICMP responses - if use flow source
address they go to flow source, not signalling source.
- message scoping: proposal: drop as potential GIMPS function, need common NSLP-level
object instead.
Henning: Agreed, could easily do it later with a local-interpretation label.
- special routing methods
NATFW reserve mode
explicit routing (make before break)
preconfigured routing in constraint topologies (DENY action in NATFW)
John: How many do we need?
Henning: explicit would be the most complicated
Allison: Don't put anything in that can't be supported with current deployed
protocols.
Robert: Like the functionality but hard to do in generic topologies.
- GIMPS aware NAT processing
already supported, could write it out to get reality check (quite complex)
- route change handling probably needs updating: architecture decision on which
layer to propagate route changes at.
- common NSLP functions
- others
IP TTL management and detection
general guidance on object ordering
lost GIMPS-confirm handling
NAT/Firewall NSIS Signaling Layer Protocol (NSLP) - 15 min (Martin)
- proxy mode
removed section on CREATE on previously pinned down path
- NOTIFY
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
message extensibility
overview picture
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)
- status
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
(asymmetry)
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
crucial.
Loose End Message Routing Method for NATFW NSLP - 5 min (Martin)
- new mrm
- context
data receiver behind NAT
must learn publicly reachable address
a NAT must be found somewhere upstream
- current approach
REA message, source DR, destination DS or DS* (opportunistic address)
-> easy solution from the first days: creates unneeded states, creates SA where
not needed, somehow a hack
- new method: new (loose end) mrm
only create on some boxes (only NATs)
could be NTLP extension
John: Proposal? In base NTLP document or NSLP?
Robert: Would put it in NTLP document.
John: General useful?
Robert: Would put it in NTLP anyway but is general method to find last node in
some direction.
- implementation status: prototype available, will update by december/january.
Will have NTLP implementation by then as well.
- present mobility effects on GIMPS and NSLPs for basic scenarios
- identified issues
different types of crossover nodes
CRN discovery
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)
problem statement
- multi-link case: multi-homing with different session ID?
James: Why only one flow ID can be used per port? Not my understanding of spec.
Robert: Flow ID can only list one port. You can't use ranges.
James: Propose to have multiple flows over different ports for an application?
To different IP addresses or same IP addresses?
Takako: Yes. Both cases.
James: Work in SCTP on one logical flow to different IP addresses, this is not a
good idea. Need to think more deeply about this from congestion control
perspective.
Hannes: Does your proposal try to make the flow identifier more flexible?
Robert: Have gone one step beyond RSVP by separating session from flow but how
far can we go (do we want to go). Need to understand where to stop.
John: Cost-benefit analysis is needed. Good discussion for mailing list. Look at
effects on NTLP/NSLP.
Henning: Multiple ports and multiple IP addresses, might even go in different
directions.
Fred: Wildcard case in RSVP. Felt we needed routing object to handle it, may
need that here as well.
Internet Routing Dynamics and NSIS Related Considerations - 10 min (Charles
Shen)
- results
route prevalence and route persistence: paths strongly dominated by single
route, significant site-to-site variations, suggests nsis could benefit from
adaptive approaches
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
this?
Slides are available at
http://www.tschofenig.com/nsis/IETF61/IETF61-draft-ietf-nsis-qos-nslp-05.ppt
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
peer-to-peer
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)
- Goal: configuration of metering entities along the data path
- similar to QoS NSLP
- main differences:
* need to drop out of session
* need to be able to get back in
John: Continue to work on it as individual draft, might recharter after NTLP
completion
Juergen Quittek: Showed commonalities, more important to see problems
Elwyn: Have you looked at Real-Time Flow Measurement
?
Cornelia: Yes, but not at thsi point yet.
Juergen
Quittek: Not useable here, MIB is too complicated too use.
Elwyn: Benchmarking working group might be interested as well.
- not planning to share code but could share traffic dumps, ...
- would like to share packets
- do we want test NSLP
- need administrative stuff (protocol numbers page, implementers' mailing list)
John: Will set up list, Robert to come up with example protocol numbers page.