RFC 5978

Using and Extending the NSIS Protocol Family

📅 published October 2010, from ietf

RFC 5978: Using and Extending the NSIS Protocol Family 📜✨

Okay bestie, this one is from October 2010 🍓. It's an Informational document, which means it's published for information and is not an Internet Standards Track specification 💅. It's ISSN 2070-1721. The authors are J. Manner (Aalto University), R. Bless (KIT), J. Loughney (Nokia), and E. Davies, Ed. (Folly Consulting), with E. Davies as the editor 🫶. It doesn't list any RFCs it obsoletes or updates, so it isn't replacing or changing anything else 🦋.

Abstract 🌸

Okay so this document is a tour of the Next Steps in Signaling (NSIS) framework and protocol suite, which the NSIS Working Group made between 2001 and 2010 💖. It also talks about how the industry can actually use these new protocols, and how the community can take advantage of the extensibility of both the framework and the existing protocols so they can handle future signaling needs 🔥.

Status of This Memo 📝

This document is not an Internet Standards Track specification. It's published for informational purposes 🌈.

It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 👑.

For the latest on this document's status, any errata, and where to send feedback, head to http://www.rfc-editor.org/info/rfc5978 🔗.

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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🧚. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💜.

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

1. Introduction ✨

Okay so the NSIS Working Group got started in November 2001 🎀. Their goal was to build an Internet signaling protocol suite that would fix some of the problems people had with solutions based on the Resource ReSerVation Protocol (RSVP), for example around mobility and Quality-of-Service (QoS) interoperability 💅. The first charter focused on QoS signaling as the first use case, with RSVP as the background for the work. Then in May 2003, middlebox traversal was added as a second explicit use case 🦋. The requirements for this new generation of signaling protocols are written up in [RFC3726], and an analysis of existing signaling protocols is in [RFC4094] 📚.

NSIS is built on a two-layer model. A general signaling transport layer provides services to an upper signaling application layer, so the layers each have their own job 🧚. The design was influenced by Bob Braden's document "A Two-Level Architecture for Internet Signaling" [TWO-LEVEL] 💜.

This document gives an overview of the NSIS framework and protocol suite as of 2010, when it was written 🌸. It introduces the use cases the current version of NSIS was designed for, explains how to deploy NSIS in existing networks, and summarises how the protocol suite can be extended to cover new use cases 🫶.

2. The NSIS Architecture ✨

Okay so the NSIS protocol suite basically takes ideas from RSVP 🦋 but splits the whole job into two layers, and it's giving organized. The bottom one is the NSIS Transport Layer Protocol (NTLP) 🚚. Its job is delivering the higher-layer messages to the next signaling node on the path. That includes finding the next NSIS node, which might not be the next routing hop 👀, plus offering different transport and security services depending on what each signaling app needs. The General Internet Signaling Transport (GIST) [RFC5971] is the protocol that fills the NTLP role 💅. And yes, the NSIS suite works with both IP versions, IPv4 and IPv6 🌈.

The actual signaling app logic lives up top in the NSIS Signaling Layer Protocol (NSLP) 👑. GIST only cares about carrying NSLP messages hop-by-hop between pairs of signaling nodes. End-to-end signaling is handled by the NSLP protocols when they need it 🫶. Not every NSLP has to do end-to-end signaling, though. The current ones can keep signaling inside a limited chunk of the path, like the inside of a domain 🏠. Every message GIST sends for an NSLP gets tagged with a unique NSLP identifier (NSLPID) tied to that NSLP 🎀. Two NSLPs are specified right now: one for Quality-of-Service signaling [RFC5974] ⚡, and one for NAT/firewall traversal [RFC5973] 🧱.

NSIS is mainly built to set up state on the nodes along the path that a given end-to-end data flow will take 🛣️. That state is supposed to help or boost some property of the flow ✨. This usually happens by routing the signaling messages along that same path (called "path-coupled signaling") and having NSIS-capable nodes intercept the messages 🕵️‍♀️. But the architecture is flexible, so how signaling messages get routed is decided by the Message Routing Method (MRM) applied to them 🗺️. The first specs define two MRMs:

  • the basic Path Coupled MRM, which drives signaling along the path the data flow will follow 🌸, and
  • the alternative Loose End MRM, which is useful for preconditioning state in firewalls and Network Address Translation (NAT) middleboxes when the data flow's destinations sit behind one of those boxes 🙈. Without preconditioning, these middleboxes will usually reject signaling messages that come from outside the region they "protect" and where the destination lives 💀.

