| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 21, 2008.
The Next Steps in Signaling (NSIS) Working group was officially formed in November 2001 to standardize a new IP signaling protocol suite. Six years have now passed and the first actual protocol specifications have been finalized. The purpose of this draft is to give an overview of what has been achieved, how the industry can make use of the new protocols, and how the research community can further extend the designs.
1.
Introduction
2.
The NSIS Architecture
3.
The General Internet Signaling Transport
4.
Quality of Service NSLP
5.
NAT/Firewall Traversal NSLP
6.
Deploying the Protocols
6.1.
Obstacles
7.
Security Features
8.
Extending the Protocols
8.1.
GIST
8.2.
QoS NSLP
8.3.
NAT/Firewall NSLP
8.4.
New NSLP protocols
9.
Security Considerations
10.
Acknowledgements
11.
References
11.1.
Normative References
11.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The Transport Area Directors held a Next Steps in Signaling (NSIS) birds of a feather session on Wednesday 21st March 2001 at the 50th IETF meeting in Minneapolis. The goal of the session was to discuss and gather an initial set of requirements for a next generation Internet signaling protocol suite as it was felt that the current RSVP-based solutions have short-comings, e.g., with respect to mobility or QoS interoperability. The NSIS Working Group was officially formed later that year, in November 2001 and had its first meeting at the IETF 52 in Salt Lake City in December 2001.
The initial charter of NSIS was focused on QoS signaling as the first use case, taking RSVP as the background for the work. In May 2003, middlebox traversal was added as an explicit second use case. The requirements for the new generation of signaling protocols are documented in [RFC3726] (Brunner, M., “Requirements for Signaling Protocols,” April 2004.) and an analysis of existing signaling protocols can be found in [RFC4094] (Manner, J. and X. Fu, “Analysis of Existing Quality-of-Service Signaling Protocols,” May 2005.).
The design of NSIS is based on a two-layer model, where a general signaling transport layer provides services to an upper signaling layer. The design was influenced by Bob Braden's Internet Draft entitled "A Two-Level Architecture for Internet Signaling" [I‑D.braden‑2level‑signal‑arch] (Braden, R. and B. Lindell, “A Two-Level Architecture for Internet Signaling,” November 2002.).
This document gives an overview of what the NSIS framework is today, provides help and guidelines to the reader as to how NSIS can be used in an IP network, and how the protocol can be enhanced to fulfill new use cases.
| TOC |
The design of the NSIS protocol suite reuses ideas and concepts from RSVP but essentially divides the functionality into two layers. The lower layer, the NSIS Transport Layer Protocol (NTLP), is in charge of transporting the higher layer protocol messages to the next signaling node on the path. This includes discovery of the next hop NSIS node, which may not be the next routing hop, and different transport services depending on the signaling application requirements. The General Internet Signaling Transport (GIST) is the protocol that fulfills the role of the NTLP. The NSIS suite supports both IP protocol versions, IPv4 and IPv6.
The actual signaling application logic is implemented in the higher layer of the NSIS stack, the NSIS Signaling Layer Protocol (NSLP). While GIST is only concerned in transporting NSLP messages between two end-points, the end-to-end signaling functionality is provided by the NSLP protocols if needed - not all NSLP protocols need to perform end-to-end signaling, even the current protocols have features to confine the signaling to a limited path. Two NSLP protocols are currently standardized: one concerning Quality of Service signaling and one for NAT/Firewall traversal.
A central concept of NSIS is the Session Identifier (SID). Signaling application states are indexed and referred to through the SID. This decouples the state information from IP addresses, allowing dynamic IP address changes for signaling flows, e.g. due to mobility: changes in IP addresses do not force complete tear down and re-initiation of a signaling application state, merely an update of the state parameters.
The SID is not meaningfull by itself, but is rather used together with the NSLP identifier (NSLPID) and the Message Routing Information (MRI). This 3-tuple is used by GIST to index and manage the signaling flows.
The following design restrictions were imposed for the first phase of the protocol suite. They may be lifted in future and new functionality may be added into the protocols at some later stage.
The key documents specifying the NSIS protocol suite are:
The next three sections provide a brief survey of GIST, QoS NSLP, and NAT/FW NSLP.
| TOC |
The General Internet Signaling Transport (GIST) [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.) provides a signaling transport service to NSIS Signaling Layer Protocols (NSLP). GIST does not define new IP transport protocols but rather makes use of existing protocols, such TCP and UDP. Applications can indicate the desired reliability, e.g., unreliable or reliable, and GIST then uses the most appropriate transport protocol to achieve the goal. If applications request also security, GIST uses TLS. The GIST layered protocol stack is shown in Figure 1 (The NSIS protocol stack).
+-----+ +--------+ +-------+
| | | | | |
| QoS | | NAT/FW | | ... | NSLP
| | | | | |
+-----+ +--------+ +-------+
----------------------------------------------------------------------
+--------------------------+
| |
| GIST | NTLP
| |
+--------------------------+
----------------------------------------------------------------------
+--------------------------+
| TLS |
+--------------------------+
+--------------------------+
| TCP | UDP | SCTP | DCCP |
+--------------------------+
+--------------------------+
| IPsec |
+--------------------------+
+--------------------------+
| IPv4(+RAO) | IPv6(+RAO) |
+--------------------------+
| Figure 1: The NSIS protocol stack |
When an NSLP application wants to send a message to its next peer, GIST starts discovering the next signaling node by sending a Query message towards the destination of the related data flow. This Query carries the NSLP identifier (NSLP ID) and Message Routing Information (MRI) among others. The MRI contains enough information to route the signaling message, e.g., information about the actual data flow that is signaled for. The next GIST node on the path receives the message and if it is running the same NSLP, it provides the MRI to the NSLP application and requests it to make a decision on whether to peer with the querying node. If the NSLP application chooses to peer, GIST sets up a Message Routing State (MRS) between the two nodes for the future exchange of NSLP data. State setup is performed by a three-way handshake that allows for negotiation of signaling flow parameters and provides counter-measures against several attacks like denial-of-service by using cookie mechanisms and a late state installation option.
If a transport connection is required and set up for reliable or secure signaling, like TCP or TLS/TCP, a Messaging Association (MA) is established between the two peers. An MA can be re-used for signaling messages concerning several different data flows, i.e., signaling messages between two nodes are multiplexed over the same transport connection. This can be done when the transport requirements (reliability, security) of a new flow can be met with an existing MA, i.e., the security and transport properties of an existing MA are equivalent or better than what is requested by the new MA.
For path-coupled signaling, we need to find the nodes on the data path that should take part in the signaling of an NSLP and invoke them to act due to arrival of such NSLP signaling messages. The basic concept is that such nodes along a flow's data path intercept the corresponding signaling packets and are thus discovered automatically. GIST uses by default the Router Alert Option (RAO) in Query messages to tell a receiving router that the packet must be inspected and possibly taken out of the fast path. This is the the same mechanism as in RSVP. Different RAO values can be used to indicate the actual NSLP being signaled, thus, making it possible for routers to leave the packet in the fast path if the right NSLP protocol is not available on the router; only a router that runs GIST and the corresponding NSLP will take the packet out of the fast path, and start processing it within GIST. Further intentional bypassing of signaling nodes can be accomplished either in GIST or in the NSLP.
Since GIST carries information about the data flow inside its messages (in the MRI), NAT gateways must be aware of GIST in order to let it work correctly. GIST provides a special object for NAT traversal so that the actual translation is disclosed if a GIST-aware NAT gateway provides this object.
GIST may use different triggers in order to detect a route change. It probes periodically for the next peer by sending a GIST Query, thereby detecting a changed route and GIST peer. GIST monitors routing tables, the GIST peer states, and notifies NSLPs of any routing changes. It is up to the NSLPs to act appropriately then, if needed, e.g., by issuing a refresh message.
In summary, GIST provides several services in one package to the upper layer signaling protocols:
| TOC |
The Quality of Service (QoS) NSIS Signaling Layer Protocol (NSLP) establishes and maintains state at nodes along the path of a data flow for the purpose of providing some forwarding resources for that flow. It is intended to satisfy the QoS-related requirements of RFC 3726 [RFC3726] (Brunner, M., “Requirements for Signaling Protocols,” April 2004.). No support for QoS architectures based on bandwidth brokers is currently included.
The design of the QoS NSLP is conceptually similar to RSVP, RFC 2205 [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.), and uses soft-state peer-to-peer refresh messages as the primary state management mechanism (i.e., state installation/refresh is performed between pairs of adjacent NSLP nodes, rather than in an end-to-end fashion along the complete signaling path). The QoS NSLP extends the set of reservation mechanisms to meet the requirements of RFC 3726 [RFC3726] (Brunner, M., “Requirements for Signaling Protocols,” April 2004.), in particular support of sender or receiver-initiated reservations, as well as, a type of bi-directional reservation and support of reservations between arbitrary nodes, e.g., edge-to-edge, end-to-access, etc. On the other hand, there is currently no support for IP multicast.
A distinction is made between the operation of the signaling protocol and the information required for the operation of the Resource Management Function (RMF). RMF-related information is carried in the QSPEC (QoS Specification) [I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.) object in QoS NSLP messages. This is similar to the decoupling between RSVP and the IntServ architecture, RFC 1633 [RFC1633] (Braden, B., Clark, D., and S. Shenker, “Integrated Services in the Internet Architecture: an Overview,” June 1994.). The QSPEC carries information on resources available, resources required, traffic descriptions and other information required by the RMF.
QoS NSLP supports different QoS models, because it does not define the QoS mechanisms and RMF that have to be used in a domain. As long as a domain knows how to perform admission control for a given QSPEC, QoS NSLP actually does not care how the specified constraints are enforced and met, e.g., by putting the related data flow in the topmost of four DiffServ classes, or by putting it into the third highest of twelve DiffServ classes. The particular used QoS configuration is up to the network provider of the domain. The QSPEC can be seen as a common language to express QoS requirements between different domains and QoS models.
In short, the functionality of the QoS NSLP includes:
| TOC |
The NAT/Firewall Traversal NSLP [I‑D.ietf‑nsis‑nslp‑natfw] (Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, “NAT/Firewall NSIS Signaling Layer Protocol (NSLP),” April 2010.) lets end-hosts interact with NAT and firewall devices in the data path. Basically it allows for a dynamic configuration of NATs and/or firewalls along the data path in order to enable data flows to traverse these devices without being obstructed. For instance, firewall pinholes could be opened on demand by authorized hosts. Furthermore, it is possible to block unwanted incoming traffic on demand, e.g., if an end-host is under attack.
Basically NATFW signaling starts at the data sender (NSIS Initiator) before any actual application data packets are sent. Signaling messages may pass several NATFW NSLP-aware middleboxes (NSIS Forwarder) on their way downstream and usually hit the receiver (being the NSIS Responder). A proxy mode is also available for cases where NATFW is not fully supported along the complete data path. NATFW NSLP is based on a soft-state concept, i.e., the sender must periodically repeat its request in order to keep it active.
Additionally, the protocol also provides functions for receivers behind NATs. The receiver may request an external address that is reachable from outside. The reserved external address must, however, be communicated to the sender out-of-band by other means, e.g., by application level signaling. After this step the data sender may initiate a normal NATFW signaling in order to create firewall pinholes.
| TOC |
First of all, NSIS implementations must be available in the corresponding network nodes (i.e., routers, firewalls, or NAT gateways) and end-hosts. That means not only GIST support, but also the NSLPs and their respective control functions (such as a resource management function for QoS admission control etc.) must be implemented. In dependence on the specific NSLP, scenarios are also supported where only one end-host is NSIS-capable and the end-host on the other is not NSIS-capable. This is usually accomplished by performing some kind of proxying functions in the domain of the responding end-host.
Another important issue is that applications must be made NSIS-aware, thereby requiring some effort on the applications programmer's side. Yet, it is possible to implement separate applications to control, e.g., the network QoS requests or firewall holes.
| TOC |
As there is network equipment with broken implementations of the Router Alert Option deployed, there may be some obstacles for initial deployment due to this legacy equipment. For controlled environments an operation without RAO is also possible as GIST uses a specific UDP port and a special magic number in order to detect Query signaling messages reliably.
NAT gateways and firewalls may also hinder initial deployment of NSIS protocols as they may either filter signaling traffic or perform NSIS-unaware address translations.
| TOC |
Basic security functions are provided at the GIST layer, e.g., protection against some blind or denial-of-service attacks. Conceptually it is difficult to protect against on-path attacker and man-in-the-middle attacks, because a basic functionality of GIST is to discover yet unknown signaling peers. Transport security can be requested by signaling applications and is realized by using TLS between signaling peers, i.e., authenticity and confidentiality of signaling messages can be assured between peers. GIST allows for mutual authentication of the signaling peers (using TLS means like certificates) and can verify the authenticated identity against a database of nodes authorized to take part in GIST signaling. It is, however, a matter of policy that the identity of peers is verified and accepted upon establishment of the secure TLS connection.
While GIST is handling authentication of peer nodes, more fine grained authentication may be required in the NSLP protocols. There is currently an ongoing work to specify common authorization mechanisms to be used in NSLP protocols [I‑D.manner‑nsis‑nslp‑auth] (Manner, J., “Authorization for NSIS Signaling Layer Protocols,” March 2007.), thus allowing, e.g., per-user and per-service authorization.
| TOC |
This section discusses the ways to extend the NSIS protocols. One key functionality of all three current protocols are the so-called "Extensibility flags (AB)". The protocols can carry new experimental objects, where the AB-flags can indicate whether a receiving node must interpret the object, or whether it can just drop them or pass them along in subsequent messages sent out further on the path. This functionality allows defining new objects without forcing all network entities to understand them.
| TOC |
GIST is extensible in several aspects.
| TOC |
A foreseen development within the QoS signaling is the introduction of new QoS Models to enable deployment of NSIS in specific scenarios. One such example is the Integrated Services Controlled Load Service for NSIS [I‑D.kappler‑nsis‑qosmodel‑controlledload] (Kappler, C., “A QoS Model for Signaling IntServ Controlled-Load Service with NSIS,” July 2007.).
There is already work to extend the base QoS NSLP and GIST to enable new QoS signaling scenarios. One such proposal is the Inter-Domain Reservation Aggregation aiming to support large-scale deployment of the QoS NSLP [I‑D.bless‑nsis‑resv‑aggr] (Doll, M. and R. Bless, “Inter-Domain Reservation Aggregation for QoS NSLP,” July 2007.). Another current proposal seeks to extend the whole NSIS framework towards path-decoupled signaling and QoS reservations [I‑D.cordeiro‑nsis‑hypath] (Cordeiro, L., “GIST Extension for Hybrid On-path Off-path Signaling (HyPath),” July 2007.).
| TOC |
The NATFW signaling can be extended in the same way as the QoS NSLP. No proposals currently exist to fulfill new use cases for the protocol.
| TOC |
Designing a new NSLP is both challenging and easy. On one hand, GIST provides many important functions through its service layer API, and allows the signaling application programmer to offload, e.g., the channel security, transport characteristics and signaling node discovery to GIST.
Yet, on the other hand, the signaling application designer must take into account that the network environment can be dynamic, both in terms of routing and node availability. The new NSLP designer must take into account at least the following issues:
The informational API between GIST and NSLPs (see Appendix B in [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.)) is very important to understand. It does not specify the exact messaging between GIST and the NSLPs but gives an understanding of the interactions, especially what kinds of asynchronous notifications from GIST the NSLP must be prepared to handle.
| TOC |
This document provides information to the community. It does not raise new security concerns.
| TOC |
Max Laier, Nuutti Varis and Lauri Liuhto have provided reviews of this draft and valuable input.
| TOC |
| TOC |
| [I-D.ietf-nsis-nslp-natfw] | Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, “NAT/Firewall NSIS Signaling Layer Protocol (NSLP),” draft-ietf-nsis-nslp-natfw-25 (work in progress), April 2010 (TXT). |
| [I-D.ietf-nsis-ntlp] | Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” draft-ietf-nsis-ntlp-20 (work in progress), June 2009 (TXT). |
| [I-D.ietf-nsis-qos-nslp] | Manner, J., Karagiannis, G., and A. McDonald, “NSLP for Quality-of-Service Signaling,” draft-ietf-nsis-qos-nslp-18 (work in progress), January 2010 (TXT). |
| [I-D.ietf-nsis-qspec] | Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” draft-ietf-nsis-qspec-24 (work in progress), January 2010 (TXT). |
| [RFC3726] | Brunner, M., “Requirements for Signaling Protocols,” RFC 3726, April 2004 (TXT). |
| [RFC4080] | Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, “Next Steps in Signaling (NSIS): Framework,” RFC 4080, June 2005 (TXT). |
| [RFC4081] | Tschofenig, H. and D. Kroeselberg, “Security Threats for Next Steps in Signaling (NSIS),” RFC 4081, June 2005 (TXT). |
| TOC |
| TOC |
| Jukka Manner | |
| Helsinki University of Technology (TKK) | |
| P.O. Box 3000 | |
| Espoo FIN-02015 TKK | |
| Finland | |
| Phone: | +358 9 451 2481 |
| Email: | jukka.manner@tkk.fi |
| URI: | http://www.netlab.tkk.fi/~jmanner/ |
| Roland Bless | |
| Institute of Telematics, Universitaet Karlsruhe (TH) | |
| Zirkel 2 | |
| Karlsruhe 76128 | |
| Germany | |
| Phone: | +49 721 608 6413 |
| Email: | bless@tm.uka.de |
| URI: | http://www.tm.uka.de/~bless |
| TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.