doc: Add RFC documents

1 files changed, 1683 insertions, 0 deletions

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]
+