Each signaling message carries parameters that drive how the relevant transport or signaling app behaves 🍓. Specifically, the messages carry Message Routing Information (MRI), which lets NSIS nodes figure out which data flow the signaling is about 🧚. Usually the intercepted messages get reinjected into the network after the NSIS entities process them, then routed further toward the destination. They might get intercepted by more NSIS-capable nodes before they reach the flow endpoint 🦋.

Just like with RSVP, the signaling message is expected to make a full round trip, either along the whole end-to-end path or just part of it if the signaling scope is limited 🔁. That gives us a two-phase strategy 💜: capabilities get assessed and provisional reservations get made on the outbound leg, then those provisional reservations get confirmed and operational state gets installed on the return leg ✅. The difference from RSVP is that signaling is normally started at the source of the data flow 📣. That makes it easier to make sure the signaling follows the flow's expected path, but it can also be started by the receiver, same as RSVP 🙌.

A central concept in 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 info from IP addresses, which lets signaling flows change IP addresses dynamically, for example because of mobility 🚀. Changing IP addresses doesn't force a full teardown and re-setup of a signaling application state. It only means updating the state parameters in the NSLP(s), especially the MRI 🛠️.

At the NTLP (GIST) layer, the SID doesn't mean much on its own 🤷‍♀️. It gets used together with the NSLP identifier (NSLPID) and the Message Routing Information (MRI). That 3-tuple is what GIST uses to index and manage signaling flows 🗂️. If routing changes or IP addresses change dynamically, for example because of mobility, GIST will have to modify Messaging Associations (MAs) that are already established. Those MAs are what carry NSLP messages between adjacent GIST peers, and they need to be changed so they still satisfy the NSLP MRI for each SID 😭.

The first phase of the protocol suite came with some design restrictions 🚧. They might get lifted later, and new functionality may be added to the protocols at some later stage 🌟.

  • Initial focus on MRMs for path-coupled signaling: GIST carries messages toward an identified unicast data flow destination, based on the signaling application's request. It doesn't directly support path-decoupled signaling, like QoS signaling sent to a bandwidth broker or some other off-path resource manager 🙅‍♀️. The framework does support a Loose End MRM, which is 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 find a NAT along the upstream data path 🔍.
  • No multicast support: Adding multicast was considered too much overhead, given how limited global IP multicast support currently is 📉. So the current GIST and NSLP specs only consider unicast flows 💖.

The key documents specifying the NSIS framework are 📚:

  • Requirements for Signaling Protocols [RFC3726]
  • Next Steps in Signaling: Framework [RFC4080]
  • Security Threats for NSIS [RFC4081]

The protocols that make up the suite specified by the NSIS Working Group are documented in 🎀:

  • The General Internet Signaling Transport protocol [RFC5971]
  • Quality-of-Service NSLP (QoS NSLP) [RFC5974]
  • The QoS specification template [RFC5975]
  • NAT/firewall traversal NSLP [RFC5973]

The next three sections give a quick tour of GIST, the QoS NSLP, and the NAT/firewall NSLP 🫧.

3. The General Internet Signaling Transport ✨

okay so the General Internet Signaling Transport, or GIST [RFC5971], is the thing that gives signaling transport and security services to NSIS Signaling Layer Protocols (NSLP) and their signaling apps 💖 GIST doesn't invent brand new IP transport protocols or security mechanisms, bestie. It borrows what already exists, like TCP, UDP, TLS, and IPsec 🎀 An app can say what transport vibe it wants for its signaling flow, like unreliable or reliable, and then GIST picks the best transport protocol(s) to match. Normally GIST goes with UDP if unreliable is fine, TCP if reliability matters, and TLS over TCP for flows that need to be secure (and reliable) 🔒 There are also extensibility hooks in GIST, so alternatives can be specified later on. Here's the NSIS layered protocol stack, shown in Figure 1 🦋

            +-----+ +--------+ +-------+
            |     | |        | |       |
            | 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 chops the data flow's end-to-end path into a bunch of segments, with each segment sitting between a pair of NSIS-aware peer nodes along the path 🛤️ Not every router or middlebox on the path has to be NSIS aware, so each segment can cover several routing hops, which is so relatable honestly 🙈 Also, not every NSIS-aware node has to run every signaling app. If the signaling for a flow only asks for some of the apps, then only the nodes running those services are expected to show up as peers ✨ Even some of those nodes can say "nope, not this flow" if, say, the extra load would overwhelm their processing power 💀 Because of all this, NSIS can be rolled out incrementally, both with the initial protocol suite and with any future NSLP apps that get developed 🌈 The next paragraphs explain how a signaling segment gets set up to offer the transport and security characteristics that one NSLP needs.

