From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5978.txt | 1683 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1683 insertions(+) create mode 100644 doc/rfc/rfc5978.txt (limited to 'doc/rfc/rfc5978.txt') diff --git a/doc/rfc/rfc5978.txt b/doc/rfc/rfc5978.txt new file mode 100644 index 0000000..634a374 --- /dev/null +++ b/doc/rfc/rfc5978.txt @@ -0,0 +1,1683 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Manner +Request for Comments: 5978 Aalto University +Category: Informational R. Bless +ISSN: 2070-1721 KIT + J. Loughney + Nokia + E. Davies, Ed. + Folly Consulting + October 2010 + + + Using and Extending the NSIS Protocol Family + +Abstract + + This document gives an overview of the Next Steps in Signaling (NSIS) + framework and protocol suite created by the NSIS Working Group during + the period of 2001-2010. It also includes suggestions on how the + industry can make use of the new protocols and how the community can + exploit the extensibility of both the framework and existing + protocols to address future signaling needs. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5978. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + + + +Manner, et al. Informational [Page 1] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The NSIS Architecture . . . . . . . . . . . . . . . . . . . . 3 + 3. The General Internet Signaling Transport . . . . . . . . . . . 6 + 4. Quality-of-Service NSLP . . . . . . . . . . . . . . . . . . . 11 + 5. NAT/Firewall Traversal NSLP . . . . . . . . . . . . . . . . . 12 + 6. Deploying the Protocols . . . . . . . . . . . . . . . . . . . 13 + 6.1. Deployment Issues Due to Use of RAO . . . . . . . . . . . 14 + 6.2. Deployment Issues with NATs and Firewalls . . . . . . . . 15 + 6.3. Incremental Deployment and Workarounds . . . . . . . . . . 15 + 7. Security Features . . . . . . . . . . . . . . . . . . . . . . 16 + 8. Extending the Protocols . . . . . . . . . . . . . . . . . . . 16 + 8.1. Overview of Administrative Actions Needed When + Extending NSIS . . . . . . . . . . . . . . . . . . . . . . 17 + 8.2. GIST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8.2.1. Use of Different Message Routing Methods . . . . . . . 18 + 8.2.2. Use of Different Transport Protocols or Security + Capabilities . . . . . . . . . . . . . . . . . . . . . 18 + 8.2.3. Use of Alternative Security Services . . . . . . . . . 19 + 8.2.4. Query Mode Packet Interception Schemes . . . . . . . . 19 + 8.2.5. Use of Alternative NAT Traversal Mechanisms . . . . . 20 + 8.2.6. Additional Error Identifiers . . . . . . . . . . . . . 20 + 8.2.7. Defining New Objects To Be Carried in GIST . . . . . . 21 + 8.2.8. Adding New Message Types . . . . . . . . . . . . . . . 21 + 8.3. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.4. QoS Specifications . . . . . . . . . . . . . . . . . . . . 22 + 8.5. NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 23 + 8.6. New NSLP Protocols . . . . . . . . . . . . . . . . . . . . 23 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 28 + + + + + + + + + + + + +Manner, et al. Informational [Page 2] + +RFC 5978 NSIS User and Extension Guide October 2010 + + +1. Introduction + + The Next Steps in Signaling (NSIS) Working Group was formed in + November 2001 to develop an Internet signaling protocol suite that + would attempt to remedy some of the perceived shortcomings of + solutions based on the Resource ReSerVation Protocol (RSVP), e.g., + with respect to mobility and Quality-of-Service (QoS) + interoperability. The initial charter 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], and an analysis of existing signaling + protocols can be found in [RFC4094]. + + The design of NSIS is based on a two-layer model, where a general + signaling transport layer provides services to an upper signaling + application layer. The design was influenced by Bob Braden's + document entitled "A Two-Level Architecture for Internet Signaling" + [TWO-LEVEL]. + + This document gives an overview of the NSIS framework and protocol + suite at the time of writing (2010), provides an introduction to the + use cases for which the current version of NSIS was designed, + describes how to deploy NSIS in existing networks, and summarizes how + the protocol suite can be enhanced to satisfy new use cases. + +2. The NSIS Architecture + + 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 and security services depending on the signaling + application requirements. The General Internet Signaling Transport + (GIST) [RFC5971] has been developed as the protocol that fulfills the + role of the NTLP. The NSIS protocol 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 with transporting NSLP messages hop-by- + hop between pairs of signaling nodes, 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. The current + protocols have features to confine the signaling to a limited part of + the path (such as the interior of a domain). Messages transmitted by + + + +Manner, et al. Informational [Page 3] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + GIST on behalf of an NSLP are identified by a unique NSLP identifier + (NSLPID) associated with the NSLP. Two NSLP protocols are currently + specified: one concerning Quality-of-Service signaling [RFC5974] and + one to enable NAT/firewall traversal [RFC5973]. + + NSIS is primarily designed to provide the signaling needed to install + state on nodes that lie on the path that will be taken by some end- + to-end flow of data packets; the state installed should facilitate or + enhance some characteristic of the data flow. This is typically + achieved by routing signaling messages along the same path (known as + "path-coupled signaling") and intercepting the signaling message at + NSIS-capable nodes. However, the NSIS architecture is designed to be + flexible, and the routing of signaling messages is controlled by the + Message Routing Method (MRM) that is applied to the signaling + messages. The initial specifications define two MRMs: + + o the basic Path Coupled MRM designed to drive signaling along the + path that will be followed by the data flow, and + + o an alternative Loose End MRM, which is applicable for + preconditioning the state in firewalls and Network Address + Translation (NAT) middleboxes when data flow destinations lie + behind this sort of middlebox. Without preconditioning, these + middleboxes will generally reject signaling messages originating + outside the region 'protected' by the middlebox and where the + destination is located. + + Parameters carried by each signaling message drive the operation of + the relevant transport or signaling application. In particular, the + messages will carry Message Routing Information (MRI) that will allow + the NSIS nodes to identify the data flow to which the signaling + applies. Generally, the intercepted messages will be reinjected into + the network after processing by the NSIS entities and will be routed + further towards the destination, possibly being intercepted by + additional NSIS-capable nodes before arriving at the flow endpoint. + + As with RSVP, it is expected that the signaling message will make a + complete round trip either along the whole end-to-end path or a part + of it if the scope of the signaling is limited. This implements a + two-phase strategy in which capabilities are assessed and provisional + reservations are made on the outbound leg; these provisional + reservations are then confirmed and operational state is installed on + the return leg. Unlike RSVP, signaling is normally initiated at the + source of the data flow, making it easier to ensure that the + signaling follows the expected path of the data flow, but can also be + receiver initiated as in RSVP. + + + + + +Manner, et al. Informational [Page 4] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + A central concept of NSIS is the Session Identifier (SID). Signaling + application states are indexed and referred to through the SID in all + the NSLPs. 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 teardown and + re-initiation of a signaling application state; they force merely an + update of the state parameters in the NSLP(s), especially the MRI. + + At the NTLP (GIST) layer, the SID is not meaningful by itself, but is + 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. Changes of routing or dynamic IP address + changes, e.g., due to mobility, will require GIST to modify already + established Messaging Associations (MAs) that are used to channel + NSLP messages between adjacent GIST peers in order to satisfy the + NSLP MRI for each SID. + + The following design restrictions were imposed for the first phase of + the protocol suite. They may be lifted in the future, and new + functionality may be added into the protocols at some later stage. + + o Initial focus on MRMs for path-coupled signaling: GIST transports + messages towards an identified unicast data flow destination based + on the signaling application request, and does not directly + support path-decoupled signaling, e.g., QoS signaling to a + bandwidth broker or other off-path resource manager. The + framework also supports a Loose End MRM used to discover GIST + nodes with particular properties in the direction of a given + address; for example, the NAT/firewall NSLP uses this method to + discover a NAT along the upstream data path. + + o No multicast support: Introducing support for multicast was deemed + too much overhead, considering the currently limited support for + global IP multicast. Thus, the current GIST and the NSLP + specifications consider unicast flows only. + + The key documents specifying the NSIS framework are: + + o Requirements for Signaling Protocols [RFC3726] + + o Next Steps in Signaling: Framework [RFC4080] + + o Security Threats for NSIS [RFC4081] + + The protocols making up the suite specified by the NSIS Working Group + are documented in: + + o The General Internet Signaling Transport protocol [RFC5971] + + + +Manner, et al. Informational [Page 5] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + o Quality-of-Service NSLP (QoS NSLP) [RFC5974] + + o The QoS specification template [RFC5975] + + o NAT/firewall traversal NSLP [RFC5973] + + The next three sections provide a brief survey of GIST, the QoS NSLP, + and the NAT/firewall NSLP. + +3. The General Internet Signaling Transport + + The General Internet Signaling Transport (GIST) [RFC5971] provides + signaling transport and security services to NSIS Signaling Layer + Protocols (NSLP) and the associated signaling applications. GIST + does not define new IP transport protocols or security mechanisms but + rather makes use of existing protocols, such as TCP, UDP, TLS, and + IPsec. Applications can indicate the desired transport attributes + for the signaling flow, e.g., unreliable or reliable, and GIST then + chooses the most appropriate transport protocol(s) to satisfy the + requirements of the flow. GIST will normally use UDP if unreliable + signaling is adequate, TCP if reliability is required, and TLS over + TCP for secure (and reliable) signaling flows, but there exist + extensibility provisions within GIST that will allow alternatives to + be specified in the future. The NSIS layered protocol stack is shown + in Figure 1. + + + + + + + + + + + + + + + + + + + + + + + + + + +Manner, et al. Informational [Page 6] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + +-----+ +--------+ +-------+ + | | | | | | + | QoS | | NAT/FW | | ... | NSLP + | | | | | | + +-----+ +--------+ +-------+ + + --------------------------------------------------------------------- + +--------------------------+ + | | + | GIST | NTLP + | | + +--------------------------+ + + --------------------------------------------------------------------- + +------------+-------------+ + | TLS | DTLS | Security Support* + +------------+-------------+ + | TCP | SCTP | UDP | DCCP | Transport Protocol* + +--------------------------+ + +--------------------------+ + | IPsec | + +--------------------------+ + +--------------------------+ + | IPv4 | IPv6 | + +--------------------------+ + + * The Security Support and Transport Protocol layers show some + possible protocols that could be used to transport NSIS messages. + To provide authentication and/or integrity protection support, + the transport protocol has to be paired with a suitable security + mechanism, e.g., TCP with TLS, or Datagram Congestion Control + Protocol (DCCP) with DTLS. + + Figure 1: The NSIS protocol stack + + GIST divides up the data flow's end-to-end path into a number of + segments between pairs of NSIS-aware peer nodes located along the + path. Not every router or other middlebox on the path needs to be + NSIS aware: each segment of the signaling path may incorporate + several routing hops. Also not every NSIS-aware node necessarily + implements every possible signaling application. If the signaling + for a flow requests services from a subset of the applications, then + only nodes that implement those services are expected to participate + as peers, and even some of these nodes can decline to operate on a + particular flow if, for example, the additional load might overload + the processing capability of the node. These characteristics mean + that incremental deployment of NSIS capabilities is possible both + with the initial protocol suite, and for any future NSLP applications + + + +Manner, et al. Informational [Page 7] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + that might be developed. The following paragraphs describe how a + signaling segment is set up to offer the transport and security + characteristics needed by a single NSLP. + + When an NSLP application wants to send a message towards a flow + endpoint, GIST starts the process of discovering the next signaling + node by sending a Query message towards the destination of the + related data flow. This Query carries the NSLP identifier (NSLPID) + and Message Routing Information (MRI), among others. The MRI + contains enough information to control the routing of the signaling + message and to identify the associated data flow. 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 needs to provide for + reliable or secure signaling, like TCP or TLS/TCP, a Messaging + Association (MA) is established between the two peers. An MA can be + reused 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 for + a potential 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 on the 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 places a Router Alert Option (RAO) in Query + message packets to ensure that they are intercepted by relevant NSIS- + aware nodes, as in RSVP. + + Late in the development of GIST, serious concerns were raised in the + IETF about the security risks and performance implications of + extensive usage of the RAO [RAO-BAD]. Additionally, evidence was + discovered indicating that several existing implementations of RAO + were inconsistent with the (intention of the) standards and would not + support the NSIS usage. There were also concerns that extending the + need for RAO recognition in the fast path of routers that are + + + +Manner, et al. Informational [Page 8] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + frequently implemented in hardware would delay or deter + implementation and deployment of NSIS. Eventually, it was decided + that NSIS would continue to specify RAO as its primary means for + triggering interception of signaling messages in intermediate nodes + on the data path, but the protocol suite would be published with + Experimental status rather than on the Standards Track while + deployment experience was gathered. More information about the use + of RAO in GIST can be found in [GIST-RAO]. Also, the deployment + issues that arise from the use of RAO are discussed in Section 6.1. + + Alternative mechanisms have been considered to allow nodes to + recognize NSIS signaling packets that should be intercepted. For + example, NSIS nodes could recognize UDP packets directed to a + specific destination port as Query messages that need to be + intercepted even though they are not addressed to the intercepting + node. GIST provides for the use of such alternatives as a part of + its extensibility design. NSIS recognizes that the workload imposed + by intercepting signaling packets could be considerable relative to + the work needed just to forward such packets. To keep the necessary + load to a minimum, NSIS provides mechanisms to limit the number of + interceptions needed by constraining the rate of generation and + allowing for intentional bypassing of signaling nodes that are not + affected by particular signaling requests. This 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. + + As with RSVP, all the state installed by NSIS protocols is "soft- + state" that will expire and be automatically removed unless it is + periodically refreshed. NSIS state is held both at the signaling + application layer and in the signaling transport layer, and is + maintained separately. NSLPs control the lifetime of the state in + the signaling application layer by setting a timeout and sending + periodic "keep alive" messages along the signaling path if no other + messages are required. The MAs and the routing state are maintained + semi-independently by the transport layer, because MAs may be used by + multiple NSLP sessions, and can also be recreated "on demand" if the + node needs to reclaim resources. The transport layer can send its + own "keep alive" messages across a MA if no NSLP messages have been + sent, for example, if the transport layer decides to maintain a + heavily used MA even though there is no current NSLP session using + it. Local state can also be deleted explicitly when no longer + needed. + + + + +Manner, et al. Informational [Page 9] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + If there is a change in the route used by a flow for which NSIS has + created state, NSIS needs to detect the change in order to determine + if the new path contains additional NSIS nodes that should have state + installed. GIST may use a range of 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 and the GIST peer states, and it notifies + NSLPs of any routing changes. It is then up to the NSLPs to act + appropriately, if needed, e.g., by issuing a refresh message. The + periodic queries also serve to maintain the soft-state in nodes as + long as the route is unchanged. + + In summary, GIST provides several services in one package to the + upper-layer signaling protocols: + + o Signaling peer discovery: GIST is able to find the next-hop node + that runs the NSLP being signaled for. + + o Multiplexing: GIST reuses already established signaling + relationships and messaging associations to next-hop peers if the + signaling flows require the same transport attributes. + + o Transport: GIST provides transport with different attributes -- + namely, reliable/unreliable and secure/unsecure. + + o Security: If security is requested, GIST uses TLS to provide an + encrypted and integrity-protected message transport to the next + signaling peer. + + o Routing changes: GIST detects routing changes, but instead of + acting on its own, it merely sends a notification to the local + NSLP. It is then up to the NSLP to act. + + o Fragmentation: GIST uses either a known Path MTU for the next hop + or limits its message size to 576 bytes when using UDP or Query + mode. If fragmentation is required, it automatically establishes + an MA and sends the signaling traffic over a reliable protocol, + e.g., TCP. + + o State maintenance: GIST establishes and then maintains the soft- + state that controls communications through MAs between GIST peers + along the signaling path, according to usage parameters supplied + by NSLPs and local policies. + + + + + + + + +Manner, et al. Informational [Page 10] + +RFC 5978 NSIS User and Extension Guide October 2010 + + +4. Quality-of-Service NSLP + + 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]. No support for QoS architectures based on bandwidth + brokers or other off-path resource managers is currently included. + + The design of the QoS NSLP is conceptually similar to RSVP, RFC 2205 + [RFC2205], 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], in particular, support of sender- or receiver- + initiated reservations, as well as, a type of bidirectional + 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) object in QoS NSLP messages. This is + similar to the decoupling between RSVP and the IntServ architecture, + RFC 1633 [RFC1633]. The QSPEC carries information on resources + available, resources required, traffic descriptions, and other + information required by the RMF. A template for QSPEC objects is + defined in [RFC5975]. This provides a number of basic parameter + objects that can be used as a common language to specify components + of concrete QoS models. The objects defined in [RFC5975] provide the + building blocks for many existing QoS models such as those associated + with RSVP and Differentiated Services. The extensibility of the + template allows new QoS model specifications to extend the template + language as necessary to support these specifications. + + The 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 QoS configuration + used 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. + + + + +Manner, et al. Informational [Page 11] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + In short, the functionality of the QoS NSLP includes: + + o Conveying resource requests for unicast flows + + o Resource requests (QSPEC) that are decoupled from the signaling + protocol (QoS NSLP) + + o Sender- and receiver-initiated reservations, as well as + bidirectional + + o Soft-state and reduced refresh (keep-alive) signaling + + o Session binding, i.e., session X can be valid only if session Y is + also valid + + o Message scoping, end-to-end, edge-to-edge, or end-to-edge (proxy + mode) + + o Protection against message re-ordering and duplication + + o Group tear, tearing down several sessions with a single message + + o Support for rerouting, e.g., due to mobility + + o Support for request priorities and preemption + + o Stateful and stateless nodes: stateless operation is particularly + relevant in core networks where large amounts of QoS state could + easily overwhelm a node + + o Reservation aggregation + + The protocol also provides for a proxy mode to allow the QoS + signaling to be implemented without needing all end-hosts to be + capable of handling NSIS signaling. + + The QSPEC template supports situations where the QoS parameters need + to be fine-grained, specifically targeted to an individual flow in + one part of the network (typically the edge or access part) but might + need to be more coarse-grained, where the flow is part of an + aggregate (typically in the core of the network). + +5. NAT/Firewall Traversal NSLP + + The NAT/firewall traversal NSLP [RFC5973] 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 + + + +Manner, et al. Informational [Page 12] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + 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. + + Configurations to be implemented in NAT and firewall devices signaled + by the NAT/firewall NSLP take the form of a (pattern, action) pair, + where the pattern specifies a template for packet header fields to be + matched. The device is then expected to apply the specified action + to any passing packet that matches the template. Actions are + currently limited to ALLOW (forward the packet) and DENY (drop the + packet). The template specification allows for a greater range of + packet fields to be matched than those allowed for in the GIST MRI. + + Basically, NAT/firewall signaling starts at the data sender (NSIS + Initiator) before any actual application data packets are sent. + Signaling messages may pass several middleboxes that are NAT/firewall + NSLP aware (NSIS Forwarder) on their way downstream and usually hit + the receiver (being the NSIS Responder). A proxy mode is also + available for cases where the NAT/firewall NSLP is not fully + supported along the complete data path. NAT/firewall 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 NAT/firewall signaling in order to create firewall + pinholes. + + The protocol also provides for a proxy mode to allow the NAT/firewall + signaling to be implemented without needing all end-hosts to be + capable of handling NSIS signaling. + +6. Deploying the Protocols + + The initial version of the NSIS protocol suite is being published + with the status of Experimental in order to gain deployment + experience. Concerns over the security, implementation, and + administrative issues surrounding the use of RAO are likely to mean + that initial deployments occur in "walled gardens" where the + characteristics of hardware in use are well-known, and there is a + high level of trust and control over the end nodes that use the + protocols. This section addresses issues that need to be considered + in a deployment of the NSIS protocol suite. + + + + +Manner, et al. Informational [Page 13] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + First of all, NSIS implementations must be available in at least some + of 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. NSIS is capable of incremental deployment and an + initial deployment does not need to involve every node in a network + domain. This is discussed further in Section 6.3. There are a + number of obstacles that may be encountered due to broken + implementations of RAO (see Section 6.1) and due to firewalls or NATs + that drop NSIS signaling packets (see Section 6.2). + + Another important issue is that applications may need to be made + NSIS-aware, thereby requiring some effort from the applications' + programmers. Alternatively, it may be possible to implement separate + applications to control, e.g., the network QoS requests or firewall + pinholes, without needing to update the actual applications that will + take advantage of NSIS capabilities. + +6.1. Deployment Issues Due to Use of RAO + + The standardized version of GIST depends on routers and other + middleboxes correctly recognizing and acting on packets containing + RAO. There are a number of problems related to RAO that can obstruct + a deployment of NSIS: + + o Some implementations do not respond to RAO at all. + + o Some implementations respond but do not distinguish between the + RAO parameter values in IPv4 packets or reject anything except 0 + (in which case, only the value 0 can be used). + + o The response to RAO in a GIST Query mode packet, which is sent + using the UDP transport, is to dispatch the packet to the UDP + stack in the intercepting node rather than to a function + associated with the RAO parameter. Since the node will not + normally have a regular UDP receiver for these packets they are + dropped. + + o The major security concern with RAO in NSIS is that it provides a + new vector for hosts to mount a (distributed) denial-of-service + (DDoS) attack on the control plane of routers on the data path. + Such attacks have occurred, and it is therefore normal for service + providers to prohibit "host-to-router" signaling packets such as + RSVP or NSIS from entering their networks from customer networks. + This will tend to limit the deployment of NSIS to "walled gardens" + unless a suitable mitigation of the DDoS threat can be found and + deployed. + + + +Manner, et al. Informational [Page 14] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + In order to deploy NSIS effectively, routers and other hardware need + to be selected and correctly configured to respond to RAO and + dispatch intercepted packets to the NSIS function. + + A further obstacle results from the likelihood that IPv4 packets with + IP options of any kind will be filtered and dropped by firewalls and + NATs. In many cases, this is the default behavior so that explicit + configuration is needed to allow packets carrying the RAO to pass + through. The general inclination of domain administrators is to deny + access to packets carrying IP options because of the security risks + and the additional load on the routers in the domain. The situation + with IPv6 may be easier, as the RAO option in IPv6 is better defined, + but the security concerns remain. + + Deployment issues are discussed at more length in Appendix C of the + GIST specification [RFC5971]. + +6.2. Deployment Issues with NATs and Firewalls + + NAT gateways and firewalls may also hinder initial deployment of NSIS + protocols for several reasons: + + o They may filter and drop signaling traffic (as described in + Section 6.1) to deny access to packets containing IP options. + + o They may not permit "unsolicited" incoming GIST Query mode + packets. This behavior has been anticipated in the design of the + protocols but requires additional support to ensure that the + middleboxes are primed to accept the incoming queries (see + [RFC5974] and [RFC5973]). + + o NATs that are not aware of the NSIS protocols will generally + perform address translations that are not coordinated with the + NSIS protocols. Since NSIS signaling messages may be carrying + embedded IP addresses affected by these translations, it may not + be possible to operate NSIS through such legacy NATs. The + situation and workarounds are discussed in Section 7.2.1 of + [RFC5971]. + +6.3. Incremental Deployment and Workarounds + + NSIS is specifically designed to be incrementally deployable. It is + not required that all nodes on the signaling and data path are NSIS + aware. To make any use of NSIS, at least two nodes on the path need + to be NSIS aware. However, it is not essential that the initiator + and receiver of the data flow are NSIS aware. Both the QoS and NAT/ + firewall NSLPs provide "proxy modes" in which nodes adjacent to the + initiator and/or receiver can act as proxy signaling initiator or + + + +Manner, et al. Informational [Page 15] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + receiver. An initiator proxy can monitor traffic and, hopefully, + detect when a data flow of a type needing NSIS support is being + initiated. The proxies can act more or less transparently on behalf + of the data flow initiator and/or receiver to set up the required + NSIS state and maintain it while the data flow continues. This + capability reduces the immediate need to modify all the data flow + endpoints before NSIS is viable. + +7. Security Features + + Basic security functions are provided at the GIST layer, e.g., + protection against some blind or denial-of-service attacks, but note + that introduction of alternative MRMs may provide attack avenues that + are not present with the current emphasis on the path-coupled MRM. + Conceptually, it is difficult to protect against an on-path attacker + and man-in-the-middle attacks when using path-coupled MRMs, because a + basic functionality of GIST is to discover as 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 such as 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 authorization may be required in the NSLP protocols. There + is currently an ongoing work to specify common authorization + mechanisms to be used in NSLP protocols [NSIS-AUTH], thus allowing, + e.g., per-user and per-service authorization. + +8. Extending the Protocols + + This section discusses the ways that are available to extend the NSIS + protocol suite. The Next Steps in Signaling (NSIS) Framework + [RFC4080] describes a two-layer framework for signaling on the + Internet, comprising a generic transport layer with specific + signaling-layer protocols to address particular applications running + over this transport layer. The model is designed to be highly + extensible so that it can be adapted for different signaling needs. + + It is expected that additional signaling requirements will be + identified in the future. The two-layer approach allows for NSLP + signaling applications to be developed independently of the transport + protocol. Further NSLPs can therefore be developed and deployed to + meet these new needs using the same GIST infrastructure, thereby + + + +Manner, et al. Informational [Page 16] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + providing a level of macro-extensibility. However, the GIST protocol + and the two signaling applications have been designed so that + additional capabilities can be incorporated into the design should + additional requirements within the general scope of these protocols + need to be accommodated. + + The NSIS framework is also highly supportive of incremental + deployment. A new NSLP need not be available on every NSIS-aware + node in a network or along a signaling path in order to start using + it. Nodes that do not (yet) support the application will forward its + signaling messages without complaint until it reaches a node where + the new NSLP application is deployed. + + One key functionality of parameter objects carried in NSIS protocols + is the so-called "Extensibility flags (A/B)". All the existing + protocols (and any future ones conforming to the standards) can carry + new experimental objects, where the A/B 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. + +8.1. Overview of Administrative Actions Needed When Extending NSIS + + Generally, NSIS protocols can be extended in multiple ways, many of + which require the allocation of unique code point values in + registries maintained by IANA on behalf of the IETF. This and the + following sections provide an overview of the administrative + mechanisms that might apply. The extensibility rules defined below + are based upon the procedures by which IANA assigns values: "IESG + Approval", "IETF Review", "Expert Review", and "Private Use" (as + specified in [RFC5226]). The appropriate procedure for a particular + type of code point is defined in one or other of the NSIS protocol + documents, mostly [RFC5971]. + + In addition to registered code points, all NSIS protocols provide + code points that can be used for experimentation, usually within + closed networks, as explained in [RFC3692]. There is no guarantee + that independent experiments will not be using the same code point! + +8.2. GIST + + GIST is extensible in several aspects covered in the subsections + below. In these subsections, there are references to document + sections in the GIST specification [RFC5971] where more information + can be found. The bullet points at the end of each subsection + specify the formal administrative actions that would need to be + carried out when a new extension is standardized. + + + +Manner, et al. Informational [Page 17] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + More generally, as asserted in Section 1 of the GIST specification, + the GIST design could be extended to cater for multicast flows and + for situations where the signaling is not tied to an end-to-end data + flow. However, it is not clear whether this could be done in a + totally backwards-compatible way, and this is not considered within + the extensibility model of NSIS. + +8.2.1. Use of Different Message Routing Methods + + Currently, only two message routing methods are supported (Path + Coupled MRM and Loose End MRM), but further MRMs may be defined in + the future. See Sections 3.3 and 5.8 of the GIST specification + [RFC5971]. One possible additional MRM under development is + documented in [EST-MRM]. This MRM would direct signaling towards an + explicit target address other than the (current) data flow + destination and is intended to assist setting up of state on a new + path during "make-before-break" handover sequences in mobile + operations. Note that alternative routing methods may require + modifications to the firewall traversal techniques used by GIST and + NSLPs. + + o New MRMs require allocation of a new MRM-ID either by IETF review + of a specification or expert review [RFC5971]. + +8.2.2. Use of Different Transport Protocols or Security Capabilities + + The initial handshake between GIST peers allows a negotiation of the + transport protocols to be used. Currently, proposals exist to add + DCCP [GIST-DCCP] and the Stream Control Transmission Protocol (SCTP) + [GIST-SCTP] transports to GIST; in each case, using Datagram TLS + (DTLS) to provide security. See Sections 3.2 and 5.7 of the GIST + specification [RFC5971]. GIST expects alternative capabilities to be + treated as selection of an alternative protocol stack. Within the + protocol stack, the individual protocols used are specified by MA + Protocol IDs that are allocated from an IANA registry if new + protocols are to be used. See Sections 5.7 and 9 of the GIST + specification [RFC5971]. + + o Use of an alternative transport protocol or security capability + requires allocation of a new MA-Protocol-ID either by IETF review + of a specification or expert review [RFC5971]. + + + + + + + + + + +Manner, et al. Informational [Page 18] + +RFC 5978 NSIS User and Extension Guide October 2010 + + +8.2.3. Use of Alternative Security Services + + Currently, only TLS is specified for providing secure channels with + MAs. Section 3.9 of the GIST specification [RFC5971] suggests that + alternative protocols could be used, but the interactions with GIST + functions would need to be carefully specified. See also Section + 4.4.2 of the GIST specification [RFC5971]. + + o Use of an alternative security service requires allocation of a + new MA-Protocol-ID either by IETF review of a specification or + expert review [RFC5971]. + +8.2.4. Query Mode Packet Interception Schemes + + GIST has standardized a scheme using RAO mechanisms [GIST-RAO] with + UDP packets. If the difficulties of deploying the RAO scheme prove + insuperable in particular circumstances, alternative interception + schemes can be specified. One proposal that was explored for GIST + used UDP port recognition in routers (rather than RAO mechanisms) to + drive the interception of packets. See Section 5.3.2 of the GIST + specification [RFC5971]. Each NSLP needs to specify membership of an + "interception class" whenever it sends a message through GIST. A + packet interception scheme can support one or more interception + classes. In principle, a GIST instance can support multiple packet + interception schemes, but each interception class needs to be + associated with exactly one interception scheme in a GIST instance, + and GIST instances that use different packet interception schemes for + the same interception class will not be interoperable. + + Defining an alternative interception class mechanism for + incorporation into GIST should be considered as a very radical step, + and all alternatives should be considered before taking this path. + The main reason for this is that the mechanism will necessarily + require additional operations on every packet passing through the + affected router interfaces. A number of considerations should be + taken into account: + + o Although the interception mechanism need only be deployed on + routers that actually need it (probably for a new NSLP), + deployment may be constrained if the mechanism requires + modification to the hardware of relevant routers and/or needs to + await modification of the software by the router vendor. + + o Typically, any packet fields to be examined should be near the + header of the packet so that additional memory accesses are not + needed to retrieve the values needed for examination. + + + + + +Manner, et al. Informational [Page 19] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + o The logic required to determine if a packet should be intercepted + needs to be kept simple to minimize the extra per-packet + processing. + + o The mechanism should be applicable to both IPv4 and IPv6 packets. + + o Packet interception mechanisms potentially provide an attack path + for denial-of-service attacks on routers, in that packets are + diverted into the "slow path" and hence can significantly increase + the load on the general processing capability of the router. Any + new interception mechanism needs to be carefully designed to + minimize the attack surface. + + Packet interception mechanisms are identified by an "interception + class" which is supplied to GIST through the Application Programming + Interface for each message sent. + + o New packet interception mechanisms will generally require + allocation of one or more new Interception-class-IDs. This does + not necessarily need to be placed in an IANA registry as it is + primarily used as a parameter in the API between the NSLPs and + GIST and may never appear on the wire, depending on the mechanism + employed; all that is required is consistent interpretation + between the NSLPs and GIST in each applicable node. However, if, + as is the case with the current RAO mechanism [GIST-RAO], the + scheme distinguishes between multiple packet interception classes + by a value carried on the wire (different values of RAO parameter + for the RAO mechanism in GIST), an IANA registry may be required + to provide a mapping between interception classes and on-the-wire + values as discussed in Section 6 of [GIST-RAO]. + +8.2.5. Use of Alternative NAT Traversal Mechanisms + + The mechanisms proposed for both legacy NAT traversal (Section 7.2.1 + of the GIST specification [RFC5971]) and GIST-aware NAT traversal + (Section 7.2.2 of the GIST specification [RFC5971]) can be extended + or replaced. As discussed above, extension of NAT traversal may be + needed if a new MRM is deployed. Note that there is extensive + discussion of NAT traversal in the NAT/firewall NSLP specification + [RFC5973]. + +8.2.6. Additional Error Identifiers + + Making extensions to any of the above items may result in having to + create new error modes. See Section 9 and Appendix A.4.1 - A.4.3 of + the GIST specification [RFC5971]. + + + + + +Manner, et al. Informational [Page 20] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + o Additional error identifiers require allocation of new error + code(s) and/or subcode(s) and may also require allocation of + Additional Information types. These are all allocated on a first- + come, first-served basis by IANA [RFC5971]. + +8.2.7. Defining New Objects To Be Carried in GIST + + The A/B (extensibility) flags in each signaling object carried in + NSIS protocols enable the community to specify new objects applicable + to GIST that can be carried inside a signaling session without + breaking existing implementations. See Appendix A.2 of the GIST + specification [RFC5971]. The A/B flags can also be used to indicate + in a controlled fashion that a certain object must be understood by + all GIST nodes, which makes it possible to probe for the support of + an extension. One such object already designed is the "Peering + Information Object (PIO)" [PEERING-DATA] that allows a Query message + to carry additional peering data to be used by the recipient in + making the peering decision. + + o New objects require allocation of a new Object Type ID either by + IETF review of a specification or through another acceptable + published specification [RFC5971]. + +8.2.8. Adding New Message Types + + Major modifications could be made by adding additional GIST message + types and defining appropriate processing. It might be necessary to + define this as a new version of the protocol. A field is provided in + the GIST Common Header containing the version number. GIST currently + has no provision for version or capability negotiation that might be + needed if a new version was defined. + + o New GIST Message Types require allocation of a new GIST Message + Type ID either by IETF review of a specification or expert review + [RFC5971]. + +8.3. QoS NSLP + + The QoS NSLP provides signaling for QoS reservations on the Internet. + The QoS NSLP decouples the resource reservation model or architecture + (QoS model) from the signaling. The signaling protocol is defined in + Quality-of-Service NSLP (QoS NSLP) [RFC5974]. The QoS models are + defined in separate specifications, and the QoS NSLP can operate with + one or more of these models as required by the environment where it + is used. It is anticipated that additional QoS models will be + developed to address various Internet scenarios in the future. + Extensibility of QoS models is considered in Section 8.4. + + + + +Manner, et al. Informational [Page 21] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + The QoS NSLP specifically mentions the possibility of using + alternative Message Routing Methods (MRMs), apart from the general + ability to extend NSLPs using new objects with the standard A/B + extensibility flags to allow them to be used in new and old + implementations. + + 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 [RESV-AGGR]. Another current proposal seeks to extend + the whole NSIS framework towards path-decoupled signaling and QoS + reservations [HYPATH]. + +8.4. QoS Specifications + + The QoS Specification template (QSPEC) is defined in [RFC5975]. This + provides the language in which the requirements of specific QoS + models are described. Introduction of a new QoS model involves + defining a new QSPEC. In order to have a new QSPEC allocated by + IANA, there must be an acceptable published specification that + defines the specific elements within the QSPEC used in the new model. + See [RFC5975] for details. + + The introduction of new QoS models is designed to enable deployment + of NSIS-based QoS control in specific scenarios. One such example is + the Integrated Services Controlled Load Service for NSIS [CL]. + + A key feature provided by defining the QSPEC template is support of a + common language for describing QoS requirements and capabilities, + which can be reused by any QoS models intending to use the QoS NSLP + to signal their requirements for traffic flows. The commonality of + the QSPEC parameters ensures a certain level of interoperability of + QoS models and reduces the demands on hardware that has to implement + the QoS control. Optional QSPEC parameters support the extensibility + of the QoS NSLP to other QoS models in the future; new QSPEC + parameters can be defined in the document that specifies a new QoS + model. See Sections 4.4 and 7 of [RFC5975]. + + The QSPEC consists of a QSPEC version number, QSPEC objects, plus + specification of processing and procedures that can be used to build + many QoS models. The definition of a QSPEC can be revised without + necessarily changing the version if the changes are functionally + backwards compatible. If changes are made that are not backwards + compatible, then a new QSPEC version number has to be assigned. Note + that a new QSPEC version number is not needed just because additional + QSPEC parameters are specified; new versions will be needed only if + the existing functionality is modified. The template includes + version negotiation procedures that allow the originator of an NSLP + + + +Manner, et al. Informational [Page 22] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + message to retry with a lower QSPEC version if the receiver rejects a + message because it does not support the QSPEC version signaled in the + message. See Section 3.2 of [RFC5975]. + + o Creation of a new, incompatible version of an existing QSPEC + requires allocation of a new QSPEC version number that is + documented in a permanent and readily available public + specification. See [RFC5975]. + + o Completely new QSPECs can also be created. Such new QSPECs + require allocation of a QSPEC type that is documented in a + permanent and readily available public specification. Values are + also available for local or experimental use during development. + See [RFC5975]. + + o Additional QSPEC procedures can be defined requiring allocation of + a new QSPEC procedure number that is documented in a permanent and + readily available public specification. Values are also available + for local or experimental use during development. See [RFC5975]. + + o Additional QSPEC parameters and associated error codes can be + defined requiring a permanent and readily available public + specification document. Values are also available for local or + experimental use during development. See [RFC5975]. + +8.5. NAT/Firewall NSLP + + The NAT/firewall signaling can be extended broadly in the same way as + the QoS NSLP by defining new parameters to be carried in NAT/firewall + NSLP messages. See Section 7 of [RFC5973]. No proposals currently + exist to fulfill new use cases for the protocol. + +8.6. New NSLP Protocols + + Designing a new NSLP is both challenging and easy. + + New signaling applications with associated NSLPs can be defined to + work in parallel or replace the applications already defined by the + NSIS working group. Applications that fit into the NSIS framework + will be expected to use GIST to provide transport of signaling + messages and appropriate security facilities that relieve the + application designer of many "lower-level" problems. GIST provides + many important functions through the API that it exposes to the code + of the signaling application layer, and allows the signaling + application programmer to offload various tasks to GIST, e.g., the + channel security, transport characteristics, and signaling node + discovery. + + + + +Manner, et al. Informational [Page 23] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + 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: + + o Routing changes, e.g., due to mobility: GIST sends network + notifications when something happens in the network, e.g., peers + or routing paths change. All signaling applications must be able + to handle these notifications and act appropriately. GIST does + not include logic to figure out what the NSLP would want to do due + to a certain network event. Therefore, GIST gives the + notification to the application, and lets it make the right + decision. + + o GIST indications: GIST will also send other notifications, e.g., + if a signaling peer does not reply to refresh messages, or a + certain NSLP message was not successfully delivered to the + recipient. NSLP applications must also be able to handle these + events. Appendix B in the GIST specification discusses the GIST- + NSLP API and the various functionality required, but implementing + this interface can be quite challenging; the multitude of + asynchronous notifications that can arrive from GIST increases the + implementation complexity of the NSLP. + + o Lifetime of the signaling flow: NSLPs should inform GIST when a + flow is no longer needed using the SetStateLifetime primitive. + This reduces bandwidth demands in the network. + + o NSLP IDs: NSLP messages may be multiplexed over GIST MAs. The new + NSLP needs to use a unique NSLPID to ensure that its messages are + delivered to the correct application by GIST. A single NSLP could + use multiple NSLPIDs, for example, to distinguish different + classes of signaling nodes that might handle different levels of + aggregation of requests or alternative processing paths. Note + that unlike GIST, the NSLPs do not provide a protocol versioning + mechanism. If the new NSLP is an upgraded version of an existing + NSLP, then it should be distinguished by a different NSLPID. + + * A new generally available NSLP requires IESG approval for the + allocation of a new NSLP ID [RFC5971] + + o Incremental deployment: It would generally be unrealistic to + expect every node on the signaling path to have a new NSLP + implemented immediately. New NSLPs need to allow for this. The + QoS and NAT/firewall NSLPs provide examples of techniques such as + proxy modes that cater for cases where the data flow originator + and/or receiver does not implement the NSLP. + + + + +Manner, et al. Informational [Page 24] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + o Signaling Message Source IP Address: It is sometimes challenging + for an NSLP originating a signaling message to determine the + source IP address that should be used in the signaling messages, + which may be different from the data flow source address used in + the MRI. This challenge occurs either when a node has multiple + interfaces or is acting as a proxy for the data flow originator + (typically expected to occur during the introduction of NSIS when + not all nodes are NSIS enabled). A proxy signaling flow + originator generally needs to know and use the correct data flow + source IP address, at least initially. As discussed in Section + 5.8.1.2 of [RFC5971], the signaling flow originator may choose to + alter the source IP address after the initial Query message has + established the flow path in order that ICMP messages are directed + to the most appropriate node. In the proxy case, the data flow + originator would be unaware of the signaling flow, and ICMP + messages relating to the signaling would be meaningless if passed + on to the data flow originator. Hence, it is essential that an + NSLP is aware of the position and role of the node on which it is + instantiated and has means of determining the appropriate source + address to be used and ensuring that it is used on signaling + packets. + + o New MRMs: GIST currently defines two Message Routing Methods, and + leaves the door open for new ideas. Thus, it is possible that a + new NSLP also requires a new MRM; path-decoupled routing being one + example. + + o Cooperation with other NSLPs: Some applications might need + resources from two or more different classes in order to operate + successfully. The NSLPs managing these resources could operate + cooperatively to ensure that such requests were coordinated to + avoid wasting signaling bandwidth and prevent race conditions. + + It is essential that the security considerations of a new NSLP are + carefully analyzed. NSIS NSLPs are deployed in routers as well as + host systems; a poorly designed NSLP could therefore provide an + attack vector for network resources as well as end systems. The NSLP + must also support authorization of users and must allow the use of + the GIST authentication and integrity protection mechanisms where + users deem them to be necessary. + + The API between GIST and NSLPs (see Appendix B in [RFC5971]) is very + important to understand. The abstract design in the GIST + specification 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: the actual interface will be dependent on each + implementation of GIST. + + + +Manner, et al. Informational [Page 25] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + Messages transmitted by GIST on behalf of an NSLP are identified by a + unique NSLP identifier (NSLPID). NSLPIDs are 16-bit unsigned numbers + taken from a registry managed by IANA and defined in Section 9 of the + GIST specification [RFC5971]. + + A range of values (32704-32767) is available for Private and + Experimental use during development. Any new signaling application + that expects to be deployed generally on the Internet needs to use + the registration procedure "IESG Approval" in order to request + allocation of unique NSLPID value(s) from the IANA registry. There + is additional discussion of NSLPIDs in Section 3.8 of the GIST + specification. + +9. Security Considerations + + This document provides information to the community. It does not + itself raise new security concerns. + + However, any extensions that are made to the NSIS protocol suite will + need to be carefully assessed for any security implications. This is + particularly important because NSIS messages are intended to be + actively processed by NSIS-capable routers that they pass through, + rather than simply forwarded as is the case with most IP packets. It + is essential that extensions provide means to authorize usage of + capabilities that might allocate resources and recommend the use of + appropriate authentication and integrity protection measures in order + to exclude or adequately mitigate any security issues that are + identified. + + Authors of new extensions for NSIS should review the analysis of + security threats to NSIS documented in [RFC4081] as well as + considering whether the new extension opens any new attack paths that + need to be mitigated. + + GIST offers facilities to authenticate NSIS messages and to ensure + that they are delivered reliably. Extensions must allow these + capabilities to be used in an appropriate manner to minimize the + risks of NSIS messages being misused and must recommend their + appropriate usage. + + If additional transport protocols are proposed for use in association + with GIST, an appropriate set of compatible security functions must + be made available in conjunction with the transport protocol to + support the authentication and integrity functions expected to be + available through GIST. + + + + + + +Manner, et al. Informational [Page 26] + +RFC 5978 NSIS User and Extension Guide October 2010 + + +10. Acknowledgements + + This document combines work previously published as two separate + documents: "What is Next Steps in Signaling anyway - A User's Guide + to the NSIS Protocol Family" written by Roland Bless and Jukka + Manner, and "NSIS Extensibility Model" written by John Loughney. + + Max Laier, Nuutti Varis and Lauri Liuhto have provided reviews of the + "User's Guide" and valuable input. Teemu Huovila also provided + valuable input on the later versions. + + The "Extensibility Model" borrowed some ideas and some text from RFC + 3936 [RFC3936], "Procedures for Modifying the Resource ReSerVation + Protocol (RSVP)". Robert Hancock provided text for the original GIST + section, since much modified, and Claudia Keppler has provided + feedback on this document, while Allison Mankin and Bob Braden + suggested that this document be worked on. + +11. References + +11.1. Normative References + + [RFC3726] Brunner, M., "Requirements for Signaling Protocols", + RFC 3726, April 2004. + + [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. + Van den Bosch, "Next Steps in Signaling (NSIS): + Framework", RFC 4080, June 2005. + + [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats + for Next Steps in Signaling (NSIS)", RFC 4081, + June 2005. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, + RFC 5226, May 2008. + + [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General + Internet Signalling Transport", RFC 5971, + October 2010. + + [RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. + Davies, "NAT/Firewall NSIS Signaling Layer Protocol + (NSLP)", RFC 5973, October 2010. + + [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS + Signaling Layer Protocol (NSLP) for Quality-of- + Service Signaling", RFC 5974, October 2010. + + + +Manner, et al. Informational [Page 27] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + [RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC + Template for the Quality-of-Service NSIS Signaling + Layer Protocol (NSLP)", RFC 5975, October 2010. + +11.2. Informative References + + [CL] Kappler, C., Fu, X., and B. Schloer, "A QoS Model for + Signaling IntServ Controlled-Load Service with NSIS", + Work in Progress, April 2010. + + [EST-MRM] Bless, R., "An Explicit Signaling Target Message + Routing Method (EST-MRM) for the General Internet + Signaling Transport (GIST) Protocol", Work + in Progress, June 2010. + + [GIST-DCCP] Manner, J., "Generic Internet Signaling Transport + over DCCP and DTLS", Work in Progress, June 2007. + + [GIST-RAO] Hancock, R., "Using the Router Alert Option for + Packet Interception in GIST", Work in Progress, + November 2008. + + [GIST-SCTP] Fu, X., Dickmann, C., and J. Crowcroft, "General + Internet Signaling Transport (GIST) over Stream + Control Transmission Protocol (SCTP) and Datagram + Transport Layer Security (DTLS)", Work in Progress, + May 2010. + + [HYPATH] Cordeiro, L., Curado, M., Monteiro, E., Bernardo, V., + Palma, D., Racaru, F., Diaz, M., and C. Chassot, + "GIST Extension for Hybrid On-path Off-path Signaling + (HyPath)", Work in Progress, February 2008. + + [NSIS-AUTH] Manner, J., Stiemerling, M., Tschofenig, H., and R. + Bless, "Authorization for NSIS Signaling Layer + Protocols", Work in Progress, July 2008. + + [PEERING-DATA] Manner, J., Liuhto, L., Varis, N., and T. Huovila, + "Peering Data for NSIS Signaling Layer Protocols", + Work in Progress, February 2008. + + [RAO-BAD] Rahman, R. and D. Ward, "Use of IP Router Alert + Considered Dangerous", Work in Progress, + October 2008. + + [RESV-AGGR] Doll, M. and R. Bless, "Inter-Domain Reservation + Aggregation for QoS NSLP", Work in Progress, + July 2007. + + + +Manner, et al. Informational [Page 28] + +RFC 5978 NSIS User and Extension Guide October 2010 + + + [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated + Services in the Internet Architecture: an Overview", + RFC 1633, June 1994. + + [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- + Version 1 Functional Specification", RFC 2205, + September 1997. + + [RFC3692] Narten, T., "Assigning Experimental and Testing + Numbers Considered Useful", BCP 82, RFC 3692, + January 2004. + + [RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying + the Resource reSerVation Protocol (RSVP)", BCP 96, + RFC 3936, October 2004. + + [RFC4094] Manner, J. and X. Fu, "Analysis of Existing Quality- + of-Service Signaling Protocols", RFC 4094, May 2005. + + [TWO-LEVEL] Braden, R. and B. Lindell, "A Two-Level Architecture + for Internet Signaling", Work in Progress, + November 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Manner, et al. Informational [Page 29] + +RFC 5978 NSIS User and Extension Guide October 2010 + + +Authors' Addresses + + Jukka Manner + Aalto University + Department of Communications and Networking (Comnet) + P.O. Box 13000 + FIN-00076 Aalto + Finland + + Phone: +358 9 470 22481 + EMail: jukka.manner@tkk.fi + URI: http://www.netlab.tkk.fi/~jmanner/ + + + Roland Bless + Institute of Telematics, Karlsruhe Institute of Technology (KIT) + Zirkel 2, Building 20.20 + P.O. Box 6980 + Karlsruhe 76049 + Germany + + Phone: +49 721 608 6413 + EMail: bless@kit.edu + URI: http://tm.kit.edu/~bless + + + John Loughney + Nokia + 955 Page Mill Road + Palo Alto, CA 94303 + USA + + Phone: +1 650 283 8068 + EMail: john.loughney@nokia.com + + + Elwyn Davies (editor) + Folly Consulting + Soham + UK + + EMail: elwynd@folly.org.uk + URI: http://www.folly.org.uk + + + + + + + + +Manner, et al. Informational [Page 30] + -- cgit v1.2.3