When an NSLP app wants to send a message toward a flow endpoint, GIST starts hunting for the next signaling node by sending a Query message toward the destination of the related data flow 🔍 This Query carries the NSLP identifier (NSLPID) and Message Routing Information (MRI), among other things. The MRI has enough info to control how the signaling message gets routed and to identify the associated data flow 🧚 The next GIST node on the path gets the message, and if it's running the same NSLP, it hands the MRI to its NSLP app and asks the app to decide whether to peer with the node that sent the query 👑 If the app says yes, GIST sets up a Message Routing State (MRS) between the two nodes so NSLP data can be exchanged later on 💅 State setup happens through a three-way handshake. That handshake lets the two sides negotiate signaling flow parameters, and it has defenses against attacks like denial-of-service, using cookie mechanisms and a late state installation option 🛡️

If a transport connection is needed to provide reliable or secure signaling, like TCP or TLS/TCP, then a Messaging Association (MA) gets set up between the two peers 🫶 An MA can be reused for signaling messages about several different data flows. In other words, signaling messages between two nodes get multiplexed over the same transport connection ✨ This works when a new flow's transport requirements (reliability, security) can be met by an existing MA. That means the security and transport properties of an existing MA are equivalent to or better than what's requested for a potential new MA 💖

For path-coupled signaling, the nodes on the data path that should take part in an NSLP's signaling need to be found and invoked to act when NSLP signaling messages arrive ⭐ The big idea is that those nodes along a flow's data path intercept the matching signaling packets, so they get discovered automatically 🔥

GIST puts a Router Alert Option (RAO) in Query message packets so they get intercepted by the relevant NSIS-aware nodes, the same way RSVP does 🎀

Late in GIST's development, the IETF raised serious concerns about the security risks and performance implications of heavy RAO usage [RAO-BAD] 😭 Evidence also turned up showing that several existing RAO implementations didn't match the (intention of the) standards and wouldn't support NSIS usage 🙈 There were worries too that making routers' fast paths (which are often hardware) recognize RAO would delay or discourage NSIS implementation and deployment 🍓 In the end, NSIS kept RAO as its main way to trigger interception of signaling messages at intermediate nodes on the data path. But the protocol suite got published with Experimental status instead of on the Standards Track, so deployment experience could be gathered first 🧚 More info about RAO use in GIST is in [GIST-RAO]. The deployment issues that come with RAO are discussed in Section 6.1 🦋

Alternatives have been considered for letting nodes recognize NSIS signaling packets that should be intercepted. For example, NSIS nodes could treat UDP packets sent to a specific destination port as Query messages that need interception, even when they aren't addressed to the intercepting node 🌸 GIST leaves room for these alternatives as part of its extensibility design. NSIS also recognizes that the workload of intercepting signaling packets can be pretty heavy compared to just forwarding them 😭 To keep that load down, NSIS has mechanisms that limit the number of interceptions by constraining how fast Queries get generated and by letting nodes intentionally bypass signaling nodes that aren't affected by a particular signaling request ✨ This can happen in GIST or in the NSLP 💅

Since GIST carries information about the data flow inside its messages (in the MRI), NAT gateways have to be aware of GIST for it to work correctly 🚧 GIST has a special object for NAT traversal, so the actual translation is disclosed if a GIST-aware NAT gateway provides this object 🫶

Just like with RSVP, all the state NSIS protocols install is "soft-state" that expires and gets removed automatically unless it's periodically refreshed ⏳ NSIS state lives both at the signaling application layer and in the signaling transport layer, and each layer keeps its own separate copy 🧁 NSLPs control how long state lasts at the application layer by setting a timeout and sending periodic "keep alive" messages along the signaling path when no other messages are needed 💜 The MAs and routing state are maintained semi-independently by the transport layer. That's because MAs can be shared by multiple NSLP sessions, and they can also be recreated "on demand" if the node needs to reclaim resources 🔄 The transport layer can send its own "keep alive" messages across an MA when no NSLP messages have gone out, for example if it decides to keep a heavily used MA alive even though no current NSLP session is using it 🌈 Local state can also be deleted explicitly once it's no longer needed 🗑️

If the route a flow uses changes for a flow that NSIS has created state for, NSIS has to notice the change so it can figure out whether the new path has extra NSIS nodes that need state installed 🗺️ GIST can use a range of triggers to detect a route change. It probes for the next peer periodically by sending a GIST Query, which catches a changed route and GIST peer along the way ✨ GIST also monitors routing tables and GIST peer states, and it notifies NSLPs of any routing changes 📣 From there it's up to the NSLPs to act appropriately if needed, for example by issuing a refresh message 💅 Those periodic queries also keep soft-state alive in nodes for as long as the route stays the same 🌷

In summary, GIST gives upper-layer signaling protocols several services in one package 🎁

  • Signaling peer discovery: GIST can find the next-hop node that runs the NSLP being signaled for 🔍
  • Multiplexing: GIST reuses already established signaling relationships and messaging associations to next-hop peers when the signaling flows need the same transport attributes 🫶
  • Transport: GIST provides transport with different attributes, namely reliable/unreliable and secure/unsecure 🚀
  • Security: If security is requested, GIST uses TLS to provide an encrypted and integrity-protected message transport to the next signaling peer 🔐
  • Routing changes: GIST detects routing changes, but instead of acting on its own, it just sends a notification to the local NSLP. It's then up to the NSLP to act 👑
  • 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 🧩
  • 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 🧚

4. Quality-of-Service NSLP ✨

okay so the Quality-of-Service (QoS) NSIS Signaling Layer Protocol (NSLP) is the one that sets up and keeps up state at the nodes along a data flow's path so that flow gets some forwarding resources 💅 it's meant to meet the QoS requirements in RFC 3726 [RFC3726]. bestie, no support for QoS setups built on bandwidth brokers or other off-path resource managers is in there yet 🙈

the design is kinda like RSVP, RFC 2205 [RFC2205] 🦋 and it uses soft-state peer-to-peer refresh messages as the main way to manage state. so state gets installed and refreshed between pairs of neighboring NSLP nodes, not end-to-end across the whole signaling path. it's giving neighborhood gossip 🌸 the QoS NSLP also stretches the reservation options to hit the RFC 3726 [RFC3726] requirements, like sender- or receiver-initiated reservations, a bidirectional kind of reservation, and reservations between arbitrary nodes (edge-to-edge, end-to-access, etc.). the one thing it doesn't do is IP multicast, sorry babe 😭

here's the vibe check: the QoS NSLP keeps the signaling separate from the info the Resource Management Function (RMF) needs. the RMF stuff rides along in the QSPEC (QoS Specification) object inside QoS NSLP messages. this is similar to how RSVP got decoupled from the IntServ architecture, RFC 1633 [RFC1633] 👑 the QSPEC carries info on resources available, resources required, traffic descriptions, and anything else the RMF needs. a template for QSPEC objects is defined in [RFC5975] ✨ it gives you a bunch of basic parameter objects you can use as a shared language for describing the parts of concrete QoS models. the objects in [RFC5975] are the building blocks for lots of existing QoS models, like the ones tied to RSVP and Differentiated Services. and the template is extensible, so new QoS model specs can extend the template language whenever they need to 🧚

the QoS NSLP supports different QoS models because it doesn't define which QoS mechanisms and RMF a domain has to use. as long as a domain knows how to do admission control for a given QSPEC, the QoS NSLP honestly doesn't care how the constraints get enforced and met. for example, the flow might go in the topmost of four Diffserv classes, or in the third highest of twelve Diffserv classes 🎀 which QoS configuration gets used is totally up to the network provider of the domain. the QSPEC can be seen as a common language for expressing QoS requirements across different domains and QoS models 🌈

in short, the QoS NSLP does:

  • Conveying resource requests for unicast flows
  • Resource requests (QSPEC) that are decoupled from the signaling protocol (QoS NSLP)
  • Sender- and receiver-initiated reservations, as well as bidirectional
  • Soft-state and reduced refresh (keep-alive) signaling
  • Session binding, i.e., session X can be valid only if session Y is also valid
  • Message scoping, end-to-end, edge-to-edge, or end-to-edge (proxy mode)
  • Protection against message re-ordering and duplication
  • Group tear, tearing down several sessions with a single message
  • Support for rerouting, e.g., due to mobility
  • Support for request priorities and preemption
  • Stateful and stateless nodes: stateless operation is particularly relevant in core networks where large amounts of QoS state could easily overwhelm a node
  • Reservation aggregation

the protocol also has a proxy mode so QoS signaling can work without every end-host needing to handle NSIS signaling 💖 and the QSPEC template handles situations where QoS parameters need to be fine-grained, aimed at one individual flow in one part of the network (usually the edge or access part). it can also be coarse-grained, where the flow is part of an aggregate (usually in the core of the network) 🫶

5. NAT/Firewall Traversal NSLP ✨

the NAT/firewall traversal NSLP [RFC5973] lets end-hosts talk to the NAT and firewall devices sitting in the data path 💅 basically it lets you dynamically configure NATs and/or firewalls along the data path so data flows can get through without being blocked. for instance, firewall pinholes can be opened on demand by authorized hosts. and it's also possible to block unwanted incoming traffic on demand, e.g., if an end-host is under attack 😭

configurations that the NAT/firewall NSLP signals to NAT and firewall devices take the form of a (pattern, action) pair 🦋 the pattern is a template for the packet header fields to be matched. the device is then expected to apply the specified action to any passing packet that matches the template. right now the actions are limited to ALLOW (forward the packet) and DENY (drop the packet). the template spec lets you match a wider range of packet fields than the GIST MRI allows for 🔥

basically, NAT/firewall signaling starts at the data sender (NSIS Initiator) before any actual application data packets get sent 🌸 signaling messages might pass through several middleboxes that understand the NAT/firewall NSLP (NSIS Forwarders) on their way downstream, and they usually end up at the receiver (the NSIS Responder). there's also a proxy mode for when the NAT/firewall NSLP isn't fully supported along the whole data path. the NAT/firewall NSLP is built on a soft-state concept, which means the sender has to periodically repeat its request to keep it active ⭐

the protocol also has functions for receivers behind NATs 🧚 the receiver can request an external address that's reachable from outside. but that reserved external address has to be communicated to the sender out-of-band, by other means, e.g., through application-level signaling. after that step, the data sender can start a normal NAT/firewall signaling to create firewall pinholes 🎀

and yep, there's a proxy mode here too, so NAT/firewall signaling can work without needing every end-host to handle NSIS signaling 💜

6. Deploying the Protocols ✨

so the initial version of the NSIS protocol suite is being published with the status of Experimental, so everyone can gain deployment experience 🧪 concerns about the security, implementation, and administrative issues around using RAO mean the first deployments will probably happen in "walled gardens" 🏰 where the hardware characteristics are well-known and there's a high level of trust and control over the end nodes that use the protocols. this section covers the issues you need to think about when deploying the NSIS protocol suite 💅

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 (like a resource management function for QoS admission control, etc.) must be implemented. NSIS can be deployed incrementally, and an initial deployment doesn't need to involve every node in a network domain. this is discussed further in Section 6.3 🦋 there are also a number of obstacles that might come up because of broken implementations of RAO (see Section 6.1) and because of firewalls or NATs that drop NSIS signaling packets (see Section 6.2) 😭

another big one: applications may need to be made NSIS-aware, which means some effort from the applications' programmers 🙈 or, alternatively, it may be possible to build separate applications that control things like 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

okay this part is the RAO drama 🍓 the standardized version of GIST depends on routers and other middleboxes correctly recognizing and acting on packets that contain RAO. there are a few problems with RAO that can get in the way of an NSIS deployment:

  • Some implementations do not respond to RAO at all.
  • Some implementations respond but do not distinguish between the RAO parameter values in IPv4 packets, or they reject anything except 0 (in which case, only the value 0 can be used).
  • 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 won't normally have a regular UDP receiver for these packets, they get dropped 😭
  • The major security concern with RAO in NSIS is that it gives hosts a new way to mount a (distributed) denial-of-service (DDoS) attack on the control plane of routers on the data path. these attacks have happened before, so it's normal for service providers to block "host-to-router" signaling packets such as RSVP or NSIS from entering their networks from customer networks. this will tend to limit NSIS deployment to "walled gardens" unless a suitable mitigation of the DDoS threat can be found and deployed 🔥

to deploy NSIS effectively, routers and other hardware need to be selected and correctly configured to respond to RAO and to dispatch intercepted packets to the NSIS function 💖

here's another obstacle: IPv4 packets with IP options of any kind will likely get filtered and dropped by firewalls and NATs 💀 in lots of cases that's the default behavior, so explicit configuration is needed to let packets carrying the RAO through. domain administrators generally want to deny access to packets carrying IP options because of the security risks and the extra load on the routers in the domain. the situation with IPv6 might be easier, since the RAO option in IPv6 is better defined, but the security concerns still stick around 🫶

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 can also hold up the initial deployment of NSIS protocols, for a few reasons 🌸

  • They may filter and drop signaling traffic (as described in Section 6.1) to deny access to packets containing IP options.
  • They may not permit "unsolicited" incoming GIST Query mode packets. this behavior was anticipated in the design of the protocols, but it requires additional support to make sure the middleboxes are primed to accept the incoming queries (see [RFC5974] and [RFC5973]) 🎀
  • NATs that aren't aware of the NSIS protocols will generally perform address translations that aren't coordinated with the NSIS protocols. since NSIS signaling messages may carry 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 ✨

okay bestie, NSIS is literally built to roll out bit by bit 🦋 Not every node on the signaling and data path has to be NSIS aware. To use NSIS at all, though, at least two nodes on the path need to be aware. The initiator and receiver of the data flow don't have to be NSIS aware either 🙈 Both the QoS and NAT/firewall NSLPs have "proxy modes", where nodes right next to the initiator and/or receiver can act as a proxy signaling initiator or receiver. An initiator proxy can watch traffic and, hopefully, notice when a data flow that needs NSIS support is starting up 👀 The proxies can work more or less invisibly for the flow's initiator and/or receiver, setting up the NSIS state and keeping it alive while the data keeps flowing 💅 So you don't have to upgrade every single endpoint before NSIS is viable 🌸

7. Security Features 🔐

Basic security stuff lives at the GIST layer 🛡️, like protection against some blind attacks and denial-of-service attacks. But heads up: bringing in alternative MRMs might open attack avenues that the current path-coupled MRM doesn't have 😭 Honestly, it's hard to defend against an on-path attacker and man-in-the-middle attacks when you're using path-coupled MRMs, because a core GIST job is discovering signaling peers it doesn't know about yet 💀

Transport security can be requested by signaling applications, and it's done with TLS between signaling peers, so the authenticity and confidentiality of signaling messages can be assured between peers 🔒 GIST lets signaling peers do mutual authentication (using TLS stuff like certificates), and it can check the authenticated identity against a database of nodes allowed to take part in GIST signaling. Whether you verify and accept a peer's identity once that secure TLS connection is set up, though, is a matter of policy 📋

While GIST handles authentication of peer nodes, the NSLP protocols may need finer-grained authorization 🧚 There's ongoing work to specify common authorization mechanisms for NSLP protocols [NSIS-AUTH], so things like per-user and per-service authorization become possible.

8. Extending the Protocols 🧩

This section talks about the ways 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: a generic transport layer, plus specific signaling-layer protocols for particular applications running over that transport. It's designed to be super extensible so it can adapt to different signaling needs 🌈

More signaling requirements are expected to show up in the future. The two-layer approach lets NSLP signaling applications be developed independently of the transport protocol, so new NSLPs can be built and deployed for new needs using the same GIST infrastructure. That gives you a kind of macro-extensibility 💖 The GIST protocol and both signaling applications were designed so extra capabilities can be added if requirements within the general scope of these protocols need accommodating ✨

NSIS is also big on incremental deployment 🫶 A new NSLP doesn't need to be on every NSIS-aware node in a network or along a signaling path before you can start using it. Nodes that don't support the application yet will forward its signaling messages without complaint until they reach a node where the new NSLP is deployed.

One key feature of parameter objects carried in NSIS protocols is the so-called "Extensibility flags (A/B)" 🎀 All the existing protocols (and any future ones that conform to the standards) can carry new experimental objects. The A/B flags indicate whether a receiving node must interpret the object, or whether it can just drop it or pass it along in subsequent messages sent further down the path. That means you can define new objects without forcing every network entity to understand them 🫧

8.1. Overview of Administrative Actions Needed When Extending NSIS 📋

Generally, NSIS protocols can be extended in multiple ways, and many of them need unique code point values allocated in registries IANA maintains on behalf of the IETF 📝 This section and the following ones give an overview of the administrative mechanisms that might apply. The extensibility rules below are based on the procedures IANA uses to assign values: "IESG Approval", "IETF Review", "Expert Review", and "Private Use" (as specified in [RFC5226]). The right procedure for a particular type of code point is defined in one of the NSIS protocol documents, mostly [RFC5971].

Besides registered code points, all NSIS protocols provide code points for experimentation, usually within closed networks, as explained in [RFC3692]. There's no guarantee that independent experiments won't be using the same code point! 😬

8.2. GIST 🌊

GIST is extensible in several aspects, covered in the subsections below. These subsections point to sections in the GIST specification [RFC5971] where more information can be found. The bullet points at the end of each subsection list the formal administrative actions that need to be carried out when a new extension is standardized 📌

More generally, as Section 1 of the GIST specification says, the GIST design could be extended to cater for multicast flows and for situations where the signaling isn't tied to an end-to-end data flow. But it isn't clear whether this could be done in a totally backwards-compatible way, and it isn't considered within the extensibility model of NSIS 🤔

8.2.1. Use of Different Message Routing Methods 🛣️

Right now, 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 toward an explicit target address other than the (current) data flow destination. It's intended to help set up 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 🚧

  • 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, and in each case Datagram TLS (DTLS) provides the 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, which are allocated from an IANA registry if new protocols are to be used. See Sections 5.7 and 9 of the GIST specification [RFC5971].

  • 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]. 🧁

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

  • 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 ✨

okay so GIST already standardized a scheme that uses 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 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 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:

  • 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.
  • 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.
  • The logic required to determine if a packet should be intercepted needs to be kept simple to minimize the extra per-packet processing.
  • The mechanism should be applicable to both IPv4 and IPv6 packets.
  • 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.

  • 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].

  • 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], which allows a Query message to carry additional peering data to be used by the recipient in making the peering decision.

  • 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.

  • 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. It 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.

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

  • 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].
  • 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].
  • 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].
  • 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 ✨

okay bestie, designing a new NSLP is both super hard AND super easy 💅 it's giving "fun problem, big responsibility" energy.

New signaling apps with their own NSLPs can be built to run alongside the apps the NSIS working group already defined, or to replace them 🦋 If your app fits into the NSIS framework, it's expected to use GIST for signaling message transport plus the security stuff, which takes a whole pile of "lower-level" headaches off your plate 🫶 GIST gives you a bunch of functions through the API it exposes to your signaling app code. You can hand off stuff like channel security, transport characteristics, and signaling node discovery, and just focus on your actual app logic 💖

BUT (and this is a big but 😭) the network is dynamic, both routing-wise and in terms of which nodes are around. So your new NSLP has to think about at least these things:

  • Routing changes, e.g., due to mobility: GIST sends network notifications whenever something changes out there, like peers or routing paths. Every signaling app has to be able to handle these notifications and respond properly 🧚 GIST doesn't figure out what your NSLP should do about a given network event. It just hands the notification over and lets your app make the right call.
  • GIST indications: GIST also sends other notifications, for example when a signaling peer doesn't reply to refresh messages, or when a particular NSLP message didn't get delivered to the recipient. NSLP apps need to handle these events too 👑 Appendix B in the GIST specification covers the GIST-NSLP API and all the functionality it needs. Implementing that interface can be quite the challenge, though, because the pile of asynchronous notifications coming from GIST makes the NSLP more complicated to build 🙈
  • Lifetime of the signaling flow: NSLPs should tell GIST when a flow isn't needed anymore by using the SetStateLifetime primitive. This cuts down on bandwidth demands in the network 🌸
  • NSLP IDs: NSLP messages may be multiplexed over GIST MAs. So your new NSLP needs a unique NSLPID, which makes sure GIST delivers its messages to the right application 🎀 A single NSLP could use multiple NSLPIDs, for example to tell apart different classes of signaling nodes that handle different levels of request aggregation or alternative processing paths. Heads up: unlike GIST, the NSLPs don't offer a protocol versioning mechanism. If your new NSLP is an upgraded version of an existing one, it should be told apart by a different NSLPID 💅
    • A new generally available NSLP requires IESG approval for the allocation of a new NSLP ID [RFC5971]
  • Incremental deployment: It would generally be unrealistic to expect every node on the signaling path to have your new NSLP implemented right away, so new NSLPs need to allow for that 🍓 The QoS and NAT/firewall NSLPs are examples of techniques like proxy modes, which cover cases where the data flow originator and/or receiver doesn't implement the NSLP.
  • Signaling Message Source IP Address: It can be tricky for an NSLP that originates a signaling message to figure out which source IP address to put in the signaling messages. That address might be different from the data flow source address used in the MRI 🤔 This happens either when a node has multiple interfaces or when it's acting as a proxy for the data flow originator (which is typically expected 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 change the source IP address after the initial Query message has set up the flow path, so that ICMP messages get sent to the most appropriate node. In the proxy case, the data flow originator wouldn't know about the signaling flow, so ICMP messages about the signaling would be meaningless if passed on to it. So it's essential that an NSLP knows the position and role of the node it's running on, and has a way to work out the right source address to use and make sure it's used on signaling packets ✨
  • New MRMs: GIST currently defines two Message Routing Methods, and leaves the door open for new ideas 🌈 So a new NSLP might also need a new MRM. Path-decoupled routing is one example.
  • Cooperation with other NSLPs: Some apps might need resources from two or more different classes to work properly. The NSLPs managing those resources could work together so these requests get coordinated, which avoids wasting signaling bandwidth and prevents race conditions 🦋

Seriously though, the security considerations of a new NSLP need to be carefully analyzed 🔥 NSIS NSLPs get deployed in routers as well as host systems, so a badly designed NSLP could become an attack vector for network resources and end systems alike. The NSLP also must support authorization of users, and must allow the use of the GIST authentication and integrity protection mechanisms wherever users decide they're needed.

The API between GIST and NSLPs (see Appendix B in [RFC5971]) is super important to understand 💜 The abstract design in the GIST specification doesn't pin down the exact messaging between GIST and the NSLPs. What it does give you is an understanding of the interactions, especially which kinds of asynchronous notifications from GIST your NSLP must be ready to handle. The actual interface depends on each GIST implementation.

Messages that GIST sends 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 set aside for Private and Experimental use during development 🧪 Any new signaling application that's expected to be deployed generally on the Internet needs to use the registration procedure "IESG Approval" to request allocation of unique NSLPID value(s) from the IANA registry. There's more discussion of NSLPIDs in Section 3.8 of the GIST specification 🎀

9. Security Considerations 🔒

This document provides information to the community. It doesn't raise any new security concerns itself.

BUT any extensions made to the NSIS protocol suite will need to be carefully assessed for security implications 😭 This matters a LOT because NSIS messages are meant to be actively processed by the NSIS-capable routers they pass through, instead of just being forwarded like most IP packets. Extensions must provide ways to authorize the use of capabilities that might allocate resources, and they should recommend appropriate authentication and integrity protection measures, so that security issues get excluded or adequately mitigated wherever they're identified 🛡️

Authors of new NSIS extensions should review the analysis of security threats to NSIS documented in [RFC4081], and also consider whether the new extension opens up any new attack paths that need mitigating 👀

GIST offers facilities to authenticate NSIS messages and to make sure they're delivered reliably ✨ Extensions must allow these capabilities to be used in an appropriate manner to minimize the risk of NSIS messages being misused, and must recommend how they should appropriately be used.

If additional transport protocols are proposed for use with GIST, an appropriate set of compatible security functions must be made available alongside the transport protocol, to support the authentication and integrity functions expected from GIST 🔐

10. Acknowledgements 🫶

This document combines work that was 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 reviewed the "User's Guide" and gave valuable input. Teemu Huovila also gave 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 wrote the text for the original GIST section, which has since been heavily modified. Claudia Keppler gave 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.
  • [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 📚✨

Okay bestie, these are the informative references 🎀 They're the background reading that helps explain the spec, and they're not the core rules. Here's the whole list, complete and untouched 💅

[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.

[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.

Authors' Addresses 🫶

And that's the whole crew! Here are the authors and editor, with all their contact details, exactly as they were 🌸

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

That's the end of RFC 5978 🌈👑 Thanks for hanging with me through all 8 parts, you're literally the best 💖🦋

📦 where this page comes from