RFC 5971
GIST: General Internet Signalling Transport
RFC 5971: GIST: General Internet Signalling Transport 🦋
okay bestie, this one is a whole vibe 💖 Here's the header tea:
- Authors: H. Schulzrinne (Columbia U.) and R. Hancock (RMR) 🎀
- Category: Experimental 🧪
- ISSN: 2070-1721
- Date: October 2010 📅
- Obsoletes / Updates: no Obsoletes or Updates line appears in this header, so there's nothing listed there 🤷♀️
It's published by the IETF, which is the crew that writes the rules for how the Internet's protocols work. ✨
Abstract ✨
ok so this doc is all about how signalling messages travel. A signalling message is basically a note about one specific flow of data, and this spec says how those notes get routed and transported along the same path that flow takes through the network 🛣️
The trick is that it reuses existing transport and security protocols, sitting them all under one shared messaging layer called the General Internet Signalling Transport (GIST). GIST gives lots of different signalling apps one common service to plug into 🔌
Here's the cool part: GIST doesn't care about what the apps are actually saying. It manages its own internal state and sets up the transport and security protocols underneath, so messages can flow in both directions along the flow path. 💅
Put GIST together with those lower layers and you get a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework. Iconic, honestly 👑
Status of This Memo 📝
not gonna lie, this part is a bit formal, but it matters 🙈
This document is not an Internet Standards Track specification. It's being shared so people can examine it, try implementing it experimentally, and evaluate it 🧪
It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 5741 for the details. 🌸
For the latest status, errata, and feedback info, head to:
http://www.rfc-editor.org/info/rfc5971Copyright 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, which you can read at:
http://trustee.ietf.org/license-infoThese are in effect on the publication date, so please actually read them! They spell out your rights and restrictions for this doc 📜 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license. 💜
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation and Terminology . . . . . . . . . . . . 5
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 8
3.2. Modes and Messaging Associations . . . . . . . . . . . . 10
3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 11
3.4. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 13
3.5. GIST Peering Relationships . . . . . . . . . . . . . . . 14
3.6. Effect on Internet Transparency . . . . . . . . . . . . . 14
3.7. Signalling Sessions . . . . . . . . . . . . . . . . . . . 15
3.8. Signalling Applications and NSLPIDs . . . . . . . . . . . 16
3.9. GIST Security Services . . . . . . . . . . . . . . . . . 17
3.10. Example of Operation . . . . . . . . . . . . . . . . . . 18
4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 20
4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 21
4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 23
4.3. Basic GIST Message Processing . . . . . . . . . . . . . . 25
4.4. Routing State and Messaging Association Maintenance . . . 33
5. Message Formats and Transport . . . . . . . . . . . . . . . . 45
5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 45
5.2. Information Elements . . . . . . . . . . . . . . . . . . 48
5.3. D-mode Transport . . . . . . . . . . . . . . . . . . . . 53
5.4. C-mode Transport . . . . . . . . . . . . . . . . . . . . 58
5.5. Message Type/Encapsulation Relationships . . . . . . . . 59
5.6. Error Message Processing . . . . . . . . . . . . . . . . 60
5.7. Messaging Association Setup . . . . . . . . . . . . . . . 61
5.8. Specific Message Routing Methods . . . . . . . . . . . . 66
6. Formal Protocol Specification . . . . . . . . . . . . . . . . 71
6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 73
6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 75
6.3. Responder Node Processing . . . . . . . . . . . . . . . . 79
6.4. Messaging Association Processing . . . . . . . . . . . . 83
7. Additional Protocol Features . . . . . . . . . . . . . . . . 86
7.1. Route Changes and Local Repair . . . . . . . . . . . . . 86
7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 93
7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 99
7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 100
8. Security Considerations . . . . . . . . . . . . . . . . . . . 101
8.1. Message Confidentiality and Integrity . . . . . . . . . . 102
8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 102
8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 103
8.4. Denial-of-Service Prevention and Overload Protection . . 104
8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 106
8.6. Security Protocol Selection Policy . . . . . . . . . . . 108
8.7. Residual Threats . . . . . . . . . . . . . . . . . . . . 109
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 117
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.1. Normative References . . . . . . . . . . . . . . . . . . 118
11.2. Informative References . . . . . . . . . . . . . . . . . 119
Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 122
A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 122
A.2. General Object Format . . . . . . . . . . . . . . . . . . 123
A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 125
A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 134
Appendix B. API between GIST and Signalling Applications . . . . 143
B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 143
B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 145
B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 146
B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 147
B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 148
B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 148
Appendix C. Deployment Issues with Router Alert Options . . . . 149
Appendix D. Example Routing State Table and Handshake . . . . . 151the ToC is giant, but we are only getting started 🌈✨
1. Introduction ✨
okay so signalling is all about messing with state that lives inside network elements 🧚. "Messing with" can mean setting it up, changing it, or tearing it down, OR it can just mean watching state that some other mechanism is managing 👀. This spec is mainly about path-coupled signalling, which means controlling resources on the network elements that sit on the path a particular data flow takes 🛣️. The flow endpoints might be involved too, but they don't have to be. Examples of state management are network resource reservation, firewall configuration, and state used in active networking 🔥. Examples of state monitoring are finding out instantaneous path properties, like available bandwidth or cumulative queuing delay 📊. Every one of these uses of signalling gets called a signalling application 💖.
GIST assumes other mechanisms handle routing inside the network, and GIST is NOT designed to set up or change paths itself 🙅♀️. So it's complementary to protocols like Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [22] or LDP [23], not a rival to them 🫶. There are almost always more than two participants in a path-coupled signalling session, though not every node on the path has to join in 🌸. Honestly, supporting GIST and any signalling applications costs performance, so flow-level signalling is way more likely on edge devices than on core routers 💅. GIST path-coupled signalling doesn't directly support multicast flows. The current GIST design could be extended to do it, especially where the multicast replication points can be made GIST-capable ✨. GIST can also be extended to cover other kinds of signalling pattern that aren't related to any end-to-end flow in the network. In that case, the line between GIST and end-to-end higher-layer signalling will be drawn differently, or maybe not at all 🤷♀️.
Every signalling application needs a set of state management rules, plus protocol support to exchange messages along the data path 📨. A lot of that protocol support is shared by all or a large number of signalling applications, so it can be built as one common protocol 🎀. The NSIS framework given in [29] explains why the work is split between common and application-specific protocols. It also gives outline requirements for the common one, the NSIS Transport Layer Protocol (NTLP) 💜. Lots of framework concepts come from RSVP [14], and so do several parts of the GIST protocol design 🍓. The application-specific protocols are called NSIS Signalling Layer Protocols (NSLPs), and they're defined in separate documents 📄. The NSIS framework [29] and the accompanying threats document [30] are must-read background for this spec, including how GIST is expected to be used in different network types and what job it's expected to do 🧠.
This spec gives a concrete solution for the NTLP 🦋. It's built on existing transport and security protocols under a common messaging layer called the General Internet Signalling Transport (GIST) ✨. GIST does NOT handle signalling application state itself. That's the big difference from higher layer signalling protocols like SIP, the Real-time Streaming Protocol (RTSP), and the control component of FTP 🙈. Instead, GIST manages its own internal state, plus the configuration of the underlying transport and security protocols, so signalling messages get delivered for signalling applications in both directions along the flow path 🚀. So the whole purpose of GIST is to provide the shared stuff (node discovery, message routing, and message transport) in a way that's simple for multiple signalling applications to reuse 👑.
Here's how this spec is laid out 🗺️. Section 2 defines terminology, and Section 3 gives an informal overview of the protocol design principles and operation. The normative specification is mainly in Section 4 to Section 8. Section 4 describes the message sequences, and Section 5 covers their format and contents. The detailed bit formats are in Appendix A, so don't skip it 🔍. The protocol operation is captured as state machines in Section 6. Section 7 covers some more advanced protocol features, and security considerations are in Section 8 🔐. Appendix B describes an abstract API for the service GIST provides to signalling applications, and Appendix D has an example message flow 🎬. Some parts of the GIST design use packets with IP options to probe the network. That causes some migration issues for IPv4, which are discussed in Appendix C ⚠️.
Because the NSIS protocol suite is layered, extending the protocols for a new signalling requirement could happen within GIST, within the signalling application layer, or both 🧩. General guidelines on how to extend each layer of the suite, and in particular when and how it's appropriate to extend GIST, are in a separate document [12] 📚. In this document, Section 9 gives the formal IANA considerations for the registries defined by the GIST specification 🗂️.
2. Requirements Notation and Terminology 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3] 🎀. That's the official rulebook for how those capital words work, so read it if you're unsure ✨.
The terminology used in this spec is defined in this section 📖. The basic entities that matter at the GIST level are shown in Figure 1 🖼️. The diagram specifically separates the different address types, depending on whether they're tied to a flow (end-to-end addresses) or to signalling (addresses of adjacent signalling peers) 💜.
Source GIST (adjacent) peer nodes Destination
IP address IP addresses = Signalling IP address
= Flow Source/Destination Addresses = Flow
Source (depending on signalling direction) Destination
Address | | Address
V V
+--------+ +------+ Data Flow +------+ +--------+
| Flow |-----------|------|-------------|------|-------->| Flow |
| Sender | | | | | |Receiver|
+--------+ | GIST |============>| GIST | +--------+
| Node |<============| Node |
+------+ Signalling +------+
GN1 Flow GN2
>>>>>>>>>>>>>>>>> = Downstream direction
<<<<<<<<<<<<<<<<< = Upstream direction
Figure 1: Basic Terminology[Data] Flow: A set of packets identified by some fixed combination of header fields 📦. Flows are unidirectional, so a bidirectional communication counts as a pair of unidirectional flows ↔️.
Session: A single application layer exchange of information for which some state information is to be manipulated or monitored 💬. Check out Section 3.7 for more detail 🔎.
Session Identifier (SID): An identifier for a session. The syntax is a 128-bit value that is opaque to GIST 🔢.
[Flow] Sender: The node in the network that is the source of the packets in a flow. A sender could be a host, or a router if, for example, the flow is actually an aggregate 🚢.
[Flow] Receiver: The node in the network that is the sink for the packets in a flow 🎯.
Downstream: In the same direction as the data flow ➡️.
Upstream: In the opposite direction to the data flow ⬅️.
GIST Node: Any node supporting the GIST protocol, no matter which signalling applications it supports 🌈.
[Adjacent] Peer: The next node along the signalling path, in the upstream or downstream direction, that a GIST node explicitly interacts with 🫂.
Querying Node: The GIST node that starts the handshake process to discover the adjacent peer 🔍.
Responding Node: The GIST node that answers the handshake and becomes the adjacent peer to the Querying node 🤝.
Datagram Mode (D-mode): A way of sending GIST messages between nodes without using any transport layer state or security protection 🌸. Datagram mode uses UDP encapsulation, with source and destination IP addresses derived either from the flow definition or from previously discovered adjacency information 🧾.
Connection Mode (C-mode): A way of sending GIST messages directly between nodes using point-to-point messaging associations (see below) 🔗. Connection mode lets you reuse existing transport and security protocols where that kind of functionality is needed 🔁.
Messaging Association (MA): A single connection between two explicitly identified GIST adjacent peers, meaning between a given signalling source and destination address 🤍. A messaging association may use a transport protocol. If security protection is required, it may use a network layer security association, or use a transport layer security association internally 🛡️. A messaging association is bidirectional, so signalling messages can be sent over it in either direction, referring to flows of either direction ↕️.
[Message] Routing: Message routing is the process of working out which GIST peer is next along the signalling path 🧭. For signalling along a flow path, the message routing GIST does is built on top of normal IP routing. That means packets get forwarded within the network layer based on their destination IP address 📬. In this document, "routing" generally means GIST message routing, unless it's specified otherwise 💡.
Message Routing Method (MRM): There can be different algorithms for discovering the route that signalling messages should take 🗺️. These are called message routing methods, and GIST supports alternatives within a common protocol framework 🎛️. See Section 3.3 👀.
Message Routing Information (MRI): The set of data item values used to route a signalling message according to a particular MRM 🏷️. For example, for routing along a flow path, the MRI includes flow source and destination addresses, plus protocol and port numbers 🔑. See Section 3.3 👀.
Router Alert Option (RAO): An option that can be included in IPv4 and v6 headers to help with the packet interception process 🚨. See [13] and [17] 📎.
Transfer Attributes: A description of the requirements a signalling application has for the delivery of a particular message, for example whether the message should be delivered reliably 📬. See Section 4.1.2 ✨.
3. Design Overview 🌟
3.1. Overall Design Approach ✨
okay so the NSIS framework [29] says the generic requirements for moving signalling messages around come down to two big things, bestie 💅
- Routing: figure out how to reach the adjacent signalling node in each direction of the data path (the GIST peer), and if needed, explicitly set up the addressing and identity info for that peer 🗺️
- Transport: actually deliver the signalling info to that peer 📬
for routing, one option is for the node to use its local routing state to explicitly work out who the GIST peer is. GIST defines a three-way handshake that probes the network and sets up the routing state between adjacent peers. and get this, signalling applications can also swap data during that handshake 🤯 the whole vibe is so efficient.
once routing is sorted, the node has to pick a way to transport the message to the peer. GIST splits the transport job into two parts: a minimal capability that GIST provides itself, plus well-understood transport protocols for the harder cases 🧩. the minimal part (more details later) is only for messages that are sized well below the lowest MTU (maximum transmission unit) along a path, that are infrequent enough not to worry about congestion and flow control, and that don't need security protection or guaranteed delivery. so it's the cute little messages only 🎀
in [29], all of these routing and transport requirements get assigned to one notional protocol called the NSIS Transport Layer Protocol (NTLP). GIST splits the transport problem instead, which gives the NTLP a layered structure: a specialised GIST messaging layer running on top of standard transport and security protocols 🍰 the basic concept is in Figure 2. just a heads up, not every combo of transport and security protocols shown in the figure actually works with GIST. the combos this specification allows are defined in Section 5.7 🙈 the figure also shows GIST offering its services to upper layers through an abstract interface, the GIST API, which we'll talk about in Section 4.1.
^^ +-------------+
|| | Signalling |
NSIS +------------|Application 2|
Signalling | Signalling +-------------+
Application |Application 1| |
Level +-------------+ |
|| | |
VV | |
========|===================|===== <-- GIST API
| |
^^ +------------------------------------------------+
|| |+-----------------------+ +--------------+ |
|| || GIST | | GIST State | |
|| || Encapsulation |<<<>>>| Maintenance | |
|| |+-----------------------+ +--------------+ |
|| | GIST: Messaging Layer |
|| +------------------------------------------------+
NSIS | | | |
Transport ..........................................
Level . Transport Layer Security (TLS or DTLS) .
(NTLP) ..........................................
|| | | | |
|| +----+ +----+ +----+ +----+
|| |UDP | |TCP | |SCTP| |DCCP| ... other
|| +----+ +----+ +----+ +----+ protocols
|| | | | |
|| .............................
|| . IP Layer Security .
|| .............................
VV | | | |
===========================|=======|=======|=======|============
| | | |
+----------------------------------------------+
| IP |
+----------------------------------------------+
Figure 2: Protocol Stack Architecture for Signalling Transport3.2. Modes and Messaging Associations ✨
okay the vibe here is that GIST has two internal modes of operation, and they're giving very different energy 💖
- Datagram mode (D-mode): for small, infrequent messages with modest delay constraints and no security requirements 📦 there's a special case of D-mode called Query-mode (Q-mode), which is used when no routing state exists 🔍
- Connection mode (C-mode): for literally all the other signalling traffic 🔗 it can handle large messages, supports channel security, and gives congestion control for signalling traffic 🛡️
C-mode can in principle use any stream or message-oriented transport protocol, but this specification picks TCP as the initial choice 🧦. it can also use specific network layer security associations or an internal transport layer security association, and this spec picks TLS as the initial choice 🔐. when GIST messages ride in C-mode, intermediate routers between the GIST peers treat them like any other traffic 🚦. and honestly? the routers literally couldn't do any processing on the messages without terminating the transport and security protocols being used 😭 so no peeking, periodt.
D-mode uses UDP, which is a NAT-friendly encapsulation that doesn't need per-message shared state kept between the peers 🦋. the long-term plan is for GIST to keep the simplicity of the current D-mode design 🌸. any extension to the security or transport capabilities of D-mode can be seen as picking a different protocol stack under the GIST messaging layer. that's then the same as defining another option inside the overall C-mode framework 🧚. this covers both using existing protocols and building a new message exchange and payload encapsulation just for GIST's requirements.
there's also a shortcut: if any necessary parameters (for example, a shared secret used for integrity or confidentiality protection) can be negotiated out-of-band, then the extra functions can be added straight into D-mode by adding an optional object to the message (see Appendix A.2.1) 🗝️. but with that approach, downgrade attacks (discussed in Section 8.6) would need to be prevented by policy at the destination node. ⚠️ this one's serious, so don't skip it!
Downgrade attacks in this approach would need to be prevented by policy at the destination node. Section 8.6 has the details.
it's possible to mix the two modes along a path 🌈. for example, you can use D-mode at the edges of the network and C-mode towards the core. this can make things more efficient for mobile endpoints, while letting shared security associations and transport connections carry messages for multiple flows and signalling applications 🫶. the setup for these protocols has an initialisation cost for using C-mode, but in the long run that cost gets shared across all the signalling sessions between peers. once the transport layer state exists, retransmission algorithms can work much more aggressively than they could in a pure D-mode design 🚀.
the routing and transport functions inside GIST are not independent, and that's important 🧠. if the message transfer has requirements that call for C-mode (say the message is so big that fragmentation is required), that can only be used between explicitly identified nodes. in those cases, GIST runs the three-way handshake first in D-mode to identify the peer, then sets up the necessary connections if they don't already exist 🤝. also, the signalling application does not pick D-mode or C-mode itself. GIST makes that call based on the message characteristics and the transfer attributes the application stated 💅. the distinction isn't visible at the GIST service interface, so the app never even sees it. iykyk 🙈
in general, the state for C-mode messaging to a particular peer (the signalling destination address, protocol and port numbers, internal protocol configuration, and state information) is called a messaging association (MA) ✨. MAs are totally internal to GIST, so signalling applications can't see them 🔒. even if GIST is using an MA to deliver messages about a particular flow, there's no direct one-to-one link between them. the GIST message routing algorithms look at each message in turn and pick an appropriate MA to carry it 🎯. there can be any number of MAs between two GIST peers, but the usual case is zero or one 💜. they get set up and torn down by management actions within GIST itself.
3.3. Message Routing Methods 🧭✨
okay so the baseline routing in GIST is that signalling messages follow a route defined by an existing flow in the network 🌊, visiting a subset of the nodes it passes through. this is the right vibe for app scenarios where the whole point of the signalling is to manipulate resources for that flow 💅. but there are scenarios where other behaviours are applicable, no cap 👀. two examples:
Predictive Routing: here the intent is to signal along a path that the data flow may follow in the future 🔮. possible cases are pre-installing state on the backup path that would be used if a link fails 🛟, and predictively installing state on the path used after a mobile node handover 📱.
NAT Address Reservations: this is for when a node behind a NAT wants to reserve an address where a sender on the other side can reach it 🏠. it needs a message sent outbound from what will be the flow receiver, even though no reverse routing state for the flow exists yet 🙈.
most of the GIST details don't care which routing behaviour is in use 🫶. so the GIST design wraps the routing-dependent details up as a message routing method (MRM), and lets multiple MRMs be defined 🌈. this spec defines the path-coupled MRM, which matches the baseline functionality above, and a second ("Loose-End") MRM for the NAT Address Reservation case 🎀. the detailed specs are in Section 5.8.
an MRM definition has the following content, using the path-coupled MRM as the example 💜:
- The format of the information that describes the path the signalling should take, the Message Routing Information (MRI). for the path-coupled MRM, this is just the flow identifier (see Section 5.8.1.1) plus some extra control information. specifically, the MRI always includes a flag to tell apart the two directions signalling messages can take, called 'upstream' and 'downstream' 🧭.
- A specification of the IP-level encapsulation of the messages that probe the network to discover the adjacent peers. a downstream encapsulation must be defined; an upstream encapsulation is optional 📦. for the path-coupled MRM, this info is in Section 5.8.1.2 and Section 5.8.1.3. current MRMs rely on intercepting probe messages in the data plane, but other mechanisms are possible within the overall GIST design and would suit other types of signalling pattern 🔍.
- A specification of what validation checks GIST should apply to the probe messages, for example to protect against IP address spoofing attacks 🛡️. the checks may depend on the direction (upstream or downstream) of the message. for the path-coupled MRM, the downstream validity check is basically a form of ingress filtering, also discussed in Section 5.8.1.2 🚧.
- The mechanism(s) available for route change detection, i.e., any change in the neighbour relationships that the MRM discovers. the default for any MRM is soft-state refresh, but extra supporting techniques may be possible; see Section 7.1.2 🔄.
also, heads up: NAT traversal may require translating fields in the MRI object carried in GIST messages (see Section 7.2.2) 👀. the generic MRI format includes a flag that must be given as part of the MRM definition, to say whether some kind of translation is needed 🚩. so developing a new MRM includes updates to the GIST spec, and may include updates to NAT behaviour specs too 🧩. those updates can happen in separate documents, which is what happens for NAT traversal for the base GIST MRMs, as described in Section 7.2.3 and [44] 📚.
the MRI is passed explicitly between signalling applications and GIST, so signalling application specs must define which MRMs they require 🫡. signalling apps may use fields in the MRI in their packet classifiers. if they use extra info for packet classification, that gets carried at the NSLP level and is invisible to GIST 🙈. any node hosting a particular signalling app needs a GIST implementation that supports the matching MRMs 💻. but GIST processing rules let nodes that don't host the app ignore its messages at the GIST level, so it doesn't matter whether those nodes support the MRM or not 🫶✨.
3.4. GIST Messages 💌
GIST has six message types: Query, Response, Confirm, Data, Error, and MA-Hello 🎉. apart from the messaging association protocols used by C-mode, all GIST communication is made of these messages. plus, all signalling application data rides along as extra payloads in these messages, next to the GIST info 🎁.
the Query, Response, and Confirm messages make up the handshake GIST uses to set up routing state and messaging associations 🤝. the handshake starts at the Querying node and heads toward the Responding node. the first message is the Query, which gets encapsulated in a specific way depending on the MRM, so it can probe the network infrastructure and the correct peer will intercept it and become the Responding node 🕵️♀️. a Query always triggers a Response going the reverse direction as the second message of the handshake 🔁. the content of the Response decides whether a Confirm gets sent. as part of the defence against denial-of-service attacks, the Responding node can delay state installation until a return routability check is done, and require the Querying node to finish the handshake with the Confirm message 🛑. also, if the handshake is setting up a new MA, the Response is required to request a Confirm 💅. all three of these messages can optionally carry signalling application data 📨. the full handshake is in Section 4.4.1.
the Data message exists purely to encapsulate and deliver signalling application data 📬. usually it's sent using pre-established routing state. but if there are no security or transport requirements and no need for persistent reverse routing state, it can also be sent the same way as the Query 🏃♀️. and finally, Error messages flag error conditions at the GIST level, and the MA-Hello message can act as a diagnostic and keepalive for the messaging association protocols 💖.
3.5. GIST Peering Relationships 👯♀️
peering is the process where two GIST nodes create message routing states that point to each other 💞.
a peering relationship can only be created by a GIST handshake 🔐. nodes become peers when one issues a Query and gets a Response back from another. issuing the initial Query happens because of an NSLP request on that node, and the Query itself is formatted by the rules of the MRM 📝. for current MRMs, the identity of the Responding node isn't known explicitly when the Query is sent. instead, the message gets examined by nodes along the path until one decides to send a Response and becomes the peer 🕊️. if the node hosts the NSLP, local GIST and signalling application policy decide whether to peer, and the details are in Section 4.3.2 ⚖️. nodes that don't host the NSLP forward the Query transparently (Section 4.3.4) 🚚. and note that the design of the Query message (see Section 5.3.2) means nodes have to opt in specifically to do the message interception. GIST-unaware nodes see the Query as a normal data packet and forward it transparently 🙌.
an existing peering relationship can only be changed by a new GIST handshake. in other words, it can only change when routing state is refreshed 🔁. on a refresh, if any of the factors in the original peering process have changed, the peering relationship can also change 🌀. besides network-level rerouting, changes could include modifications to NSIS signalling functions deployed at a node, or changes to signalling application policy 🛠️. a change could make an existing node drop out of the signalling path, or make a new node join it 🚪. GIST handles all of these possibilities as rerouting events. more details are in Section 7.1 📖.
3.6. Effect on Internet Transparency 🕵️♀️🌐
okay this part is a little serious, bestie 😭. GIST relies on routers inside the network to intercept and process packets that would normally go end-to-end. this processing may be non-transparent: messages may be forwarded with modifications, or not forwarded at all 🫣. the interception only applies to the encapsulation used for the Query messages that probe the network, for example along a flow path. all other GIST messages are handled only by the nodes they're directly addressed to, i.e., as normal Internet traffic 📭.
Because this interception can break Internet transparency for packets that have nothing to do with GIST, the encapsulation GIST uses in this case (called Query-mode or Q-mode) has several features to avoid accidental collisions with other traffic 🚨:
- Q-mode messages are always sent as UDP traffic, to a specific well-known port (
270) allocated by IANA 🔢. - All GIST messages sent as UDP have a magic number as the first 32-bit word of the datagram payload ✨.
even if a node intercepts a packet as potentially a GIST message, unless it passes both of these checks it gets ignored at the GIST level and forwarded transparently 🫶. more on the reception process is in Section 4.3.1, and the encapsulation is in Section 5.3 💜.
3.7. Signalling Sessions ✨
okay bestie, so GIST makes every signalling application attach each of its messages to a signalling session 🎀. Informally, if there's an application layer exchange where some network control state is gonna be manipulated or monitored, all the signalling messages for it should be associated with the same session 🦋. Signalling applications give over the session identifier (SID) whenever they wanna send a message, and GIST reports the SID when a message comes in 💅. On messages forwarded at the GIST level, the SID stays exactly the same, unchanged ✨.
NSLPs usually keep the SID value along the entire signalling path, ngl 💜. But GIST doesn't enforce that, and it can't even see it 🙈. GIST only sees the scope of the SID as the single hop between adjacent NSLP peers 🧚.
Most GIST processing and state info is tied to the flow (defined by the MRI; see above) and the signalling application (given by the NSLP identifier, see below) 👑. There are a few ways flows and sessions can relate, for example:
- The simplest case is that all signalling messages for the same flow have the same SID.
- Messages for more than one flow may use the same SID, for example, because one flow is replacing another in a mobility or multihoming scenario.
- A single flow may have messages for different SIDs, for example, from independently operating signalling applications.
Because of this range of options, GIST does not perform any validation on how signalling applications map between flows and sessions 🌸. It also doesn't do any direct validation on the properties of the SID itself, like enforcing uniqueness 🙃. GIST only defines the syntax of the SID as an opaque 128-bit identifier 🔥.
The SID assignment has the following impact on GIST processing:
- Messages with the same SID that are to be delivered reliably between the same GIST peers are delivered in order.
- All other messages are handled independently.
- GIST identifies routing state (upstream and downstream peer) by the
MRI/SID/NSLPIDcombination.
Strictly speaking, the routing state should not depend on the SID. But if the routing state is keyed only by (MRI, NSLP), there's a trivial denial-of-service attack (see Section 8.3) where a malicious off-path node asserts that it's the peer for a particular flow 😭. That attack wouldn't redirect the traffic, but it would reroute the signalling 💀. So the routing state is also segregated between different SIDs, which means the attacking node can only disrupt a signalling session if it can guess the corresponding SID 🛡️. Normative rules on the selection of SIDs are given in Section 4.1.3 💖.
3.8. Signalling Applications and NSLPIDs
okay so the functionality for signalling applications is supported by NSIS Signalling Layer Protocols (NSLPs) 🦋. Each NSLP is identified by a 16-bit NSLP identifier (NSLPID), assigned by IANA (Section 9) 🎀. A single signalling application, like resource reservation, may define a family of NSLPs to implement its functionality, for example, to carry out signalling operations at different levels in a hierarchy (cf. [21]) 🌈. However, the interactions between the different NSLPs (for example, to relate aggregation levels or aggregation region boundaries in the resource management case) are handled at the signalling application level 💅. The NSLPID is the only information visible to GIST about the signalling application being used 👀.
3.9. GIST Security Services
GIST has two distinct security goals, and we're not messing around with either one 🔐:
- to protect GIST state from corruption, and to protect the nodes on which it runs from resource exhaustion attacks; and
- to provide secure transport for NSLP messages to the signalling applications.
The protocol mechanisms for the first goal are mainly internal to GIST 🧱. They include a cookie exchange and return routability check to protect the handshake that sets up routing state, and a random SID is also used to prevent off-path session hijacking by SID guessing 🍓. Further details are given in Section 4.1.3 and Section 4.4.1, and the overall security aspects are discussed in Section 8 💜.
A second level of protection is provided by the use of a channel security protocol in messaging associations (i.e., within C-mode). This mechanism serves two purposes: to protect against on-path attacks on GIST and to provide a secure channel for NSLP messages. 🚨
For the mechanism to be effective, it must be able to provide the following functions:
- mutual authentication of the GIST peer nodes;
- ability to verify the authenticated identity against a database of nodes authorised to take part in GIST signalling;
- confidentiality and integrity protection for NSLP data, and provision of the authenticated identities used to the signalling application.
The authorised peer database is described in more detail in Section 4.4.2, including the types of entries that it can contain and the authorisation checking algorithm that is used 📚. The only channel security protocol defined by this specification is a basic use of TLS, and Section 5.7.3 defines the TLS-specific aspects of how these functions (for example, authentication and identity comparison) are integrated with the rest of GIST operation 🫶. At a high level, there are several alternative protocols with similar functionality, and the handshake (Section 4.4.1) provides a mechanism within GIST to select between them ✨. However, they differ in their identity schemes and authentication methods and dependencies on infrastructure support for the authentication process, and any GIST extension to incorporate them would need to define the details of the corresponding interactions with GIST operation 🌸.
3.10. Example of Operation 🎀
Okay bestie, let's walk through a GIST example. It's a pretty simple, NAT-free signalling setup, so you can see the main features without any translation drama 💅 Let's go!
GN1 GN2
+------------+ +------------+
NSLP | | | |
Level | >>>>>>>>>1 | | 5>>>>>>>>5 |
| ^ V | Intermediate | ^ V |
|-^--------2-| Routers |-^--------V-|
| ^ V | | ^ V |
| ^ V | +-----+ +-----+ | ^ V |
>>>>>>>>>^ >3>>>>>>>>4>>>>>>>>>>>4>>>>>>>>>5 5>>>>>>>>>
| | | | | | | |
GIST | 6<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<6 |
Level +------------+ +-----+ +-----+ +------------+
>>>>>, <<<<< = Signalling messages
1 - 6 = Stages in the example
(stages 7 and 8 are not shown)
Figure 3: Example of OperationSo picture this: an RSVP-like signalling app that makes receiver-based resource reservations for a single unicast flow ✨ Signalling can happen along the whole end-to-end path (flow source to destination), but GIST's job is only to move signalling messages over one segment, between neighbouring resource-capable nodes 🦋 Basic GIST operation is the same whether it's the endpoints or just interior nodes doing the work. Either way, GIST gets triggered by a request from a local signalling application 🫶 This example follows GN1 and GN2, two adjacent peers some distance along the path (see Figure 3). We pick up the story right where a message is being processed above the GIST layer by the signalling application in GN1.
- The signalling application in GN1 decides this message is a simple description of resources that would suit the flow 🌸 It has no special security or transport requirements for the message. It just wants the message passed to the next downstream signalling application peer on the path the flow will take.
- The message payload goes down to the GIST layer in GN1, along with a definition of the flow and the message transfer attributes. Here, it asks for no reliable transmission and no channel security protection 🙈 GIST works out that this message doesn't need fragmentation. It also doesn't know the next peer for this flow and signalling application. BUT, it figures this app will probably need secured upstream and downstream transport of large messages later 👀 That call comes from node-internal policy interactions between GIST and the signalling application, so it's a local decision.
- GN1 builds a GIST Query carrying the NSLP payload, plus extra GIST-level payloads that will be used to start a messaging association 📦 The Query gets wrapped in a UDP datagram and injected into the network. At the IP level, the destination address is the flow receiver, and an IP Router Alert Option (RAO) is included too.
- The Query travels toward the flow receiver and gets seen by each router in turn 🚀 GIST-unaware routers won't recognise the RAO value, so they just forward the message unchanged. GIST-aware routers that don't support the NSLP in question also forward it basically unchanged, though they might have to look at more of the message to figure that out after the first intercept.
- GN2 intercepts the message 🙌 The GIST layer sees that it's relevant to a local signalling application, and passes the NSLP payload and flow description up to it. That app in GN2 tells GIST it will peer with GN1, so GIST should go ahead and set up any routing state. The app also keeps processing the message just like GN1 did (compare step 1), and hands it back down to GIST so it gets sent further downstream. Eventually it reaches the flow receiver 🎯 GIST itself works hop-by-hop, and the signalling application is the one that stitches those hops together to manage the end-to-end signalling.
- At the same time, the GIST instance in GN2 now knows it should keep routing state and a messaging association for future signalling with GN1 💜 It knows this because the message is a Query, and because the local signalling application said it will peer with GN1. There are two possible cases for sending back the necessary GIST Response:
- 6.A - Association Exists: GN1 and GN2 already have an appropriate MA. GN2 just records GN1's identity as its upstream peer for that flow and NSLP, then sends a Response back to GN1 over the MA, identifying itself as the peer for this flow ✅
- 6.B - No Association: GN2 sends the Response in D-mode directly to GN1. It identifies itself and agrees to the messaging association setup. The protocol exchanges needed to finish that will happen in parallel with the stages that follow 🧚
Either way, GN1 and GN2 end up in a peering relationship for the flow. Slay 👑
- Eventually, another NSLP message makes its way upstream from the receiver to GN2 💌 This one has a description of the actual resources requested, plus authorisation and other security info. The signalling application in GN2 passes this payload down to the GIST level, along with the flow definition and transfer attributes. In this case, it could ask for reliable transmission and a secure channel for integrity protection. (Other combinations of attributes are possible, babe 💖)
- The GIST layer in GN2 identifies GN1 as the upstream peer for this flow and NSLP, and checks that it has an MA with the right properties 🎀 The message gets queued on the MA for transmission. This might be a bit delayed if the procedures started in step 6.B haven't finished yet.
More messages can go in each direction the same way 💅 Meanwhile, the GIST layer in each node can run maintenance operations in parallel, like route change detection (see Section 7.1) 🌈
It's important to understand that lots of these GIST details can be changed, either by local policy or based on signalling application requirements 🍓 The authoritative details are in the rest of this document, so that's where to look for the real rules 📖
4. GIST Processing Overview ✨
This section lays out the basic structure and operation of GIST 🧚 Section 4.1 covers how GIST talks to local signalling applications through an abstract service interface. Section 4.2 covers the per-flow and per-peer state GIST keeps so it can transfer messages. Section 4.3 explains how messages get processed when the needed messaging associations and routing state already exist. That includes pure D-mode operation, where no messaging associations are needed at all 🦋 Last but not least, Section 4.4 explains how routing state and messaging associations get created and managed.
4.1. GIST Service Interface 💖
This section describes the interaction between GIST and signalling applications through an abstract service interface. It also defines the attributes of message transfer that GIST can offer 🎀 The service interface here is non-normative. It doesn't constrain actual implementations of any interface between GIST and signalling applications. It's just here to help you understand how GIST can be used 🤓 That said, requirements on SID selection and on internal GIST behaviour that supports message transfer semantics (like in-order delivery) are stated normatively in this section.
The same service interface is presented at every GIST node. Applications might invoke it differently at different nodes, depending on local policy, for example 🌸 The service interface is also defined independently of any specific transport protocol, or even of the D-mode vs C-mode distinction. The first version of this specification defines how to support the service interface using a C-mode based on TCP 🔥 If more protocol support gets added later, it will support the same interface, so the change is invisible to applications, except maybe as a performance boost ⭐ A more detailed description of this service interface is in Appendix B.
4.1.1. Message Handling 🫧
Fundamentally, GIST is a simple message-by-message transfer service for signalling applications. Individual messages get sent, and individual messages get received 📨 At the service interface, the NSLP payload (which is opaque to GIST) comes with control information that says how the application wants the message routed (the MRI). The application also provides the session identifier (SID), see Section 4.1.3. Extra message transfer attributes control the specific transport and security properties the app wants 🔐
The D- and C-mode distinction isn't visible at the service interface. Fragmentation and reassembly, bundling small messages together for efficiency, and congestion control aren't visible there either 🙈 GIST takes whatever action is needed based on the message properties and local node state.
A signalling application is free to choose how fast it processes inbound messages. An implementation MAY let the application block accepting messages from GIST 🚦 In those situations, GIST MAY discard unreliably delivered messages. But for reliable messages, GIST MUST propagate the flow-control condition back to the sender. So apps need to be aware that they might end up blocked from sending outbound messages themselves 😭
4.1.2. Message Transfer Attributes ✨
okay bestie, NSLPs use message transfer attributes to set the minimum level of message processing they need 💅 there are three attributes, and they're giving main character energy:
- Reliability: this one can be
trueorfalse. when it'strue, these rules apply 🔥- messages MUST be delivered to the signalling application in the peer exactly once or not at all 🫶
- for messages with the same SID, the delivery MUST be in order 💖
- if there's a chance the message wasn't delivered (like in the case of a transport layer error), an error MUST be indicated to the local signalling application, identifying the routing information for the message in question 😭
GIST gets reliability by using an appropriate transport protocol inside a messaging association, so how message loss gets detected depends on that protocol 🌸 for the current spec, the TCP case is covered in Section 5.7.2. when it's false, a message may be delivered once, several times, or not at all, and there are no error indications in any of those cases 🦋
- Security: this defines the set of security properties the signalling application requires for the message. that includes the type of protection needed and which authenticated identities should be used for the signalling source and destination 🔐 this info maps onto the matching properties of the security associations set up between peers in C-mode. the keying material for those security associations comes from the authentication mechanisms inside the messaging association protocols themselves, so see Section 8.2 🧚 the app can set this attribute explicitly, or GIST can report it back to the app. the reporting can happen either when a message is received, or just before sending a message but after configuring or selecting the messaging association to be used for it ✨
This attribute can also carry info about any address validation GIST did, like whether a return routability check was carried out 👑 more details are in Appendix B.
- Local Processing: an NSLP can drop hints to GIST so processing is more efficient or appropriate 🍓 for example, the NSLP might pick a priority from a range of locally defined values to influence the order messages leave a node. any priority mechanism MUST respect the ordering requirements for reliable messages within a session, and priority values are not carried in the protocol or available at the signalling peer or intermediate nodes 🙈 an NSLP can also say that upstream path routing state won't be needed for this flow, which stops the node asking its downstream peer to create it. the other way round: even if routing state exists, the NSLP can request that it's not used, which means GIST Data messages get sent Q-mode encapsulated instead 💅
A GIST implementation MAY deliver messages with stronger attribute values than those explicitly requested by the application 🌈
4.1.3. SID Selection 🎀
the fact that SIDs index routing state (see Section 4.2.1 below) means there are rules for how they get selected 👀 signalling applications MUST choose SIDs so that they are cryptographically random, and SHOULD NOT use several SIDs for the same flow, to avoid extra load from routing state maintenance 💜 guidance on secure randomness generation can be found in [31].
4.2. GIST State 🦋
4.2.1. Message Routing State
for each flow, the GIST layer can maintain message routing state to manage the processing of outgoing messages 📋 it's conceptually organised into a table, and each row corresponds to a unique combination of these three items:
- Message Routing Information (MRI): this defines the method used to route the message, the direction to send it in, and any associated addressing information; see Section 3.3.
- Session Identifier (SID): the signalling session this message should be associated with; see Section 3.7.
- NSLP Identifier (NSLPID): an IANA-assigned identifier tied to the NSLP generating messages for this flow; see Section 3.8. including this identifier means the routing state can be different for different NSLPs 🍓
the info tied to a given MRI/SID/NSLPID combo is the routing state to reach the peer in the direction given by the MRI. usually there are two entries in the table for any flow, one each for the upstream and downstream MRI 🔥 the routing state includes info about the peer identity (see Section 4.4.3), plus a UDP port number for D-mode, or a reference to one or more MAs for C-mode. entries get created by the GIST handshake, which is described in more detail in Section 4.4 🫶
it's also possible for the state info in either direction to be empty 🙈 there are a few cases:
- the signalling application has indicated that no messages will actually be sent in that direction.
- the node is the endpoint of the signalling path, for example because it's acting as a proxy, or because it's determined there are no further signalling nodes in that direction.
- the node is using other techniques to route the message. for example, it can send it in Q-mode and rely on the peer to intercept it.
in particular, if the node is a flow endpoint, GIST will refuse to create routing state for the direction beyond the end of the flow (see Section 4.3.3) 🚫 each entry in the routing state table has an associated validity timer indicating how long it can be considered accurate. when that timer expires, the entry MUST be purged if it hasn't been refreshed ⏳ installation and maintenance of routing state are described in more detail in Section 4.4.
4.2.2. Peer-Peer Messaging Association State
the per-flow message routing state isn't the only state GIST stores 💅 there's also the state needed to manage the MAs. since these aren't per-flow, they're stored separately from the routing state, and include the following per-MA info:
- a queue of any messages that need an MA, pending transmission while the MA is being established;
- the time since the peer re-stated its desire to keep the MA open (see Section 4.4.5).
on top of that, per-MA state like TCP port numbers or timer info is held in the messaging association protocols themselves 🧚 but those details aren't directly visible to GIST, and they don't affect the rest of the protocol description ✨
4.3. Basic GIST Message Processing 💖
this section describes how signalling application messages get processed when any necessary messaging associations and routing state are already in place 🌸 it's split into a few parts. First, message reception, local processing, and message transmission are covered for when the node hosts the NSLPID identified in the message. Second, in Section 4.3.4, we get the case where the message is handled directly in the IP or GIST layer (because there's no matching signalling application on the node) 🎀 there's an overview in Figure 4 below. this section focuses on the GIST-level processing, with full details of IP and transport layer encapsulation in Section 5.3 and Section 5.4 🔥
+---------------------------------------------------------+
| >> Signalling Application Processing >> |
| |
+--------^---------------------------------------V--------+
^ NSLP NSLP V
^ Payloads Payloads V
+--------^---------------------------------------V--------+
| >> GIST >> |
| ^ ^ ^ Processing V V V |
+--x-----------N--Q---------------------Q--N-----------x--+
x N Q Q N x
x N Q>>>>>>>>>>>>>>>>>>>>>Q N x
x N Q Bypass at Q N x
+--x-----+ +--N--Q--+ GIST level +--Q--N--+ +-----x--+
| C-mode | | D-mode | | D-mode | | C-mode |
|Handling| |Handling| |Handling| |Handling|
+--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+
x N Q Q N x
x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x
x N Q Bypass at Q N x
+--x--N--+ +-----Q--+ IP (router +--Q-----+ +--N--x--+
|IP Host | | Q-mode | alert) level | Q-mode | |IP Host |
|Handling| |Handling| |Handling| |Handling|
+--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+
x N Q Q N x
+--x--N-----------Q--+ +--Q-----------N--x--+
| IP Layer | | IP Layer |
| (Receive Side) | | (Transmit Side) |
+--x--N-----------Q--+ +--Q-----------N--x--+
x N Q Q N x
x N Q Q N x
NNNNNNNNNNNNNN = Normal D-mode messages
QQQQQQQQQQQQQQ = D-mode messages that are Q-mode encapsulated
xxxxxxxxxxxxxx = C-mode messages
RAO = Router Alert Option
Figure 4: Message Paths through a GIST Node4.3.1. Message Reception 📬
Okay so messages can be received in C-mode or D-mode 🦋
Reception in C-mode is honestly so simple 💅. Incoming packets get the security and transport treatment tied to the MA, and then the MA hands complete messages up to the GIST layer for further processing ✨
Reception in D-mode depends on the message type 🌸, so let's break it down 🫶
- Normal encapsulation: Normal messages arrive UDP-encapsulated and are addressed straight to the receiving signalling node, at an address and port it learned earlier. Each datagram holds a single message, which gets passed to the GIST layer for further processing, just like in C-mode 🎀
- Q-mode encapsulation: When GIST sends messages that should be intercepted by the right peer instead of being addressed to it directly (Query messages especially 👀), these are UDP encapsulated, and they MAY include an IP Router Alert Option (RAO) if the MRM needs one. Every GIST node can therefore see every one of these messages, but unless the message exactly matches the Q-mode encapsulation rules (Section 5.3.2), it MUST be forwarded transparently at the IP level. If it does match, GIST MUST check the NSLPID in the common header. The case where the NSLPID doesn't match a local signalling application at all is covered below in Section 4.3.4; otherwise, the message MUST be passed up to the GIST layer for further processing 🧚
Several different RAO values may be used by the NSIS protocol suite 💜. GIST itself doesn't allocate any RAO values (for either IPv4 or IPv6). Instead, an assignment is made for each NSLP using MRMs that use the RAO in the Q-mode encapsulation, and the rationale for those assignments is discussed in a separate document [12]. The RAO value assigned for an NSLPID may be different for IPv4 and IPv6.
Note the different significance between the RAO and the NSLPID values! 🔥 The meaning of a message (which signalling application it refers to, and whether it should be processed at a node) is determined only from the NSLPID. The role of the RAO value is simply to let nodes pre-filter which IP datagrams get analysed to see if they might be Q-mode GIST messages.
For all assignments associated with NSIS, the RAO-specific processing is the same, and it's as defined by this specification, here and in Section 4.3.4 and Section 5.3.2 🌈
Immediately after reception, the GIST hop count is checked 👑. Any message with a GIST hop count of zero MUST be rejected with a "Hop Limit Exceeded" error message (Appendix A.4.4.2). Ngl, a correct GIST implementation will never send a message with a GIST hop count of zero 🙈. Otherwise, the GIST hop count MUST be decremented by one before the next stage.
4.3.2. Local Processing and Validation 🧁
Once a message has been received, it gets processed locally within the GIST layer ✨. Further processing depends on the message type and the payloads it carries. Most of the GIST payloads are tied to internal state maintenance, and those details are covered in Section 4.4.
This section focuses on the interaction with the signalling application, especially the decision to peer and how data gets delivered to the NSLP 💖
In the case of a Query, there's an interaction with the signalling application to decide which of two courses to follow. The first option (peering) MUST be chosen if the node is the final destination of the Query message 🎯
- The receiving signalling application wishes to become a signalling peer with the Querying node. GIST MUST continue with the handshake process to set up message routing state, as described in Section 4.4.1. The application MAY provide an NSLP payload for the same NSLPID, which GIST will transfer in the Response 🦋
- The signalling application does not wish to set up state with the Querying node and become its peer. This includes the case where a node wants to avoid taking part in the signalling for overload protection reasons 🫠. GIST MUST propagate the Query, similar to the case described in Section 4.3.4. No message is sent back to the Querying node. The application MAY provide an updated NSLP payload for the same NSLPID, which will be used in the Query forwarded by GIST. Note that if the node that finally processes the Query returns an Error message, this will be sent directly back to the originating node, bypassing any forwarders. For these diagnostics to be meaningful, any GIST node forwarding a Query, or relaying it with a modified NSLP payload, MUST NOT modify it except in the GIST hop count. In particular, it MUST NOT modify any other GIST payloads or their order. An implementation MAY choose to achieve this by retaining the original message, rather than reconstructing it from some parsed internal representation 🧠
This interaction with the signalling application, including the generation or update of an NSLP payload, SHOULD take place synchronously as part of the Query processing. In terms of the GIST service interface, this can be implemented by providing appropriate return values for the primitive that gets triggered when such a message is received. See Appendix B.2 for further discussion 🎀
For all GIST message types other than Queries, if the message includes an NSLP payload, this MUST be delivered locally to the signalling application identified by the NSLPID. The format of the payload isn't constrained by GIST, and the content isn't interpreted 🙌 Delivery is subject to the following validation checks, which MUST be applied in the sequence given:
- if the message was explicitly routed (see Section 7.1.5) or is a Data message delivered without routing state (see Section 5.3.2), the payload is delivered but flagged to the receiving NSLP to indicate that routing state was not validated;
- else, if the message arrived on an association that is not associated with the MRI/NSLPID/SID combination given in the message, the message MUST be rejected with an "Incorrectly Delivered Message" error message (Appendix A.4.4.4);
- else, if there is no routing state for this MRI/SID/NSLPID combination, the message MUST either be dropped or be rejected with an error message (see Section 4.4.6 for further details);
- else, the payload is delivered as normal 💜
4.3.3. Message Transmission ✨
Okay so signalling applications can cook up their messages whenever they want, either asynchronously or as a reply to a message GIST just delivered to them, and GIST can also generate messages on its own 💅. GIST MUST verify that it is not the direct destination of an outgoing message, and MUST reject such messages with an error indication to the signalling application. When the signalling application makes the message, it may be carried in a Query if local policy and the message transfer attributes allow it 🎀. Otherwise, this may trigger setup of an MA, and the NSLP payload gets sent in a Data message 🦋.
Signalling applications can set a value for the GIST hop count, and if they don't, GIST picks one itself 🧚. GIST MUST reject messages for which the signalling application has specified a value of zero 🙈. The GIST hop count is only there to control message looping at the GIST level, but the GIST API (Appendix B) hands the incoming hop count up to the NSLPs, and they can keep it on outgoing messages as they get forwarded further along the path. This gives NSLPs that don't define anything fancier a lightweight loop-control mechanism 🫶. Just note that the count gets decremented on forwarding through every GIST-aware node. What the initial values should be is an implementation matter. One suitable approach is to use the same algorithm as for IP TTL setting [1] 🌸.
When a message is ready to go, GIST uses internal policy and the stored routing state to figure out how to handle it 💖. This processing applies equally to locally generated messages and to messages forwarded from within the GIST or signalling application levels. However, see Section 5.6 for special rules that apply to the transmission of Error messages by GIST ⭐.
The big decision is whether the message has to be sent in C-mode or D-mode 👑. Reasons for using C-mode are:
- message transfer attributes: for example, the signalling application has specified security attributes that require channel-secured delivery, or reliable delivery 🔐.
- message size: a message whose size (including the GIST header, GIST objects and any NSLP payload, and an allowance for the IP and transport layer encapsulation required by D-mode) exceeds a fragmentation-related threshold MUST be sent over C-mode, using a messaging association that supports fragmentation and reassembly internally. The allowance for IP and transport layer encapsulation is 64 bytes. The message size MUST NOT exceed the Path MTU to the next peer, if this is known. If this is not known, the message size MUST NOT exceed the least of the first-hop MTU, and 576 bytes. The same limit applies to IPv4 and IPv6 📏.
- congestion control: D-mode SHOULD NOT be used for signalling where it is possible to set up routing state and use C-mode, unless the network can be engineered to guarantee capacity for D-mode traffic within the rate control limits imposed by GIST (see Section 5.3.3) 🚦.
In principle, as well as deciding that some messaging association has to be used, GIST MAY pick between a set of alternatives, for example for load sharing, or because different messaging associations give different transport or security attributes ⚖️. For reliable delivery, GIST MUST NOT distribute messages for the same session over multiple messaging associations in parallel. It MUST use a single association at any given time 🛤️. Moving over to a new association is covered in Section 4.4.5.
If C-mode is selected and a messaging association is used, the message gets queued on the association found in the routing state table, and further output processing happens according to the details of the protocol stacks used 🎀. If no appropriate association exists, the message gets queued while one is created (see Section 4.4.1), which will trigger the exchange of additional GIST messages 📨. If no association can be created, that's an error condition, and it should be indicated back to the local signalling application 🚨.
If a messaging association isn't appropriate, the message is sent in D-mode 🦋. What happens next depends on the message type, local policy, and whether or not routing state exists:
- If the message is not a Query, local policy does not request the use of Q-mode for this message, and routing state exists, it is sent with the normal D-mode encapsulation directly to the address from the routing state table 📬.
- If the message is a Query, or the message is Data and local policy as given by the message transfer attributes requests the use of Q-mode, then it is sent in Q-mode as defined in Section 5.3.2. The details depend on the message routing method 🧭.
- If no routing state exists, GIST can attempt to use Q-mode as in the Query case. It can either send a Data message with the Q-mode encapsulation, or use the event as a trigger for routing state setup (see Section 4.4). If this isn't possible, for example because the encapsulation for the MRM is only defined for one message direction, then that's an error condition that gets reported back to the local signalling application 😭.
4.3.4. Nodes not Hosting the NSLP 🏠
A node might receive messages where it has no signalling application matching the message NSLPID 👀. There are several possible cases, depending mainly on the encapsulation:
- A message contains an RAO value that is relevant to NSIS, but it doesn't exactly match the Q-mode encapsulation rules of Section 5.3.2. The message MUST be transparently forwarded at the IP layer. See Section 3.6.
- A Q-mode encapsulated message contains an RAO value that has been assigned to some NSIS signalling application, but that isn't used on this specific node. The IP layer can't tell whether it needs to be passed to GIST for further processing, or whether the packet should just be forwarded like a normal IP datagram 🤷♀️.
- A Q-mode encapsulated message contains an RAO value that has been assigned to an NSIS signalling application that is used on this node, but the signalling application doesn't process the NSLPID in the message. (This covers the case where a signalling application uses a set of NSLPIDs.)
- A directly addressed message (in D-mode or C-mode) is delivered to a node that has no corresponding signalling application. With the current specification, this should not happen in normal operation. Future versions might find a use for such a feature, but for now this MUST cause an "Unknown NSLPID" error message (Appendix A.4.4.6) 🚫.
- A Q-mode encapsulated message arrives at an end-system that doesn't handle the signalling application. This is possible in normal operation, and it MUST be indicated to the sender with an "Endpoint Found" informational message (Appendix A.4.4.7). The end-system includes the MRI and SID from the original message in the error message, without interpreting them 🎯.
- The node is a GIST-aware NAT. See Section 7.2 🌐.
In cases (2) and (3), GIST's job is to forward the message essentially as though it were a normal IP datagram, and the node won't become a peer to the node that sent the message 🚚. Forwarding with modified NSLP payloads is covered above in Section 4.3.2. However, a GIST implementation MUST ensure that the IP-layer TTL field and GIST hop count are managed correctly to prevent message looping. This should be done consistently, no matter where in the packet processing path the decision is made 🔁. The rules are that in cases (2) and (3), the IP-layer TTL MUST be decremented just as if the message was a normal IP forwarded packet. In case (3), the GIST hop count MUST be decremented as in normal input processing, which also applies to cases (4) and (5) 🧮.
A GIST node processing Q-mode encapsulated messages this way SHOULD make the routing decision based on the full contents of the MRI, and not only the IP destination address 🗺️. It MAY also apply a restricted set of sanity checks and, under certain conditions, return an error message rather than forward the message. These conditions are:
- The message is so large that it would be fragmented on downstream links, for example because the downstream MTU is abnormally small (less than 576 bytes). The error "Message Too Large" (Appendix A.4.4.8) SHOULD be returned to the sender, which SHOULD begin messaging association setup 📦.
- The GIST hop count has reached zero. The error "Hop Limit Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender, which MAY retry with a larger initial hop count ⏳.
- The MRI represents a flow definition that is too general to be forwarded along a unique path (for example, the destination address prefix is too short). The error "MRI Validation Failure" (Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be returned to the sender, which MAY retry with restricted MRIs, possibly starting additional signalling sessions to do so 🌪️. If the GIST node doesn't understand the MRM in question, it MUST NOT apply this check, and instead forwards the message transparently 🫠.
In the first two cases, only the common header of the GIST message gets examined. In the third case, the MRI is examined too. The rest of the message MUST NOT be inspected in any case 🙅♀️. As in Section 4.3.2, the GIST payloads MUST NOT be modified or re-ordered. An implementation MAY choose to achieve this by keeping the original message, rather than rebuilding it from some parsed internal representation 🧠.
4.4. Routing State and Messaging Association Maintenance 🎀
The main job of GIST is managing the routing state and messaging associations that the message processing described above relies on 👑. Routing state gets installed and refreshed by GIST handshake messages 🤝. Messaging associations are set up by the normal procedures of the transport and security protocols that make them up, using peer IP addresses from the routing state. Once a messaging association has been created, its refresh and expiration can be managed independently from the routing state ⏰.
There are two different cases for state installation and refresh:
- Where routing state is being discovered or a new association is to be established; and
- Where a suitable association already exists, including the case where routing state for the flow is being refreshed.
We'll go through these cases in turn, followed by the case of background general management procedures 💜.
4.4.1. Routing State and Messaging Association Creation ✨
okay so this is how GIST sets up state between two peers 🎀 Figure 5 shows the whole handshake, with the optional bits in square brackets, and there's an example in Appendix D if you want to see it in action 🦋
+----------+ +----------+
| Querying | |Responding|
| Node(Q-N)| | Node(R-N)|
+----------+ +----------+
Query .............
----------------------> . .
Router Alert Option . Routing .
MRI/SID/NSLPID . state .
Q-N Network Layer Info . installed .
Query-Cookie . at .
[Q-N Stack-Proposal . Responding.
Q-N Stack-Config-Data] . node .
[NSLP Payload] . (case 1) .
.............
......................................
. The responder can use an existing .
. messaging association if available .
. from here onwards to short-circuit .
. messaging association setup .
......................................
Response
............. <----------------------
. Routing . MRI/SID/NSLPID
. state . R-N Network Layer Info
. installed . Query-Cookie
. at . [Responder-Cookie
. Querying . [R-N Stack-Proposal
. node . R-N Stack-Config-Data]]
............. [NSLP Payload]
....................................
. If a messaging association needs .
. to be created, it is set up here .
. and the Confirm uses it .
....................................
Confirm .............
----------------------> . Routing .
MRI/SID/NSLPID . state .
Q-N Network Layer Info . installed .
[Responder-Cookie . at .
[R-N Stack-Proposal . Responding.
[Q-N Stack-Config-Data]]] . node .
[NSLP Payload] . (case 2) .
.............
Figure 5: Message Sequence at State SetupFirst up, the Query! 💌 Every routing state maintenance operation starts with a Query, sent by the Querying node and intercepted at the responding node 👀. It carries the addressing and identifiers for the flow and the signalling application the state is being maintained for, plus info about the Query sender's own address. It MAY contain an NSLP payload 🧁. It also has a Query-Cookie and, optionally, capability info about messaging association protocol stacks 💜. The cookies in this and later messages are there to guard against certain denial-of-service attacks and to link up the events in the sequence (Section 8.5 has the deets) 🔐.
Once the signalling application has said message routing state should be set up (Section 4.3.2), getting a Query MUST get you a Response 💅. It's a normally encapsulated D-mode message with extra GIST payloads. It tells you the network layer info about the Responding node, echoes the Query-Cookie, and MAY contain an NSLP payload, possibly a reply to the one in the initial message 🌸. If a messaging association was requested, the Response MUST also contain a Responder-Cookie and its own capability info about messaging association protocol stacks 🦋. Even when no association was requested, the Response MAY still include a Responder-Cookie if the node's routing state setup policy requires it (see below) ✨.
Now the messaging association part! 🌈 Setup of a new messaging association begins once peer addressing info is available and a new association is actually needed. Any setup MUST take place immediately after that specific Query/Response exchange 😭. Why so urgent? The addressing info might expire, either because it depends on NAT bindings with a limited lifetime or because it refers to agile destination ports for the transport protocols 💀. The Stack-Proposal and Stack-Configuration-Data objects in the exchange carry the capability info about which messaging association protocols can be used, and Section 5.7 goes deeper on how they get processed 🧚. With the protocol options defined right now, setup always starts from the Querying node, though more flexible configs are possible within the overall GIST design 🍓.
If the messaging association includes a channel security protocol, each GIST node MUST verify the authenticated identity of the peer against its authorised peer database, and if there's no match, the messaging association MUST be torn down 🚨. The database and authorisation check are covered in Section 4.4.2 below. Heads up: the verification can depend on what the MA is for (e.g., for which MRI or session), so this step might not be possible right after authentication finishes and could happen some time later ⏰.
Finally, once any necessary messaging association setup is done, a Confirm MUST be sent if the Response asked for it 🎉. After the Confirm goes out, the Querying node assumes routing state is installed at the responder and can start sending normal Data messages for that flow 🚀. Recovering from a lost Confirm is discussed in Section 5.3.3. If a messaging association is being used, the Confirm MUST be sent over it before any other messages for the same flow 🫶. It echoes the Responder-Cookie and Stack-Proposal from the Response. The cookie lets the receiver validate the message contents (see Section 8.5), and the proposal helps prevent certain bidding-down attacks on messaging association security (see Section 8.6) 🔐. This first Confirm on a new association MUST also contain a Stack-Configuration-Data object carrying an MA-Hold-Time value, which supersedes the value given in the original Query 🕰️. The association can be used in the upstream direction for the MRI and NSLPID carried in the Confirm, once the Confirm has been received 💖.
Installing state, the fun part! 🍭 The Querying node MUST install the responder address, derived from the R-Node Network Layer info, as routing state information after verifying the Query-Cookie in the Response 👑. The Responding node MAY install the querying address as peer state information at two points in time:
- Case 1: after the receipt of the initial Query, or
- Case 2: after a Confirm containing the
Responder-Cookie.
The Responding node SHOULD derive the peer address from the Q-Node Network Layer Info if that was decoded successfully 🧭. Otherwise, it MAY be derived from the IP source address of the message if the common header flags this as being the signalling source address 🌷. When state gets installed is a matter of security policy, mostly about preventing denial-of-service and state poisoning attacks, and Section 8 has the full story 🛡️. Since the Responding node MAY choose to delay state installation as in case (2), the Confirm must contain enough information to be processed in the same way as the original Query 🎀. That creates some special requirements for NAT traversal and cookie functionality, which are discussed in Section 7.2 and Section 8 respectively 💅✨.
4.4.2. GIST Peer Authorisation ✨
okay so when two GIST nodes authenticate using a messaging association 🫶, both ends have to decide two things: whether to accept the MA being created at all, and whether they actually trust the info sent over it. this is basically an authorisation decision 💅
- Authorised peers are trusted to install correct routing state about themselves, and not (for example) to claim they're on-path for a flow when they're not 🙈
- Authorised peers are trusted to obey transport- and application-level flow control rules, and not to attempt to create overload situations 💀
- Authorised peers are trusted not to send erroneous or malicious error messages, for example, asserting that routing state has been lost when it hasn't 😭
the spec models this decision as the authorising node checking the peer's identity against a local list of peers, called the authorised peer database (APD) 📒. the APD is an abstract construct, kinda like the security policy database of IPsec [36] 🔐. implementations MAY provide the associated functionality in any way they choose 🌈. this section only defines the requirements for APD administration and what happens when a peer's identity validates against it 🎀.
the APD is a list of entries. each entry has an identity, the namespace that identity comes from (e.g., DNS domains), the scope the entry applies to, and whether authorisation is allowed or denied. here are the example scopes:
- Peer Address Ownership: the scope is the IP address where the peer for this MRI should be, and the APD entry says the identity is the owner of that address 🏠. if the authorising node can work out this address from local info (like its own routing tables), matching this entry shows the peer is the correct on-path node, so it should be authorised ✅. this is simple if the peer is one IP hop downstream, since the IP address can be derived from the router's forwarding tables. if the peer is more than one hop away or is upstream, it gets harder but might still be possible in some circumstances 🤔. the authorising node may be able to figure out a (small) set of possible peer addresses, and accept that any of these could be the correct peer.
- End-System Subnet: the scope is an address range where the MRI source or destination lives, and the APD entry says the identity could potentially be on-path between the authorising node and that address range 🛣️. there can be different source and destination scopes, to account for asymmetric routing 🔄.
the same identity can show up in multiple entries, and the order of entries in the APD matters a lot 📋. when a messaging association is authenticated and associated with an MRI, the authorising node scans the APD for the first entry where the identity matches what the peer presented, and where the scope info matches the circumstances the MA is being set up for 👀. the identity matching process itself depends on the messaging association protocol doing the authentication, and the details for TLS are in Section 5.7.3 🔍. whenever the full set of possible peers for a specific scope is known, deny entries SHOULD be added for the wildcard identity to reject signalling associations from unknown nodes 🚫. how well the authorising node can reject inappropriate MAs depends directly on how granular the APD is and how precise the scope matching is 🎯.
if authorisation is allowed, the MA can be used as normal 🥰. otherwise, it MUST be torn down without further GIST exchanges, and any routing state associated with the MA MUST also be deleted 💥. an error condition MAY be logged locally 📝. when an APD entry is modified or deleted, the node MUST re-validate existing MAs and the routing state table against the revised contents of the APD 🔁. this might result in MAs being torn down or routing state entries being deleted 😬. these changes SHOULD be indicated to local signalling applications via the NetworkNotification API call (Appendix B.4) 📣.
this spec doesn't define how the APD gets populated 🤷♀️. as a minimum, an implementation MUST provide an administrative interface through which entries can be added, modified, or deleted 🛠️. fancier mechanisms are possible in some scenarios. for example, the fact that a node is legitimately associated with a specific IP address could be established by directly embedding that IP address as a particular identity type in a certificate, or by mapping that address to another identifier type through an extra database lookup (like relating IP addresses in in-addr.arpa to domain names) 🪪. an enterprise network operator could generate a list of all the identities of its border nodes as authorised to be on the signalling path to external destinations, and distribute it to all hosts inside the network 🏢. whatever the technique, it MUST be ensured that the source data justify the authorisation decisions listed at the start of this section, and that the security of the chain of operations on which the APD entry depends cannot be compromised 🔒✨.
4.4.3. Messaging Association Multiplexing
it's a design goal of GIST that, as far as possible, a single messaging association should be used for multiple flows and sessions between two peers, instead of setting up a new MA for each one 🧚. this re-use of existing MAs is called messaging association multiplexing 🔀. multiplexing means the MA cost only scales with the number of peers, and it avoids the latency of new MA setup where possible ⚡.
the catch is that multiplexing needs you to find an existing MA that matches the same routing state and desired properties a normal handshake in D-mode would produce, and that identification has to be just as reliable and secure as doing a normal D-mode handshake 🧐. this gets complicated because NATs may remap node addresses in D-mode messages, and because some nodes may peer over multiple interfaces (so with different addresses) 🌐.
MA multiplexing is controlled by the Network Layer Information (NLI) object, which is carried in Query, Response, and Confirm messages 📦. the NLI object includes (among other elements) these:
- Peer-Identity: for a given node, this is an interface-independent value with opaque syntax. it MUST be chosen so as to have a high probability of uniqueness across the set of all potential peers, and SHOULD be stable at least until the next node restart 🆔. there's no cryptographic protection of this identity, and trying to provide it would basically duplicate what the messaging association security protocols already do 🙅♀️. for routers, the Router-ID [2], which is one of the router's IP addresses, MAY be used as one possible value for the Peer-Identity 🛜. in scenarios with nested NATs, the Router-ID alone may not satisfy the uniqueness requirements, in which case it MAY be extended with additional tokens, either chosen randomly or administratively coordinated 🎲.
- Interface-Address: this is an IP address through which the signalling node can be reached. there may be several choices available for the Interface-Address, and more discussion on this is in Section 5.2.2 📍.
a messaging association is associated with the NLI object the peer provided in the Query/Response/Confirm when the association was first set up 💌. there can be more than one MA for a given NLI object, for example, with different security or transport properties 🔐.
MA multiplexing happens by matching these two elements from the NLI in a new GIST message against one associated with an existing MA. the message can be either a Query or a Response, although the former is more likely 👑:
- Perfect match: if there's a perfect match to an existing association, that association SHOULD be re-used, provided it meets the criteria on security and transport properties given at the end of Section 5.7.1 🎀. the rest of the handshake messages then get sent over that association. this will lead to multiplexing on an association to the wrong node if signalling nodes have colliding Peer-Identities and one is reachable at the same Interface-Address as another 😱. this could be caused by an on-path attacker, and on-path attacks are discussed further in Section 8.7 👻. when multiplexing is done and the original MA authorisation was MRI-dependent, the verification steps of Section 4.4.2 MUST be repeated for the new flow 🔁.
- All other cases: the handshake MUST be executed in D-mode as usual. there are actually four possibilities:
- Nothing matches: this is clearly a new peer 🌟.
- Only the Peer-Identity matches: this may be either a new interface on an existing peer or a changed address mapping behind a NAT. these should be rare events, so the expense of a new association setup is acceptable 💸. another possibility is one node using another node's Peer-Identity, for example, as some kind of attack 🥷. because the Peer-Identity is only used for this multiplexing process, the only consequence is that it requires a new association setup, and this is considered in Section 8.4 🧩.
- Only the Interface-Address matches: this is probably a new peer behind the same NAT as an existing one, so a new association setup is required 🏘️.
- Both elements of the NLI object match: this is a degenerate case, where one node recognises an existing peer but wants to keep the option of setting up a new association anyway, for example, to create an association with different properties 🪞.
4.4.4. Routing State Maintenance 💖
Okay so every bit of routing state has a lifetime ⏳, and it's negotiated during the Query/Response/Confirm handshake. The NLI object in the Query proposes a lifetime value, and the NLI in the Response carries the value the Responding node requires. A default timer of 30 seconds is RECOMMENDED 🎀. Nodes that can use fancier, more powerful route change detection, like the methods in Section 7.1.2, MAY go with much longer times 🦋. Nodes MAY also go shorter if they want faster change detection ✨.
Here's the catch 🙈: if the number of active routing state items adds up to a Query rate that stresses the rate limits on D-mode traffic (Section 5.3.3), nodes MUST increase the timer for new items and on the refresh of existing ones. A suitable value is:
2 * (number of routing states) / (rate limit in packets/second)That leaves a factor of two headroom for new routing state creation and Query retransmissions 💅.
The Querying node MUST ensure that a Query is received before this timer expires, if it believes the signalling session is still active. Otherwise, the Responding node MAY delete the state 🧚. Receipt of the message at the Responding node refreshes peer addressing state for one direction, and receipt of a Response at the Querying node refreshes it for the other 🫶. There's no mechanism at the GIST level for explicit teardown of routing state 😭. However, GIST MUST NOT refresh routing state if a signalling session is known to be inactive. That happens either because upstream state has expired, or because the signalling application has indicated via the GIST API (Appendix B.5) that the state is no longer required. Refreshing in those cases would prevent correct state repair when the IP layer reroutes traffic 🌸.
This spec only pins down the exact time routing state expires. It doesn't say when refresh handshakes get kicked off. Implementations MUST select timer settings that take at least the following into account:
- the transmission latency between source and destination;
- the need for retransmissions of Query messages;
- the need to avoid network synchronisation of control traffic (cf. [42]).
In most cases, a reasonable policy is to start the routing state refresh when between 1/2 and 3/4 of the validity time has elapsed since the last successful refresh. The actual moment MUST be chosen randomly within this interval to avoid synchronisation effects 🌈.
4.4.5. Messaging Association Maintenance 🦋
Unneeded MAs get torn down by GIST. It uses the teardown mechanisms of the underlying transport or security protocols if they're available, for example by simply closing a TCP connection. Either end can start the teardown ✨. Whether an MA is needed comes down to two factors:
- local policy, which could take into account the cost of keeping the messaging association open, the level of past activity on the association, and the likelihood of future activity, e.g., if there is routing state still in place that might generate messages to use it.
- whether the peer still wants the MA to remain in place. During MA setup, as part of the Stack-Configuration-Data, each node advertises its own MA-Hold-Time, i.e., the time for which it will retain an MA that is not carrying signalling traffic. A node MUST NOT tear down an MA if it has received traffic from its peer over that period. A peer that has generated no traffic but still wants the MA retained can send a special null message (
MA-Hello) to say so. A default value for MA-Hold-Time of 30 seconds is RECOMMENDED. Nodes MAY use shorter times to get more rapid peer failure detection, but they need to account for the load on the network created by theMA-Hellomessages. Nodes MAY use longer times, but they need to weigh the cost of retaining idle MAs for extended periods. Nodes MAY also factor in signalling application behaviour (e.g., NSLP refresh times) when picking an appropriate value 💜.
Because the Responding node can choose not to create state until a Confirm, an abbreviated Stack-Configuration-Data object containing just this information from the initial Query MUST be repeated by the Querying node in the first Confirm sent on a new MA. If the object is missing in the Confirm, an "Object Type Error" message (Appendix A.4.4.9) with subcode 2 ("Missing Object") MUST be returned 🚨.
Messaging associations can always be set up on demand, and their status isn't made directly visible outside the GIST layer. So even if GIST tears down an MA and later re-establishes it, signalling applications can't tell that apart from an MA that stayed open the whole time 🙃. To keep the transport semantics from Section 4.1, GIST MUST close transport connections carrying reliable messages gracefully or report an error condition. It also MUST NOT open a new association for a given session and peer while messages on a previous association could still be outstanding 🔥. GIST MAY use an MA-Hello request/reply exchange on an existing association to check that messages sent on it reached the peer. GIST MAY use the same technique to test the liveness of the underlying MA protocols themselves at arbitrary times 💅.
This spec only pins down the exact time messaging associations expire. It doesn't say when keepalives get kicked off. Implementations MUST select timer settings that take at least the following into account:
- the transmission latency between source and destination;
- the need for retransmissions within the messaging association protocols;
- the need to avoid network synchronisation of control traffic (cf. [42]).
In most cases, a reasonable policy is to start the MA refresh when between 1/2 and 3/4 of the validity time has elapsed since the last successful refresh. The actual moment MUST be chosen randomly within this interval to avoid synchronisation effects 🫧.
4.4.6. Routing State Failures 😱
Sometimes a GIST node gets a message from a GIST peer that only makes sense with some routing state, but there's no matching routing state at all 👀. Cases where this can happen include:
- Where the message is random traffic from an attacker, or backscatter (replies to such traffic).
- Where routing state was correctly installed but the peer has since lost it, for example, because of aggressive timeout settings at the peer or because the node has crashed and restarted.
- Where the routing state was not correctly installed in the first place, but the sending node doesn't know that. This can happen if the Confirm message of the handshake is lost.
It's important for GIST to recover from these situations promptly when they're genuine errors (node restarts, or lost messages that would otherwise never be retransmitted) 🫶. Note that only Response, Confirm, Data, and Error messages ever require routing state to exist. Here's how each one goes 🧁:
- Response: A Response can arrive at a node that never sent (or has forgotten) the corresponding Query. If the node wants routing state to exist, it will initiate it itself. A diagnostic error wouldn't let the sender of the Response take any corrective action, and the diagnostic could itself be a form of backscatter. Therefore, an error message MUST NOT be generated, but the condition MAY be logged locally.
- Confirm: For a Responding node that implements delayed state installation, this is normal behaviour, and routing state will be created provided the Confirm is validated. Otherwise, this is a case of a non-existent or forgotten Response, and the node may not have enough information in the Confirm to create the correct state. The requirement is to notify the Querying node so it can recover the routing state 💌.
- Data: This happens when a node receives Data where routing state is required, but either it doesn't exist at all or it hasn't been finalised (no Confirm message). To keep Data from being black-holed, a notification has to go to the peer 📨.
- Error: Some error messages can only be interpreted in the context of routing state. However, the only error messages that require a reply within the protocol are the routing state error messages themselves. So this case gets handled exactly like a Response: an error message MUST NOT be generated, but the condition MAY be logged locally 🙅♀️.
For Confirm or Data messages, if the state is required but doesn't exist, the node MUST reject the incoming message with a "No Routing State" error message (Appendix A.4.4.5). Then there are three cases at the receiver of that error message 🎀:
- No routing state: The condition MAY be logged, but a reply MUST NOT be sent (see above).
- Querying node: The node MUST restart the GIST handshake from the beginning, with a new Query.
- Responding node: The node MUST delete its own routing state and SHOULD report an error condition to the local signalling application.
The rules at the Querying or Responding node make GIST open to disruption by randomly injected error messages 😰. It's similar to blind reset attacks on TCP (cf. [46]). Because routing state matching includes the SID, though, this is mainly limited to on-path attackers. If a GIST node detects a significant rate of such attacks, it MAY adopt a policy of using secured messaging associations to communicate for the affected MRIs, and only accepting "No Routing State" error messages over such associations 🛡️.
5. Message Formats and Transport ✨
5.1. GIST Messages
okay so every GIST message starts with the same common header, and then it's followed by a bunch of TLV objects (type-length-value, aka little labelled boxes 📦). this bit gives you the high-level tour in ABNF [11] ✨. the nitty gritty header and object details live in Section 5.2 and the bit layouts are in Appendix A 🎀. also ngl, NAT traversal for GIST sneaks in an extra NAT-Traversal-Object into Query, Response, and some Data and Error messages 🦋. the rules for that are in Section 7.2, so go peek if you're curious 👀
GIST-Message: the main messages are either part of the three-way handshake or a simple message carrying NSLP data 💅. there are extra types for errors and for keeping messaging associations alive 🌸
GIST-Message = Query / Response / Confirm /
Data / Error / MA-Hellothe common header has a version number, the message type and size, and the NSLPID 🧚. it also carries a hop count so messages can't loop forever 🔁, plus a bunch of control flags. one of those is the R-flag, which says whether some kind of reply is wanted 💜. the objects after the common header MUST be carried in a fixed order, and that order depends on the message type 👑. if a message has missing, duplicate, or invalid objects for its type, it MUST be rejected with an "Object Type Error" message and the right subcode (Appendix A.4.4.9) 😭. unknown objects are the exception here, because they tell you explicitly how they should be treated, so they're not covered by that rule 🙈
Query: a Query MUST be sent in D-mode using the special Q-mode encapsulation 🍓. on top of the common header it has some mandatory control objects, and it MAY also carry a signalling application payload ✨. if the exchange is about setting up a messaging association, a stack proposal and configuration data MUST be included 🏗️. and this is true even when the Query is only meant for a refresh, since a routing change might have happened in the meantime 🤷♀️. the R-flag MUST always be set (R=1) in a Query, because a Query always gets a Response back 💖
Query = Common-Header
[ NAT-Traversal-Object ]
Message-Routing-Information
Session-Identifier
Network-Layer-Information
Query-Cookie
[ Stack-Proposal Stack-Configuration-Data ]
[ NSLP-Data ]Response: a Response MUST be sent in D-mode if no existing messaging association can be re-used 🔄. if one can be re-used, the Response MUST be sent in C-mode 💫. it MUST echo the MRI, SID, and Query-Cookie from the Query, and it carries its own Network-Layer-Information 🎀. if the exchange sets up a new messaging association, that MUST involve a D-mode Response, and a Responder-Cookie MUST be included, along with the Responder's own stack proposal and configuration data 🌈. the R-flag MUST be set (R=1) if a Responder-Cookie is present, but otherwise it is optional 🦋. if the R-flag is set, a Confirm MUST be sent back as a reply 💅. so basically a Confirm will always be required if a new MA is being set up 🫶. also, the direction of this MRI gets flipped compared to the Query's, so an upstream MRI becomes downstream and the other way round (see Section 3.3) 🔀
Response = Common-Header
[ NAT-Traversal-Object ]
Message-Routing-Information
Session-Identifier
Network-Layer-Information
Query-Cookie
[ Responder-Cookie
[ Stack-Proposal Stack-Configuration-Data ] ]
[ NSLP-Data ]Confirm: a Confirm MUST be sent in C-mode if a messaging association is being used for this routing state, and it MUST be sent before other messages for this routing state if an association is being set up 🌸. if no messaging association is being used, the Confirm MUST be sent in D-mode 🧚. the Confirm MUST include the MRI (with the direction inverted) and the SID, and it echoes the Responder-Cookie if the Response had one 💜. in C-mode, the Confirm MUST also echo the Stack-Proposal from the Response (if there was one) so the receiver can check that nobody messed with it 🕵️♀️. the first Confirm on a new association MUST also repeat the Stack-Configuration-Data from the original Query, but in an abbreviated form that just contains the MA-Hold-Time ⏰
Confirm = Common-Header
Message-Routing-Information
Session-Identifier
Network-Layer-Information
[ Responder-Cookie
[ Stack-Proposal
[ Stack-Configuration-Data ] ] ]
[ NSLP-Data ]Data: the Data message is for moving NSLP data around without changing GIST state 📬. it has no control objects, just the MRI and SID that go with the NSLP data being transferred ✨. Network-Layer-Information (NLI) MUST be carried in the D-mode case, but MUST NOT be included otherwise 🙅♀️
Data = Common-Header
[ NAT-Traversal-Object ]
Message-Routing-Information
Session-Identifier
[ Network-Layer-Information ]
NSLP-DataError: an Error message reports a problem that GIST itself spotted 🚨. (errors that come from signalling applications get reported inside NSLP-Data payloads, and GIST doesn't treat those specially 🙄.) if the message is sent in D-mode, the originator of the error message MUST include its own Network-Layer-Information object 📍. all the other error info goes in a GIST-Error-Data object 🗂️
Error = Common-Header
[ NAT-Traversal-Object ]
[ Network-Layer-Information ]
GIST-Error-DataMA-Hello: this message MUST be sent only in C-mode 🫧. it has the common header with a NSLPID of zero, plus a message identifier called the Hello-ID 🆔. it always says "I want to keep this messaging association open", and if it's sent with R=0 and a zero Hello-ID, that's its only job 💤. a node MAY also start a diagnostic request/reply exchange by setting R=1 and giving a non-zero Hello-ID 🔍. in that case the peer MUST send another MA-Hello back along the messaging association, echoing the same Hello-ID and with R=0 📨. whether to use this diagnostic is totally up to the node that starts it 💅
MA-Hello = Common-Header
Hello-ID5.2. Information Elements
this section is all about what's inside each object that can show up in each GIST message 🎀. that covers both the common header and each individual TLV 💖. the bit formats are in Appendix A ✨
5.2.1. The Common Header
every message starts with a fixed-format common header, and it holds the following info 📋
- Version: the version number of the GIST protocol. this specification defines GIST version 1 🔢
- GIST hop count: a hop count so a message can't loop forever 🔁
- Length: the number of 32-bit words in the message after the common header 📏
- Upper layer identifier (NSLPID): tells you which NSLP this message is for 🧚
- Context-free flag: this flag is set (C=1) if the receiver has to be able to process the message without supporting routing state. the C-flag MUST be set for Query messages, and also for Data messages sent in Q-mode 🛡️. the C-flag matters a lot for NAT traversal processing 🦋
- Message type: the message type (Query, Response, etc.) 💌
- Source addressing mode: if it's set (S=1), that means the IP source address of the message is the same as the IP address of the signalling peer, so replies can be sent safely to that address 📮. S is always set in C-mode. it gets cleared (S=0) if the IP source address was derived from the message routing information in the payload and that's different from the signalling source address 🕵️♀️
- Response requested: a flag that, if set (R=1), means a GIST message should be sent back in reply. the right reply type depends on what the original message was 💬
- Explicit routing: a flag that, if set (E=1), means the message was explicitly routed (see Section 7.1.5) 🗺️
Note that in D-mode, Section 5.3, there is a 32-bit magic number before the header 🪄. however, this is treated as part of the encapsulation rather than part of the message itself 🫶
...but yeah, the whole point is: every single one of these MUST/MAY bits is doing real work, so don't let them slip 😭💜
5.2.2. TLV Objects ✨
okay so everything after the common header is packed into a sequence of type-length-value objects (TLVs) 📦 Right now each object can show up at most once 🙅♀️, and which ones are required or allowed depends on the message type and the encapsulation (D-mode or C-mode) 💅
Message-Routing-Information (MRI): this is the info that says how the signalling message should get routed through the network 🗺️
Message-Routing-Information = message-routing-method
method-specific-informationThe format of the method-specific-information depends on which message-routing-method the signalling application asked for. Here's the bestie part 🫶 it always includes a flag that says whether the direction is upstream or downstream (see Section 3.3). The NSLP gives this in the message sender, and GIST uses it to pick the routing.
Session-Identifier (SID): a 128-bit, cryptographically random ID picked by the node that starts the signalling exchange 🔐 See Section 3.7.
Network-Layer-Information (NLI): this one carries the network-layer details of the sending node, including the data GIST needs to manage routing state 🧠 It has the sender's peer identity and IP address, plus IP-TTL so the IP hop count between GIST peers can be measured and reported, and an RS-validity-time for the routing state ⏳
Network-Layer-Information = peer-identity
interface-address
RS-validity-time
IP-TTLThe RS-validity-time gets its own explanation in Section 4.4.4 🙌 The peer-identity and interface-address are used for matching existing associations, as covered in Section 4.4.3.
The interface-address must be routable, aka it MUST be usable as a destination IP address for packets sent back to the node that made the signalling message, whether that's D-mode or C-mode 🛣️ If this object shows up in a message with the source addressing mode flag S=1, the interface-address MUST match the source address used in the IP encapsulation. This helps with legacy NAT detection (Section 7.2.1) 🕵️♀️ If it's carried in a Query or Confirm, the interface-address MUST specifically be set to an address bound to an interface associated with the MRI. That's what makes route change handling work (Section 7.1) 🔄 A suitable choice is the interface carrying the outbound flow.
Here's the tea ☕ a node can have a bunch of addresses to pick from. There might be a choice of IP versions, addresses with limited scope (like link-local), or addresses on different interfaces if you're a router or a multihomed host 🏠 But some of those might not be usable by the peer, so a node MUST follow a policy of using a global address of the same IP version as in the MRI, unless it can establish that an alternative would also be usable 🌍
The IP-TTL field is a whole mood 🎭 how it gets set and read depends on the message direction (upstream or downstream, as decided by the MRI) and the encapsulation.
- If the message is sent downstream, and the TTL that will be set in the IP header for the message can be figured out, the IP-TTL value MUST be set to that value. Otherwise it gets set to 0.
- On receiving a downstream message in D-mode, a non-zero IP-TTL gets compared to the TTL in the IP header. The difference is stored as the IP-hop-count-to-peer for the upstream peer, in the routing state table for that flow. Otherwise the field is ignored 🙈
- If the message is sent upstream, the IP-TTL MUST be set to the value of the IP-hop-count-to-peer stored in the routing state table, or 0 if there isn't a value stored yet.
- On receiving an upstream message, the IP-TTL is stored as the IP-hop-count-to-peer for the downstream peer.
In every case, the IP-TTL value reported to signalling applications is the one stored with the routing state for that flow, after it's been updated if needed from processing the message in question 💖
Stack-Proposal: this field lists which combos of transport and security protocols are available for messaging associations 🧩 It's also discussed further in Section 5.7.
Stack-Proposal = 1*stack-profile
stack-profile = protocol-count 1*protocol-layer
;; padded on the right with 0 to 32-bit boundary
protocol-count = %x01-FF
;; number of the following <protocol-layer>,
;; represented as one byte. This doesn't include
;; padding.
protocol-layer = %x01-FFEach protocol-layer field identifies a protocol with a unique tag 🏷️ Any extra data, like higher-layer addressing or other options for that protocol, gets carried in an MA-protocol-options field inside the Stack-Configuration-Data TLV (more on that below) 🎁
Stack-Configuration-Data (SCD): this object carries the overall configuration of a messaging association ⚙️
Stack-Configuration-Data = MA-Hold-Time
0*MA-protocol-optionsThe MA-Hold-Time field says how long a node will keep an inactive association open ⏰ See Section 4.4.5 for the deep dive. The MA-protocol-options fields give the configuration of the protocols (like TCP and TLS) used for new messaging associations, and they're described in more detail in Section 5.7 🔥
Query-Cookie/Responder-Cookie: a Query-Cookie lives in a Query and MUST be echoed in a Response 🍪 A Responder-Cookie MAY be sent in a Response, and if it's there, it MUST be echoed in the following Confirm. Cookies are variable-length bit strings picked by whoever generates them. For the full requirements and mechanisms for cookie generation, see Section 8.5 🫧
Hello-ID: this is a 32-bit quantity that correlates messages in an MA-Hello request/reply exchange 🤝 A non-zero value MUST be used in a request (messages sent with R=1), and the same value must be returned in the reply (which has R=0). The value zero MUST be used for all other messages. If a message comes in with R=1 and Hello-ID=0, an "Object Value Error" message (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") MUST be returned, and the message dropped 🚫 Nodes MAY use any algorithm to generate the Hello-ID. A solid approach is a local sequence number with a random starting point 🎲
NSLP-Data: this is the NSLP payload that gets delivered to the signalling application 📬 GIST doesn't interpret the payload content, so hands off 🙌
GIST-Error-Data: this object holds the info needed to report the cause and context of an error 🚨
GIST-Error-Data = error-class error-code error-subcode
common-error-header
[ Message-Routing-Information-content ]
[ Session-Identification-content ]
0*additional-information
[ comment ]The error-class shows the severity level, and the error-code and error-subcode pinpoint the exact error 🎯 A full list of GIST errors and their severity levels is in Appendix A.4. The common-error-header carries the Common-Header from the original message. The contents of the Message-Routing-Information (MRI) and Session-Identifier (SID) objects are included too, as long as they were successfully decoded. Some errors can come with extra information fields, which have a simple TLV format themselves 🧸 And finally, you can tack on an optional free-text comment 💬
5.3. D-mode Transport 🦋
This section walks through the different encapsulation options for D-mode messages 🌈 There are a few possibilities depending on the message type, the MRM, and local policy. The big design principle, though, is that the only job of the encapsulation is to make sure the message gets delivered to, or intercepted at, the right peer 🎯 Beyond that, the type of encapsulation and the values of the addresses or ports used for it barely matter 🤷♀️ That's on purpose, so new options can be built later to handle particular deployment needs without rewriting the whole protocol spec 🔮
5.3.1. Normal Encapsulation 🌸
Normal encapsulation MUST be used for all D-mode messages where the signalling peer is already known from previous signalling 💌 That covers Response and Confirm messages, and Data messages, unless those are being sent without using local routing state. Normal encapsulation is super simple: the message rides in a single UDP datagram 📦 UDP checksums MUST be enabled 🔒 The UDP payload MUST always begin with a 32-bit magic number, value 0x4e04 bda5 in network byte order. After that comes the GIST common header and the complete set of payloads. If the magic number isn't there, the message MUST be silently dropped 🫥 The normal encapsulation is shown in outline in Figure 6 👀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IP Header //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// UDP Header //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GIST Magic Number (0x4e04bda5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// GIST Common Header //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// GIST Payloads //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Normal Encapsulation Packet Format 📸
The message is IP addressed directly to the adjacent peer, as given by the routing state table 🎯 When the message is a direct reply to a Query and no routing state exists, the destination address is worked out from the input message using the same rules as in Section 4.4.1. The UDP port numbering MUST be compatible with what's used on Query messages (see below). That means the ports are the same for messages going the same direction, and the source and destination ports are swapped for messages going the opposite way 🔁 Messages with normal encapsulation MUST be sent with source addressing mode flag S=1, unless the message is a reply to a message that's known to have passed through a NAT 🛡️ And the receiver MUST check the IP source address against the interface-address given in the NLI, as part of legacy NAT detection. Both of these are discussed further in Section 7.2.1 ✨
5.3.2. Q-mode Encapsulation ✨
Okay bestie, Q-mode encapsulation MUST be used for messages where no routing state is available or where the routing state is being refreshed, especially Query messages 💅 Q-mode can also be used when local policy asks for it. It's giving "basically normal encapsulation," but with a few glow-ups: different IP address selection, new rules about IP options, and a defined way to pick UDP ports 🦋
It's lowkey essential that a GIST node can intercept these messages efficiently even when they aren't addressed to it 👀 And the flip side is just as important: a non-GIST node should be able to ignore them without clogging up the slow path packet processing 🧚 This document says interception is done based on RAOs 🎀
5.3.2.1. Encapsulation and Interception in IPv4
So the IP addresses are derived from info in the MRI, and the exact rules depend on the MRM 🌸 For messages with source addressing mode flag S=1, the receiver MUST check the IP source address against the interface-address given in the NLI as part of legacy NAT detection. See Section 7.2.1 for that one 🕵️
Current MRMs define using a Router Alert Option [13] to help the peer intercept the message, depending on the NSLPID. If the MRM defines RAO use, the sender MUST include it unless it's been specifically configured not to (see below). A node MAY make the initial interception decision purely based on IP-Protocol number transport header analysis. Implementations MAY provide an option to disable setting RAO on Q-mode packets on a per-destination prefix basis. However, that option MUST be disabled by default, and it MUST only be enabled when it's been separately verified that the next GIST node along the path to the destination can intercept packets without RAO. The whole point is to work across networks that don't properly support RAO, and more details are in Appendix C 📖
It's likely that fragmented datagrams won't be correctly intercepted in the network, since the checks that a datagram is a Q-mode packet depend on data beyond the IP header. So the sender MUST set the Don't Fragment (DF) bit in the IPv4 header 🙈 ICMP "packet too large" messages get sent to the source address of the original IP datagram. Since all MRM definitions recommend S=1 for at least some retransmissions, ICMP errors related to fragmentation will be seen at the Querying node 💀
The upper layer protocol, identified by the IP-Protocol field in the IP header, MUST be UDP. 💖
5.3.2.2. Encapsulation and Interception in IPv6
Same vibe as IPv4 here. The IP addresses come from the MRI, and the exact rules depend on the MRM. For messages with source addressing mode flag S=1, the receiver MUST check the IP source address with the interface-address given in the NLI as part of legacy NAT detection. See Section 7.2.1 🕵️
For all current MRMs, the IP header gets a Router Alert Option [8] to help the peer intercept the message, depending on the NSLPID. If the MRM defines RAO use, the sender MUST include it without exception 🫶 It is RECOMMENDED that a node bases its initial interception decision purely on the presence of a hop-by-hop option header containing the RAO, which sits at the start of the header chain 🌈
The upper layer protocol MUST be UDP, with no intervening encapsulation layers. After any hop-by-hop option header, the IP header MUST NOT include any extension headers other than routing or destination options [5]. And for the last extension header, the next-header field MUST be UDP ✨
5.3.2.3. Upper Layer Encapsulation and Overall Interception Requirements
For both IP versions, the rules above mean the upper layer protocol identified by the IP header MUST be UDP. Other packets MUST NOT be identified as GIST Q-mode packets. That includes IP-in-IP tunnelled packets, other tunnelled packets (tunnel mode AH/ESP), and packets that have gone through some extra transport layer processing (transport mode AH/ESP) 🚫 If IP output processing at the originating node or an intermediate router adds such encapsulations to a GIST Q-mode packet, that packet won't be identified as GIST until the encapsulation is terminated. And if the node wants to signal for data over the network region where the encapsulation applies, it MUST generate additional signalling with an MRI matching the encapsulated traffic. The outbound GIST Q-mode messages for it MUST bypass the encapsulation processing 🎀
So the final stage of interception, and the final part of encapsulation, happens at the UDP level 🦋 The source UDP port is picked by the message sender as the port it's prepared to receive UDP messages on in reply. The sender MUST use the destination UDP port allocated for GIST by IANA (see Section 9) 👑
Now here's the tea ☕ For some MRMs, GIST nodes anywhere along the path can generate GIST packets with source addresses that spoof the source address of the data flow. That means destinations can't tell these packets apart from genuine end-to-end data purely by looking at addresses. Instead, it has to be possible to distinguish such GIST packets by port analysis, and that mechanism must stay valid even if the destination is GIST-unaware 😭 GIST handles this by using a fixed destination UDP port from the "well known" space for Q-mode encapsulation. That port should never be allocated on a GIST-unaware host, so Q-mode encapsulated messages should always be rejected with an ICMP error. If other applications use this destination port, they'll see reduced performance from increased delay and packet drops, because GIST nodes intercept their traffic 🙃
A GIST node needs to be able to filter out all IP/UDP packets whose UDP destination port number equals the one registered for GIST Q-mode encapsulation. These packets SHOULD then be further verified as GIST packets by checking the magic number (see Section 5.3.1). Packets that meet both the port and magic number requirements are processed further as GIST Q-mode packets. Any filtered packets that fail this GIST magic number check SHOULD be forwarded towards the IP packet's destination as a normal IP datagram 💅
To protect against denial-of-service attacks, a GIST node SHOULD have a rate limiter that stops more packets (filtered as potential Q-mode packets) from being processed than the system can safely handle. Any excess packets SHOULD be discarded 🛡️
5.3.2.4. IP Option Processing
For both IPv4 and IPv6, Q-mode packets can carry IP options allowed by the rules above. IP options processing is intended to be carried out independently of GIST processing 🧚 For the options allowed by these rules, the option semantics don't depend on the payload. UDP payload modifications aren't prevented by the options and don't affect the option content. And the presence of the options doesn't affect the UDP payload 🌸
On packets originated by GIST, IP options MAY be added according to node-local policies on outgoing IP data. On packets forwarded by GIST without NSLP processing, IP options MUST be processed as for a normally forwarded IP packet. On packets locally delivered to the NSLP, the IP options MAY be passed to the NSLP, and equivalent options can be used on subsequently generated outgoing Q-mode packets. In this case, routing related options SHOULD be processed identically to how they'd be processed for a normally forwarded IP packet 🍓
5.3.3. Retransmission and Rate Control 🔁
okay bestie, D-mode runs on UDP 🦋, which means it has zero built-in reliability or congestion control 💀. Signalling apps that need reliability should use C-mode, which should also carry the bulk of the signalling traffic ✨. BUT the GIST control messages themselves still need some kind of messaging reliability, and we also need rate control to handle retransmissions and bursts of unreliable signalling or state setup requests from the signalling apps 🚦.
Query messages that don't get a Response MAY be retransmitted, and retransmissions MUST use a binary exponential backoff 📈. The first timer value is T1, and the backoff can grow it up to a maximum of T2 seconds. The default for T1 is 500 ms 🕐. T1 is basically an estimate of the round-trip time between the Querying and Responding nodes. Nodes MAY use smaller values of T1 if it's known that the Query should get answered within the local network 🏠. T1 MAY be chosen larger, and this is RECOMMENDED if you know ahead of time (like on high-latency access links) that the round-trip time is going to be longer 🐢. The default value of T2 is 64*T1. Queries can go unanswered because of message loss (in either direction) or because there's no reachable GIST peer, so implementations MAY trade off reliability (large T2) against promptness of error feedback to applications (small T2) ⚖️. If the NSLP has indicated a timeout on the validity of this payload (see Appendix B.1), T2 MUST be chosen so the process ends within that timeout ⏳. Retransmitted Queries MUST use different Query-Cookie values 🍪. If the Query carries NSLP data, it may be delivered to the signalling application multiple times, so heads up 👀. These rules apply equally to the message that first creates routing state and to the ones that refresh it. In all cases, Responses MUST be sent promptly to avoid spurious retransmissions 💨. Nodes generating any type of retransmission MUST be prepared to receive and match a reply to any of them, not just the one most recently sent 🎯. A node SHOULD stop its retransmission process when any reply comes in, but it MUST keep processing further replies as normal 💅.
This algorithm handles lost Queries and Responses just fine 🙌. A lost Confirm is trickier, though 😬. The Responding node MAY run a retransmission timer to resend the Response until a Confirm arrives, and that timer MUST use the same backoff mechanism and parameters as for Responses 🔁. Now, an amplification attack stimulated by a malicious Query is a real threat 🚨, so the cookie mechanism is required so the node receiving the Response can throw it away efficiently if it doesn't match a previously sent Query 🗑️. This approach only works if the Responding node is okay storing per-flow state after receiving a single (Query) message, and that includes the case where the node has queued NSLP data 📦. If the Responding node has delayed state installation, the error condition only shows up when a Data message arrives. That gets handled as a routing state error (see Section 4.4.6), which makes the Querying node restart the handshake 🔄.
The basic rate-control requirements for D-mode traffic are deliberately minimal 🤏. A single rate limiter applies to all traffic, for all interfaces and message types 🚧. It covers retransmissions as well as new messages, although an implementation MAY choose to prioritise one over the other 🎀. Rate control only applies to locally generated D-mode messages, not to messages being forwarded ➡️. When the rate limiter is in effect, D-mode messages MUST be queued until transmission is re-enabled, or they MAY be dropped with an error condition reported back to local signalling applications 🫠. Either way, the effect is that new transactions get started more slowly by the signalling applications, which takes some pressure off the network 🌸.
The rate-limiting mechanism is implementation-defined, but it is RECOMMENDED that a token bucket limiter as described in [33] be used 🪣. The token bucket MUST be sized so a node can't saturate the network with D-mode traffic, for example when re-probing the network for multiple flows after a route change 🛑. A suitable approach is to restrict the token bucket parameters so the mean output rate is a small fraction of the node's lowest-speed interface. It is RECOMMENDED that this fraction is no more than 5% 📉. Also, according to the rules of Section 4.3.3, D-mode SHOULD only be used for Queries and Responses rather than normal signalling traffic, unless capacity for normal signalling traffic can be engineered 💜.
5.4. C-mode Transport 🚛
It is a requirement of the NTLP defined in [29] that it can support bundling of small messages, fragmentation of large messages, and message boundary delineation 📋. TCP gives you bundling and fragmentation, but not message boundaries 🙃. Good news though: the length information in the GIST common header lets the message boundary be discovered during parsing ✅. The bundling of small messages can either happen inside the transport protocol or be done by GIST during message construction. Either way, there are two approaches to know about 👯:
- As messages arrive for transmission, they get gathered into a bundle until a size limit is reached or a timeout expires (cf. the Nagle algorithm of TCP). This gives maximal efficiency at the cost of some latency 🐌.
- Messages awaiting transmission get gathered together while the node is not allowed to send them, for example because it's congestion controlled 🧱.
The second type of bundling is always appropriate 💖. For GIST, the first type MUST NOT be used for trigger messages (i.e., messages that update GIST or signalling application state), but it may be appropriate for refresh messages (i.e., messages that just extend timers) ⏰. These distinctions are only known to the signalling applications, but they MAY be indicated (as an implementation issue) by setting the priority transfer attribute (Section 4.1.2) 🏷️.
All of these transport protocol options can be supported by the basic GIST message format we already covered 🧩. The GIST message, which is the common header plus TLVs, is carried directly in the transport protocol, possibly with transport layer security protection 🔐. More messages can be carried in a continuous stream 🌊. This specification only defines the use of TCP, but other possibilities could be added without any extra work on message formatting ✨.
5.5. Message Type/Encapsulation Relationships 💌
GIST has four primary message types (Query, Response, Confirm, and Data) and three possible encapsulation methods (normal D-mode, Q-mode, and C-mode) 🎁. The allowed combinations of message type and encapsulation for sending are in the table below. Sometimes there are several possible choices, depending on whether routing state or messaging associations already exist 🤔. The rules for GIST policy, including whether or not to create such state to handle a message, are described normatively in the other sections of this specification 📖. If a message that can only be sent in Q-mode or D-mode arrives in C-mode, or vice versa, this MUST be rejected with an Incorrect Encapsulation error message (Appendix A.4.4.3) 🚫. It's worth noting that the receiver's processing of the message isn't otherwise affected by the encapsulation method, except that decapsulation may provide extra information, like translated addresses or the IP hop count to use in later message processing 🔍.
+----------+--------------+---------------------------+-------------+
| Message | Normal | Query D-mode (Q-mode) | C-mode |
| | D-mode | | |
+----------+--------------+---------------------------+-------------+
| Query | Never | Always, with C-flag=1 | Never |
| | | | |
| Response | Unless a | Never | If a |
| | messaging | | messaging |
| | association | | association |
| | is being | | is being |
| | re-used | | re-used |
| | | | |
| Confirm | Only if no | Never | If a |
| | messaging | | messaging |
| | association | | association |
| | has been set | | has been |
| | up or is | | set up or |
| | being | | is being |
| | re-used | | re-used |
| | | | |
| Data | If routing | If the MRI can be used to | If a |
| | state exists | derive the Q-mode | messaging |
| | for the flow | encapsulation, and either | association |
| | but no | no routing state exists | exists |
| | messaging | or local policy requires | |
| | association | Q-mode; MUST have | |
| | | C-flag=1 | |
+----------+--------------+---------------------------+-------------+5.6. Error Message Processing 🚑
Error messages get some special rules for encapsulation and transmission 🧐.
GIST only generates Error messages in reaction to incoming messages 📨. Error messages MUST NOT be generated in reaction to incoming Error messages, no exceptions 🙅♀️. The routing and encapsulation of the Error message are derived from those of the message that caused the error. In particular, local routing state is not consulted 🙈. Routing state and messaging association state MUST NOT be created to handle the error, and Error messages MUST NOT be retransmitted explicitly by GIST. They are still subject to the same rate control as other messages, though 🚦.
- If the incoming message was received in D-mode, the error MUST be sent in D-mode using the normal encapsulation, using the addressing information from the NLI object in the incoming message. If the NLI could not be determined, the error MUST be sent to the IP source of the incoming message if the S-flag was set in it. The NLI object in the Error message reports information about the originator of the error 📍.
- If the incoming message was received over a messaging association, the error MUST be sent back over the same messaging association 🔙.
The NSLPID in the common header of the Error message has the value zero 0️⃣. If for any reason the message can't be sent (for example, because it's too large to send in D-mode, or because the MA over which the original message arrived has since been closed), an error SHOULD be logged locally 📝. The receiver of the Error message can infer the NSLPID for the message that caused the error from the Common Header that is embedded in the Error Object 🕵️♀️.
5.7. Messaging Association Setup 🤝
5.7.1. Overview ✨
okay bestie, the big thing about GIST is that it is SO flexible about which transport and security protocols it uses 💅 different transports have different performance vibes for different environments, and different security protocols fit different authentication setups 🫶 even with a default mandatory protocol set, we can't rule out needing new protocols later, and secure feature negotiation literally can't be bolted onto an existing protocol in a backwards-compatible way 💀 so some sort of capability discovery is required 🦋
capability discovery happens in Query and Response messages, using Stack-Proposal and Stack-Configuration-Data (SCD) objects ✨ if a new messaging association is needed, it gets set up, and then there's a Confirm 🎀 messaging association multiplexing is achieved by short-circuiting this exchange, meaning the Response or Confirm gets sent on an existing association (Section 4.4.3) 🌸 whether to do that is a matter of local policy, so it's your call bestie 🧚 the end result is a messaging association that is a stack of protocols 👑 if multiple associations exist, it's local policy how to spread messages across them, but you have to respect the transfer attributes requested for each message 💜
every possible protocol for a messaging association has these attributes:
- MA-Protocol-ID, a 1-byte IANA-assigned value (see Section 9) 🍓
- A specification of the (non-negotiable) policies about how the protocol should be used, for example, in which direction a connection should be opened 🔥
- (Depending on the specific protocol:) Formats for an MA-protocol-options field to carry the protocol addressing and other configuration information in the SCD object. The format may differ depending on whether the field is present in the Query or Response. Some protocols don't need any extra data defined like this, in which case no corresponding MA-protocol-options field shows up in the SCD object 🌈
a Stack-Proposal object is basically just a list of profiles, and each profile is a sequence of MA-Protocol-IDs 💖 a profile lists the protocols in 'top to bottom' order (e.g., TLS over TCP) ✨ a Stack-Proposal is generally accompanied by an SCD object that carries an MA-protocol-options field for any protocol in the Stack-Proposal that needs one 🎀 an MA-protocol-options field can apply globally, to all instances of the protocol in the Stack-Proposal, or it can be tagged as applying to one specific instance 🫶 that second option is useful for things like carrying different port numbers for TCP depending on whether it's used with or without TLS 🦋 there's a message flow showing several features of the Stack-Proposal and Stack-Configuration-Data formats in Appendix D 📖
an MA-protocol-options field can also be flagged as not usable 🙈 for example, a NAT that couldn't handle SCTP would set this in an MA-protocol-options field about SCTP 💀 a protocol flagged this way MUST NOT be used for a messaging association 🚫 and if the Stack-Proposal and SCD are both present but don't match up, like if they refer to different protocols or an MA-protocol-options field points at a non-existent profile, an "Object Value Error" message (Appendix A.4.4.10) with subcode 5 ("Stack-Proposal - Stack-Configuration-Data Mismatch") MUST be returned and the message dropped 😭
a node generating an SCD object MUST honour the implied protocol configurations for the period during which a messaging association might be set up 🫶 in particular, it MUST be immediately ready to accept incoming datagrams or connections at the protocol/port combinations it advertised ✨ this MAY mean creating listening endpoints for the transport and security protocols in question, or a node MAY keep a pool of those endpoints open for longer periods 🌸
BUT the received object contents MUST only be kept for the duration of the Query/Response exchange, plus enough time to let any necessary association setup finish 💅 they can go stale because of expired bindings at intermediate NATs, or because the advertising node is using agile ports 🧚 once setup is complete, or if it isn't necessary or fails for some reason, the object contents MUST be discarded 🗑️ a default time of 30 seconds to keep the contents is RECOMMENDED ⏱️
a Query asking for messaging association setup ALWAYS has a Stack-Proposal and SCD object 👑 the Stack-Proposal MUST only include protocol configurations that suit the transfer attributes of the messages the Querying node wants to send over that messaging association 💜 for example, it SHOULD NOT just include every configuration the Querying node is capable of supporting 🙅
the Response always contains a Stack-Proposal and SCD object, unless multiplexing happens (where the Responder decides to use an existing association) 🦋 for such a Response, the security protocols listed in the Stack-Proposal MUST NOT depend on the Query 🔒 a node MAY make different proposals depending on the combination of interface and NSLPID 🌈 if multiplexing does happen, which is indicated by sending the Response over an existing messaging association, these rules apply:
- The re-used messaging association MUST NOT have weaker security properties than all of the options that would have been offered in the full Response that would have been sent without re-use. 🔐
- The re-used messaging association MUST have equivalent or better transport and security characteristics as at least one of the protocol configurations that was offered in the Query. 🎀
once the messaging association is set up, the Querying node repeats the responder's Stack-Proposal over it in the Confirm 🫶 the Responding node MUST verify that this hasn't been changed, as part of bidding-down attack prevention, and it MUST also verify the Responder-Cookie (Section 8.5) ✨ if either check fails, the Responding node MUST NOT create the message routing state (or MUST delete it if it already exists) and SHOULD log an error condition locally 🚨 if this is the first message on a new MA, the MA MUST be torn down 💥 see Section 8.6 for more on that 🍓
5.7.2. Protocol Definition: Forwards-TCP 🌸
this MA-Protocol-ID is a basic use of TCP between peers 💖 support for this protocol is REQUIRED 🫶 if this protocol is offered, MA-protocol-options data MUST also be carried in the SCD object 📦 the MA-protocol-options field formats are:
- in a Query: no additional options data (the MA-protocol-options Length field is zero). 🙃
- in a Response: 2-byte port number at which the connection will be accepted, followed by 2 pad bytes. 🎀
the connection is opened in the forwards direction, from the Querying node towards the responder 🦋 the Querying node MAY use any source address and source port 🌈 the destination information MUST be derived from information in the Response: the address comes from the interface-address in the Network-Layer-Information object, and the port comes from the SCD object as described above 🧭
associations using Forwards-TCP can carry messages with the transfer attribute Reliable=True ✨ if an error occurs on the TCP connection, such as a reset (which can be detected, for example, by a socket exception condition), GIST MUST report this to NSLPs as discussed in Section 4.1.2 🚨
5.7.3. Protocol Definition: Transport Layer Security 🔐
this MA-Protocol-ID is a basic use of transport layer channel security, initially in conjunction with TCP 💜 support for this protocol in conjunction with TCP is REQUIRED 🫶 associations using it can carry messages with transfer attributes requesting confidentiality or integrity protection 🛡️ the specific TLS version gets negotiated within the TLS layer itself, but implementations MUST NOT negotiate to protocol versions prior to TLS1.0 [15] and MUST use the highest protocol version supported by both peers 👑 implementation of TLS1.2 [10] is RECOMMENDED ✨ GIST nodes supporting TLS1.0 or TLS1.1 MUST be able to negotiate the TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD be able to negotiate the TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA 🎀 they MAY negotiate any mutually acceptable ciphersuite that provides authentication, integrity, and confidentiality 🌈
the default mode of TLS authentication, which applies in particular to the above ciphersuites, uses a client/server X.509 certificate exchange 🦋 the Querying node acts as a TLS client, and the Responding node acts as a TLS server 🧚 where one of the above ciphersuites is negotiated, the GIST node acting as a server MUST provide a certificate, and MUST request one from the GIST node acting as a TLS client 📜 this allows either server-only or mutual authentication, depending on the certificates available to the client and the policy applied at the server 🫶
GIST nodes MAY negotiate other TLS ciphersuites 💅 sometimes negotiating an alternative ciphersuite is used to trigger alternative authentication procedures, like pre-shared keys [32] 🗝️ using other authentication procedures may need additional specification work to define how they fit into TLS within the GIST framework, and they may or may not need new MA-Protocol-IDs 🤓
no MA-protocol-options field is required for this TLS protocol definition 🙌 the configuration info for the transport protocol under TLS (e.g., TCP port number) is provided by the MA-protocol-options for that protocol 💖
5.7.3.1. Identity Checking in TLS 🔐
okay bestie, after TLS authentication, a node MUST check the identity the peer presents 🕵️♀️ so it can avoid man-in-the-middle attacks 😭, and verify that the peer is authorised to take part in signalling at the GIST layer 🛡️. The authorisation check works by comparing the presented identity with each Authorised Peer Database (APD) entry in turn, as discussed in Section 4.4.2. This section defines the identity comparison algorithm for a single APD entry 💅.
For TLS authentication with X.509 certificates, an identity from the DNS namespace MUST be checked against each subjectAltName extension of type dNSName present in the certificate. If no such extension is present, then the identity MUST be compared to the (most specific) Common Name in the Subject field of the certificate. When matching DNS names against dNSName or Common Name fields, matching is case-insensitive 🔤. Also, a * wildcard character MAY be used as the left-most name component in the certificate or identity in the APD. For example, *.example.com in the APD would match certificates for a.example.com, foo.example.com, *.example.com, etc., but would not match example.com. Similarly, a certificate for *.example.com would be valid for APD identities of a.example.com, foo.example.com, *.example.com, etc., but not example.com 🌸.
Additionally, a node MUST verify the binding between the identity of the peer to which it connects and the public key presented by that peer 🔑. Nodes SHOULD implement the algorithm in Section 6 of [8] for general certificate validation, but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings) 🧚.
For TLS authentication with pre-shared keys, the identity in the psk_identity_hint (for the server identity, i.e., the Responding node) or psk_identity (for the client identity, i.e., the Querying node) MUST be compared to the identities in the APD 🎀.
5.8. Specific Message Routing Methods 🛣️
Each message routing method (see Section 3.3) requires the definition of the format of the message routing information (MRI) and Q-mode encapsulation rules. These are given in the following subsections for the MRMs currently defined. A GIST implementation on a node MUST support whatever MRMs are required by the NSLPs on that node; GIST implementations SHOULD provide support for both the MRMs defined here, in order to minimise deployment barriers for new signalling applications that need them 🦋.
5.8.1. The Path-Coupled MRM
5.8.1.1. Message Routing Information
For the path-coupled MRM, the message routing information (MRI) is conceptually the Flow Identifier as in the NSIS framework [29]. Minimally, this could just be the flow destination address 📍; however, to account for policy-based forwarding and other issues a more complete set of header fields SHOULD be specified if possible (see Section 4.3.4 and Section 7.2 for further discussion) 🧠.
MRI = network-layer-version
source-address prefix-length
destination-address prefix-length
IP-protocol
diffserv-codepoint
[ flow-label ]
[ ipsec-SPI / L4-ports]Additional control information defines whether the flow-label, IPsec Security Parameters Index (SPI), and port information are present, and whether the IP-protocol and diffserv-codepoint fields should be interpreted as significant 🚦. The source and destination addresses MUST be real node addresses, but prefix lengths other than 32 or 128 (for IPv4 and IPv6, respectively) MAY be used to implement address wildcarding, allowing the MRI to refer to traffic to or from a wider address range 🌈. An additional flag defines the message direction relative to the MRI (upstream vs. downstream).
The MRI format allows a potentially very large number of different flag and field combinations 🙈. A GIST implementation that cannot interpret the MRI in a message MUST return an "Object Value Error" message (Appendix A.4.4.10) with subcodes 1 ("Value Not Supported") or 2 ("Invalid Flag-Field Combination") and drop the message 💀.
5.8.1.2. Downstream Q-mode Encapsulation
Where the signalling message is travelling in the same ('downstream') direction as the flow defined by the MRI, the IP addressing for Q-mode encapsulated messages is as follows. Support for this encapsulation is REQUIRED ✨.
- The destination IP address MUST be the flow destination address as given in the MRI of the message payload 🎯.
- By default, the source address is the flow source address, again from the MRI; therefore, the source addressing mode flag in the common header is
S=0. This gives the best likelihood that the message will be correctly routed through any region performing per-packet policy-based forwarding or load balancing that takes the source address into account 💖. However, there may be circumstances where the use of the signalling source address (S=1) is preferable, such as:- In order to receive ICMP error messages about the signalling message, such as unreachable port or address. If these are delivered to the flow source rather than the signalling source, it will be very difficult for the querying node to detect that it is the last GIST node on the path 👀. Another case is where there is an abnormally low MTU along the path, in which case the querying node needs to see the ICMP error (recall that Q-mode packets are sent with DF set).
- In order to receive GIST Error messages where the error message sender could not interpret the NLI in the original message 📨.
- In order to attempt to run GIST through an unmodified NAT, which will only process and translate IP addresses in the IP header (see Section 7.2.1) 🧦.
Because of these considerations, use of the signalling source address is allowed as an option, with use based on local policy 🍓. A node SHOULD use the flow source address for initial Query messages, but SHOULD transition to the signalling source address for some retransmissions or as a matter of static configuration, for example, if a NAT is known to be in the path out of a certain interface 🔁. The S-flag in the common header tells the message receiver which option was used 🏷️.
A Router Alert Option is also included in the IP header. The option value depends on the NSLP being signalled for 🚨. In addition, it is essential that the Query mimics the actual data flow as closely as possible, since this is the basis of how the signalling message is attached to the data path 🪞. To this end, GIST SHOULD set the Diffserv codepoint and (for IPv6) flow label to match the values in the MRI 💜.
A GIST implementation SHOULD apply validation checks to the MRI, to reject Query messages that are being injected by nodes with no legitimate interest in the flow being signalled for 🚫. In general, if the GIST node can detect that no flow could arrive over the same interface as the Query, it MUST be rejected with an appropriate error message. Such checks apply only to messages with the Q-mode encapsulation, since only those messages are required to track the flow path. The main checks are that the IP version used in the encapsulation should match that of the MRI and the version(s) used on that interface, and that the full range of source addresses (the source-address masked with its prefix-length) would pass ingress filtering checks 🧐. For these cases, the error message is "MRI Validation Failure" (Appendix A.4.4.12) with subcodes 1 or 2 ("IP Version Mismatch" or "Ingress Filter Failure"), respectively.
5.8.1.3. Upstream Q-mode Encapsulation
In some deployment scenarios, it is desirable to set up routing state in the upstream direction (i.e., from flow receiver towards the sender) 🔄. This could be used to support firewall signalling to control traffic from an uncooperative sender, or signalling in general where the flow sender was not NSIS-capable 🧱. This capability is incorporated into GIST by defining an encapsulation and processing rules for sending Query messages upstream 🚀.
In general, it is not possible to determine the hop-by-hop route upstream because of asymmetric IP routing 🌀. However, in particular cases, the upstream peer can be discovered with a high degree of confidence, for example:
- The upstream GIST peer is one IP hop away, and can be reached by tracing back through the interface on which the flow arrives 🪄.
- The upstream peer is a border router of a single-homed (stub) network 🏠.
This section defines an upstream Q-mode encapsulation and validation checks for when it can be used. The functionality to generate upstream Queries is OPTIONAL, but if received they MUST be processed in the normal way with some additional IP TTL checks. No special functionality is needed for this 🌷.
It is possible for routing state at a given node, for a specific MRI and NSLPID, to be created by both an upstream Query exchange (initiated by the node itself) and a downstream Query exchange (where the node is the responder). If the SIDs are different, these items of routing state MUST be considered as independent; if the SIDs match, the routing state installed by the downstream exchange MUST take precedence, provided that the downstream Query passed ingress filtering checks 👑. The rationale for this is that the downstream Query is in general a more reliable way to install state, since it directly probes the IP routing infrastructure along the flow path, whereas use of the upstream Query depends on the correctness of the Querying node's understanding of the topology 🗺️.
The details of the encapsulation are as follows:
- The destination address SHOULD be the flow source address as given in the MRI of the message payload. An implementation with more detailed knowledge of local IP routing MAY use an alternative destination address (e.g., the address of its default router) 🧭.
- The source address SHOULD be the signalling node address, so in the common header
S=1📣. - A Router Alert Option is included as in the downstream case 🚨.
- The Diffserv codepoint and (for IPv6) flow label MAY be set to match the values from the MRI as in the downstream case, and the UDP port selection is also the same 🎨.
- The IP layer TTL of the message MUST be set to 255 🔝.
The sending GIST implementation SHOULD attempt to send the Query via the same interface and to the same link layer neighbour from which the data packets of the flow are arriving 📬.
The receiving GIST node MAY apply validation checks to the message and MRI, to reject Query messages that have reached a node at which they can no longer be trusted 🕊️. In particular, a node SHOULD reject a message that has been propagated more than one IP hop, with an "Invalid IP layer TTL" error message (Appendix A.4.4.11) 🙅♀️. This can be determined by examining the received IP layer TTL, similar to the generalised IP TTL security mechanism described in [41].
Alternatively, receipt of an upstream Query at the flow source MAY be used to trigger setup of GIST state in the downstream direction 🌟. These restrictions may be relaxed in a future version 🍭.
5.8.2. The Loose-End MRM 🦋
okay so the Loose-End MRM is the one you use to find GIST nodes with particular properties somewhere in the direction of a given address 👀 like, sniffing out a NAT along the upstream data path (see [34]) 🧚
5.8.2.1. Message Routing Information 🎀
for the loose-end MRM you only need a simplified version of the Flow Identifier ✨
MRI = network-layer-version
source-address
destination-addressThe source address is the address of the node that starts the discovery, like the node that'll be the data receiver in the NAT discovery case 💖 The destination address is the address of a node that's expected to be the other side of the node being discovered 🌸 Extra control information sets the direction of the message relative to this flow, just like in the path-coupled case 💅
5.8.2.2. Downstream Q-mode Encapsulation 🍓
only one encapsulation is defined for the loose-end MRM, and by convention we call it the downstream encapsulation 🫶 it's defined like this:
- The IP destination address MUST be the destination address as given in the MRI of the message payload.
- By default, the IP source address is the source address from the MRI (S=0). However, the use of the signalling source address (S=1) is allowed, same as in the path-coupled MRM 🦋
A Router Alert Option is included in the IP header 🔥 The option value depends on the NSLP being signalled for. there are no special requirements on the setting of the Diffserv codepoint, IP layer TTL, or (for IPv6) the flow label. nor are any special validation checks applied. no drama, just vibes 💜
6. Formal Protocol Specification 👑
this section gives a more formal spec of how GIST processing works, in terms of rules for transitions between states of a set of communicating state machines inside a node 🧚 the description below only covers the basic protocol spec. additional mechanisms can be used by an implementation to speed up route change processing, and those are covered in Section 7.1 ✨ a more detailed description of GIST protocol operation in state machine syntax can be found in [45] 🌈
conceptually, GIST processing at a node can be seen in terms of four types of cooperating state machine 💖
- There is a top-level state machine that represents the node itself (Node-SM). It's responsible for processing events that can't be directed towards a more specific state machine, for example, inbound messages for which no routing state currently exists. This machine exists permanently, and it's responsible for creating per-MRI state machines to manage the GIST handshake and routing state maintenance procedures 👑
- For each flow and signalling direction where the node is responsible for creating routing state, there is an instance of a Query-Node state machine (Querying-SM). This machine sends Query and Confirm messages and waits for Responses, according to the requirements from local API commands or timer processing, such as message repetition or routing state refresh 🎀
- For each flow and signalling direction where the node has accepted the creation of routing state by a peer, there is an instance of a Responding-Node state machine (Responding-SM). This machine is responsible for managing the status of the routing state for that flow. Depending on policy, it MAY be responsible for transmission or retransmission of Response messages, or this MAY be handled by the Node-SM, and a Responding-SM is not even created for a flow until a properly formatted Confirm has been accepted 🫶
- Messaging associations have their own lifecycle, represented by an MA-SM, from when they are first created (in an incomplete state, listening for an inbound connection or waiting for outbound connections to complete), to when they are active and available for use 🧚
apart from the fact that the various machines can be created and destroyed by each other, there is almost no interaction between them 🙈 the machines for different flows don't interact, and the Querying-SM and Responding-SM for a single flow and signalling direction don't interact either. that means the Responding-SM that accepts the creation of routing state for a flow on one interface has no direct interaction with the Querying-SM that sets up routing state on the next interface along the path. this interaction is mediated instead through the NSLP 💅
the state machine descriptions use the terminology rx_MMMM, tg_TTTT, and er_EEEE for incoming messages, API/lower layer triggers, and error conditions, respectively 🌸 the possible events of these types are given in the table below 👀 timeout events denoted to_TTTT may also occur 💜 the various timers are listed independently for each type of state machine in the following subsections ✨
+---------------------+---------------------------------------------+
| Name | Meaning |
+---------------------+---------------------------------------------+
| rx_Query | A Query has been received. |
| | |
| rx_Response | A Response has been received. |
| | |
| rx_Confirm | A Confirm has been received. |
| | |
| rx_Data | A Data message has been received. |
| | |
| rx_Message | rx_Query||rx_Response||rx_Confirm||rx_Data. |
| | |
| rx_MA-Hello | An MA-Hello message has been received. |
| | |
| tg_NSLPData | A signalling application has requested data |
| | transfer (via API SendMessage). |
| | |
| tg_Connected | The protocol stack for a messaging |
| | association has completed connecting. |
| | |
| tg_RawData | GIST wishes to transfer data over a |
| | particular messaging association. |
| | |
| tg_MAIdle | GIST decides that it is no longer necessary |
| | to keep an MA open for itself. |
| | |
| er_NoRSM | A "No Routing State" error was received. |
| | |
| er_MAConnect | A messaging association protocol failed to |
| | complete a connection. |
| | |
| er_MAFailure | A messaging association failed. |
+---------------------+---------------------------------------------+
Incoming Events6.1. Node Processing 🌈
the Node-level state machine handles events for which no more appropriate messaging association state or routing state exists 💖 its structure is super simple: there's a single state ('Idle'), and all events cause a transition back to Idle ✨ some events cause the creation of other state machines. the only events this state machine processes are incoming GIST messages (Query/ Response/Confirm/Data) and API requests to send data, and no other events are possible 🙈 on top of that, the Node-level machine is in charge of managing listening endpoints for messaging associations. these relate to Responding node operation, but they can't be handled by the Responder state machine since they aren't created per flow 🫶 the processing rules for each event are as follows:
Rule 1 (rx_Query):
use the GIST service interface to determine the signalling
application policy relating to this peer
// note that this interaction delivers any NSLP-Data to
// the NSLP as a side effect
if (the signalling application indicates that routing state should
be created) then
if (routing state can be created without a 3-way handshake) then
create Responding-SM and transfer control to it
else
send Response with R=1
else
propagate the Query with any updated NSLP payload provided
Rule 2 (rx_Response):
// a routing state error
discard message
Rule 3 (rx_Confirm):
if (routing state can be created before receiving a Confirm) then
// we should already have Responding-SM for it,
// which would handle this message
discard message
send "No Routing State" error message
else
create Responding-SM and pass message to it
Rule 4 (rx_Data):
if (node policy will only process Data messages with matching
routing state) then
send "No Routing State" error message
else
pass directly to NSLP
Rule 4 (er_NoRSM):
discard the message
Rule 5 (tg_NSLPData):
if Q-mode encapsulation is not possible for this MRI
reject message with an error
else
if (local policy & transfer attributes say routing
state is not needed) then
send message statelessly
else
create Querying-SM and pass message to it6.2. Query Node Processing 🎀
okay bestie, the Querying-Node state machine (Querying-SM) has three states 💅:
- Awaiting Response
- Established
- Awaiting Refresh
The Querying-SM gets created by the Node-SM machine when there's a request to send a message for a flow in a signalling direction where the right state doesn't exist yet 🦋. The Query is generated immediately and the No_Response timer starts ⏱️. The NSLP data MAY be carried in the Query if local policy and the transfer attributes allow it ✨. Otherwise it MUST be queued locally until MA establishment 📦. Then the machine moves to Awaiting Response, where timeout-based retransmissions are handled 🔁. Data messages (rx_Data events) should not show up in this state. If they do, that can mean a Response got lost, and a node MAY retransmit a Query for this reason 👀.
Once a Response has been successfully received and routing state created, the machine moves to Established 👑, where NSLP data can be sent and received normally 💖. Further Responses received in this state (which can happen if a Confirm was lost) MUST be treated the same way 🫶. Awaiting Refresh is lowkey a substate of Established. A new Query has been generated to refresh the routing state (just like in Awaiting Response), but NSLP data can still be handled normally 🌸.
The timers for this state machine are:
- Refresh_QNode: Tells you when the routing state stored by this state machine must be refreshed 🔄. It gets reset whenever a Response comes back saying the routing state is still valid. Implementations MUST set the period of this timer based on the value in the
RS-validity-timefield of a Response, so a Query is generated before the peer's routing state expires (see Section 4.4.4) ⏰. - No_Response: Shows that a Response hasn't been received for a Query 🙈. It starts whenever a Query is sent and stops when a Response is received.
- Inactive_QNode: Shows that no NSLP traffic is being handled by this state machine right now 😴. It gets reset whenever the state machine handles NSLP data, in either direction. When it expires, the state machine MAY be deleted 🗑️. The period of the timer can be set at any time via the API (
SetStateLifetime), and if the period is reset that way, the timer itself MUST be restarted 🔥.
The main events (including all the ones that cause state transitions) are shown in the figure below, tagged with the number of the processing rule that handles them. The rules are listed right after the diagram 🧚. All events not shown or described in the text above are assumed to be impossible in a correct implementation and MUST be ignored 💀.
[Initialisation] +-----+
-------------------------|Birth|
| +-----+
| er_NoRSM[3](from all states) rx_Response[4]
| || tg_NSLPData[5]
| tg_NSLPData[1] || rx_Data[7]
| -------- -------
| | V | V
| | V | V
| +----------+ +-----------+
---->>| Awaiting | |Established|
------| Response |---------------------------->> | |
| +----------+ rx_Response[4] +-----------+
| ^ | ^ |
| ^ | ^ |
| -------- | |
| to_No_Response[2] | |
| [!nResp_reached] tg_NSLPData[5] | |
| || rx_Data[7] | |
| -------- | |
| | V | |
| to_No_Response[2] | V | |
| [nResp_reached] +-----------+ rx_Response[4] | |
---------- -----------| Awaiting |----------------- |
| | | Refresh |<<-------------------
| | +-----------+ to_Refresh_QNode[8]
| | ^ |
V V ^ | to_No_Response[2]
V V -------- [!nResp_reached]
+-----+
|Death|<<---------------
+-----+ to_Inactive_QNode[6]
(from all states)Figure 7: Query Node State Machine 📊
Here are the processing rules 📜:
Rule 1:
Store the message for later transmission
Rule 2:
if number of Queries sent has reached the threshold
// nQuery_isMax is true
indicate No Response error to NSLP
destroy self
else
send Query
start No_Response timer with new value
Rule 3:
// Assume the Confirm was lost in transit or the peer has reset;
// restart the handshake
send Query
(re)start No_Response timer
Rule 4:
if a new MA-SM is needed create one
if the R-flag was set send a Confirm
send any stored Data messages
stop No_Response timer
start Refresh_QNode timer
start Inactive_QNode timer if it was not running
if there was piggybacked NSLP-Data
pass it to the NSLP
restart Inactive_QNode timer
Rule 5:
send Data message
restart Inactive_QNode timer
Rule 6:
Terminate
Rule 7:
pass any data to the NSLP
restart Inactive_QNode timer
Rule 8:
send Query
start No_Response timer
stop Refresh_QNode timer6.3. Responder Node Processing ✨
okay so the Responding-SM (Responding state machine, bestie 💅) has three states:
- Awaiting Confirm
- Established
- Awaiting Refresh
the policy for handling Query messages and creating the Responding-SM has three cases, and honestly this part is so iconic 😭
- No Confirm is required for a Query, and the state machine can be created immediately.
- A Confirm is required for a Query, but the state machine can still be created immediately. A timer retransmits Response messages, and the Responding-SM gets destroyed if no valid Confirm shows up.
- A Confirm is required for a Query, and the state machine can only be created when that Confirm is received. The initial Query was already handled by the Node-level machine 🧚
in case 2, the Responding-SM starts in Awaiting Confirm and stays there until a Confirm arrives, and then it moves to Established. in cases 1 and 3, the Responding-SM is created straight into Established 🎀 also, if the machine gets created on receiving a Query, some of the message processing has already happened in the node state machine, so don't be shocked by that. an implementation MAY change its policy on handling a Query message at any time 🦋 but the state machine descriptions here only cover the situation where the policy stays fixed while it's waiting for a Confirm message.
in the Established state, the NSLP can send and receive data like normal, and any extra rx_Confirm events MUST be silently ignored 💜 Awaiting Refresh can be thought of as a substate of Established, where a Query came in to kick off the routing state refresh ✨ in Awaiting Refresh, the Responding-SM acts just like Awaiting Confirm, except the NSLP can still send and receive data. the main point is that in both states there's timer-based retransmission of Response messages until a Confirm lands, and extra rx_Query events in these states MUST also generate a reply and restart the no_Confirm timer 🔥
here are the timers that run this machine:
Expire_RNode: tells you when the routing state this state machine stores has to expire. it gets reset whenever a Query or Confirm (depending on local policy) comes in showing the routing state is still valid. heads up, state can't be refreshed from the R-Node 🙈 if this timer fires, the routing state machine gets deleted, no matter whether a No_Confirm timer is running.No_Confirm: tells you a Confirm hasn't been received in answer to a Response. it's started or reset whenever a Response is sent, and stopped when a Confirm is received.
the detailed state transitions and processing rules work the same way as in the Query node case, so here's the full picture 👑
rx_Query[1] rx_Query[5]
[confirmRequired] +-----+ [!confirmRequired]
-------------------------|Birth|----------------------------
| +-----+ |
| | rx_Confirm[2] |
| ---------------------------- |
| | |
| rx_Query[5] | |
| tg_NSLPData[7] || rx_Confirm[10] | |
| || rx_Query[1] || rx_Data[4] | |
| || rx_Data[6] || tg_NSLPData[3] | |
| -------- -------------- | |
| | V | V V V
| | V | V V V
| +----------+ | +-----------+
---->>| Awaiting | rx_Confirm[8] -----------|Established|
------| Confirm |------------------------------>> | |
| +----------+ +-----------+
| ^ | ^ |
| ^ | tg_NSLPData[3] ^ |
| -------- || rx_Query[1] | |
| to_No_Confirm[9] || rx_Data[4] | |
| [!nConf_reached] -------- | |
| | V | |
| to_No_Confirm[9] | V | |
| [nConf_reached] +-----------+ rx_Confirm[8] | |
---------- ------------| Awaiting |----------------- |
| | | Refresh |<<-------------------
| | +-----------+ rx_Query[1]
| | ^ | [confirmRequired]
| | ^ |
| | --------
V V to_No_Confirm[9]
V V [!nConf_reached]
+-----+
|Death|<<---------------------
+-----+ er_NoRSM[11]
to_Expire_RNode[11]
(from Established/Awaiting Refresh)
Figure 8: Responder Node State Machinenow the processing rules, the main event 🎀
Rule 1:
// a Confirm is required
send Response with R=1
(re)start No_Confirm timer with the initial timer value
Rule 2:
pass any NSLP-Data object to the NSLP
start Expire_RNode timer
Rule 3: send the Data message
Rule 4: pass data to NSLP
Rule 5:
// no Confirm is required
send Response with R=0
start Expire_RNode timer
Rule 6:
drop incoming data
send "No Routing State" error message
Rule 7: store Data message
Rule 8:
pass any NSLP-Data object to the NSLP
send any stored Data messages
stop No_Confirm timer
start Expire_RNode timer
Rule 9:
if number of Responses sent has reached threshold
// nResp_isMax is true
destroy self
else
send Response
start No_Response timer
Rule 10:
// can happen e.g., a retransmitted Response causes a duplicate Confirm
silently ignore
Rule 11: destroy selfthat's the whole vibe for part 21, bestie 💖 the Responding-SM is literally the main character of the routing refresh story and we are not even close to done 🌸
6.4. Messaging Association Processing 💌
okay so messaging associations (MAs) get modelled in GIST with a simple three-state process 💅 The first state is Awaiting Connection, which just means the MA is waiting for the connection process(es) for every protocol in the messaging association to finish ✨ That might mean creating listening endpoints or attempting active connects. Timers may also be needed to catch connection failure (like no incoming connection within a certain period), but those aren't modelled explicitly here 🙈
Connected means the MA is open, ready to use, and the node wants it to stay open 🫶 In this state the node runs a SendHello timer so messages keep going to the peer regularly, which stops the peer from tearing the MA down 🦋 The node moves from Connected to Idle (basically "I don't need this association anymore") as a matter of local policy. One way to handle that policy is an activity timer, but the state machine doesn't specify it explicitly. See also Section 4.4.5.
In Idle, the node doesn't need the MA anymore, but the peer still does and is letting everyone know with periodic MA-Hello messages 👑 A different timer, NoHello, purges the MA when those messages stop arriving. If real data gets transferred over the MA, the state machine goes back to Connected 🔥
At any time in Connected or Idle, a node MAY test the connectivity to its peer and the liveness of the GIST instance at that peer by sending an MA-Hello request with R=1 🔍 A failure to receive a reply with a matching Hello-ID within a timeout MAY be taken as a reason to trigger er_MAFailure. Starting such a test and picking the timeout setting are left to the implementation. Also, er_MAFailure may be signalled by indications from the underlying messaging association protocols. If a messaging association fails, this MUST be indicated back to the routing state machines that use it, and those MAY generate indications to signalling applications. If the messaging association was being used to deliver messages reliably, this MUST be reported as a NetworkNotification error (Appendix B.4). Yikes, serious stuff 😭
Clearly, a lot of the internal details of the messaging association protocols are hidden in this model, especially when the MA uses multiple protocol layers. Also, even though signalling applications can't directly see that MAs exist, the two do interact a bit: security-related information becomes available during the open process, and that may be passed up to signalling applications if they asked for it 🔐
The timers relevant to this state machine are:
SendHello: Indicates that an MA-Hello message should be sent to the remote node. The period of this timer is determined by the MA-Hold-Time sent by the remote node during the Query/Response/Confirm exchange.
NoHello: Indicates that no MA-Hello has been received from the remote node for a period of time. The period of this timer is sent to the remote node as the MA-Hold-Time during the Query/Response exchange.
The detailed state transitions and processing rules are described below, just like in the Query node case 🧚
[Initialisation] +-----+
----------------------------|Birth|
| +-----+ tg_RawData[1]
| || rx_Message[2]
| || rx_MA-Hello[3]
| tg_RawData[5] || to_SendHello[4]
| -------- --------
| | V | V
| | V | V
| +----------+ +-----------+
---->>| Awaiting | tg_Connected[6] | Connected |
------|Connection|----------------------->>| |
| +----------+ +-----------+
| ^ |
| tg_RawData[1] ^ |
| || rx_Message[2] | | tg_MAIdle[7]
| | V
| | V
| er_MAConnect[8] +-----+ to_NoHello[8] +-----------+
---------------->>|Death|<<----------------| Idle |
+-----+ +-----------+
^ ^ |
^ ^ |
--------------- --------
er_MAFailure[8] rx_MA-Hello[9]
(from Connected/Idle)
Figure 9: Messaging Association State MachineThe processing rules are as follows:
Rule 1:
pass message to transport layer
if the NoHello timer was running, stop it
(re)start SendHello
Rule 2:
pass message to Node-SM, or R-SM (for a Confirm),
or Q-SM (for a Response)
if the NoHello timer was running, stop it
Rule 3:
if reply requested
send MA-Hello
restart SendHello timer
Rule 4:
send MA-Hello message
restart SendHello timer
Rule 5:
queue message for later transmission
Rule 6:
pass outstanding queued messages to transport layer
stop any timers controlling connection establishment
start SendHello timer
Rule 7:
stop SendHello timer
start NoHello timer
Rule 8:
report failure to routing state machines and signalling applications
destroy self
Rule 9:
if reply requested
send MA-Hello
restart NoHello timer7. Additional Protocol Features ✨
7.1. Route Changes and Local Repair 🛠️
7.1.1. Introduction 🦋
so when IP layer rerouting happens in the network, GIST and signalling application state both need updating for every flow whose path changed 👀 How the signalling application state gets updated depends mainly on the application. For example, if the path characteristics changed, just moving state from the old path to the new one isn't enough 💀 So GIST can't finish the path update on its own. Its jobs are to detect the route change, keep its local routing state consistent, and tell the interested signalling applications at the affected nodes 🫶
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
x +--+ +--+ +--+ x Initial
x .|C1|_.....|D1|_.....|E1| x Configuration
x . +--+. .+--+. .+--+\. x
>>xxxxxxxxxxxxx . . . . . . xxxxxx>>
+-+ +-+ . .. .. . +-+
...|A|_......|B|/ .. .. .|F|_....
+-+ +-+ . . . . . . +-+
. . . . . .
. +--+ +--+ +--+ .
.|C2|_.....|D2|_.....|E2|/
+--+ +--+ +--+
+--+ +--+ +--+ Configuration
.|C1|......|D1|......|E1| after failure
. +--+ .+--+ +--+ of E1-F link
. \. . \. ./
+-+ +-+ . .. .. +-+
...|A|_......|B|. .. .. .|F|_....
+-+ +-+\ . . . . . +-+
>>xxxxxxxxxxxxx . . . . . . xxxxxx>>
x . +--+ +--+ +--+ . x
x .|C2|_.....|D2|_.....|E2|/ x
x +--+ +--+ +--+ x
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
........... = physical link topology
>>xxxxxxx>> = flow direction
_.......... = outgoing link for flow xxxxxx given
by local forwarding table
Figure 10: A Rerouting EventRoute change management is complicated because the problem is distributed 🌈 Look at the rerouting event in Figure 10. An outside observer would guess the main responsibility for controlling the updates will probably sit with nodes B and F. But E1 is best placed to spot the event quickly at the GIST level, and C1 and D1 could also try to kick off the repair 🎀
The NSIS framework [29] assumes that signalling applications are soft-state based and operate end to end. In that case, since GIST also periodically refreshes its picture of routing state, route changes will eventually get fixed automatically ✨ The spec as already written includes this. BUT, especially if upper layer refresh times get extended to cut down signalling load, the inconsistent state could last a really long time 😭 So GIST includes logic to swap prompt notifications with signalling applications, so local repair can happen when possible 💅 The extra mechanisms for this are in the subsections that follow. Mostly these additions can be seen as implementation issues: the protocol messages and what they mean don't change, but there are extra interactions through the API between GIST and signalling applications, plus extra triggers for moving between the various GIST states 🧚
7.1.2. Route Change Detection Mechanisms ✨
Okay so bestie, spotting a route change at a single node has two sides 👀
- Detecting that the outgoing path (the direction the Query travels) has changed, or might have changed.
- Detecting that the incoming path (the direction the Response travels) has changed, or might have, in which case the node might not be on the path at all anymore 😱
At one node these two processes are pretty independent, but a change in one direction at a node lines up with a change in the opposite direction at its peer 🫶 Also, a route change can come in two flavours: the interface a flow leaves or enters through might change, or the adjacent peer might change. Usually it's one or the other or both, and it's also possible for neither to change (though those changes are super hard to catch 🙈).
The route change detection tools a node has depend on which MRM is in use and on the role the node played when it set up the routing state (Querying or Responding node). This discussion is specifically about the path-coupled MRM using downstream Queries only 💅 Other setups might need other methods. The repair logic in the next subsections, though, is meant to work everywhere 🌈
There are five ways a node can detect that a route change happened. They work differently depending on whether the change is in the Query or Response direction, and the table below sums up those differences.
- Local Trigger: In local trigger mode, GIST finds out from the local forwarding table that the next hop changed. This only works if the routing change is local. It doesn't work if the change happens a few IP routing hops away, including when it happens at a GIST-unaware node 🧚
- Extended Trigger: GIST checks a link-state topology database to see that the path changed. This assumes IP route computation is consistent, and it only works within a single area for OSPF [16] and similar link-state protocols. When it's available it gives the most accurate and fastest heads-up about route changes 🔥 But it needs more access to routing internals than a typical operating system might give you 💀
- GIST C-mode Monitoring: GIST may notice C-mode packets arriving (from either peer) with a different IP layer TTL or on a different interface. This doesn't tell you anything directly about the new flow path, but it does say routing has changed and rediscovery may be needed 👀
- Data Plane Monitoring: The signalling application on a node may notice a change in how the flow behaves, like an IP layer TTL change, arrival on a different interface, or the flow disappearing altogether. The signalling application is allowed to pass this info along to the local GIST instance (Appendix B.6) 💌
- GIST Probing: Per the spec, each GIST node MUST periodically repeat the discovery (Query/Response) operation. Probe frequency values are discussed in Section 4.4.4. The period can be negotiated separately for each GIST hop, so nodes that have access to the other techniques above MAY use long periods between probes 😌 The Querying node finds the route change when the Response shows a modified
Network-Layer-Information. The Responding node can spot a change in its upstream peer the same way. Also, if the Responding node stores the interface Queries arrive on, it can notice when that interface changes even if the peer doesn't ✨
+-------------+--------------------------+--------------------------+
| Method | Query direction | Response direction |
+-------------+--------------------------+--------------------------+
| Local | Discovers new interface | Not applicable |
| Trigger | (and peer if local) | |
| | | |
| Extended | Discovers new interface | May determine that route |
| Trigger | and may determine new | from peer will have |
| | peer | changed |
| | | |
| C-mode | Provides hint that | Provides hint that |
| Monitoring | change has occurred | change has occurred |
| | | |
| Data Plane | Not applicable | NSLP informs GIST that a |
| Monitoring | | change may have occurred |
| | | |
| Probing | Discovers changed NLI in | Discovers changed NLI in |
| | Response | Query |
+-------------+--------------------------+--------------------------+7.1.3. GIST Behaviour Supporting Rerouting 🦋
Okay, so GIST needs a specific set of behaviours to handle rerouting, and you can model them with a three-level classification of how valid each bit of current routing state is 💜 (NSIS can also keep past routing state, which is covered in Section 7.1.4 below.) This classification is applied separately to the Querying and Responding nodes for each pair of GIST peers. The three levels are:
- Bad: The routing state is either missing completely or not safe to use for sending data 💀
- Tentative: The routing state may have changed, but it's still usable for sending NSLP data while it gets verified 🤞
- Good: The routing state has been established and no events affecting it have been detected since 💖
These classifications aren't identical to the states described in Section 6, but they do depend on each other. Routing state is considered Bad until the state machine first enters the Established state, and at that point it becomes Good 🎀 After that, the status can be invalidated for any of the reasons we talked about above. It's up to the implementation to decide which techniques to build in and how to reclassify routing state (as Bad or Tentative) for each one 🛠️ The status goes back to Good either when the state machine re-enters the Established state, or when GIST can confirm from direct inspection of the IP routing or forwarding tables that the peer hasn't changed. When the status returns to Good, GIST MUST, if necessary, update its routing state table so that the relationships between MRI/SID/NSLPID tuples and messaging associations are up to date 🙌
When the downstream routing state classification changes to Bad/Tentative because of local IP routing indications, GIST MAY automatically change the upstream classification to Tentative, unless local routing indicates that this isn't necessary. This SHOULD NOT be done when the initial change was indicated by the signalling application. The reason is that a routing change can affect several nodes, so it can be a hint that upstream routing may have changed too 👀 Either way, whenever GIST updates the routing status, it tells the signalling application through the NetworkNotification API (Appendix B.4), unless the change was caused through the API in the first place 📣
The repair behaviour for state is different for Querying and Responding nodes. The Responding node doesn't do anything extra, since it can't start protocol transitions on its own. It can only react to the Querying node 🥺 The Querying node has three options, depending on how the move away from Good was originally triggered:
- Inspect the IP routing/forwarding table and verify that the next peer hasn't changed. This technique MUST NOT be used if the transition was caused by a signalling application, but SHOULD be used otherwise, if available 🔍
- Move to the Awaiting Refresh state. This technique MUST NOT be used if the current status is Bad, since data is being delivered incorrectly 🚫
- Move to the Awaiting Response state. This technique may be used at any time, but it has the effect of freezing NSLP communication while GIST state is being repaired 🧊
The second and third techniques kick off a GIST handshake to do the repair. You might want to delay starting the handshake, whether to wait for the network to settle, to avoid flooding the network with Query traffic when a bunch of flows are affected, or to confirm the node is still on the path from the upstream peer ⏳ One approach is to hold off on the handshake until there's NSLP data to send. Setting up these delays is a matter of local policy, but GIST MUST begin the handshake immediately if the status change was caused by an InvalidateRoutingState API call marked as 'Urgent', and SHOULD begin it if the upstream routing state is still known to be Good 🚨 💅
7.1.4. Load Splitting and Route Flapping 🦋
okay so bestie, the Q-mode encapsulation rules in Section 5.8 are trying their hardest to make the Query messages that discover the path copy the flow as closely as possible 🫶. but ngl, in networks with load balancing over multiple routes, the path a Query finds can change from one handshake to the next even when the network is totally stable 😭. this happens when the balancing depends on header fields that differ between flow packets and Q-mode packets, or when it just goes round-robin. GIST sees that as a route flap 🎀. flapping can also come from real connectivity or routing protocol problems. for example, a mobile node might be bouncing between two links, or it might look like it vanished even though it's still reachable through a different route 🌈.
this spec doesn't define mechanisms for GIST to manage multiple parallel routes or an unstable route 💅. instead, GIST MAY expose this to the NSLP, and the NSLP can manage it based on what the signalling application needs ✨. the algorithms we already covered always keep track of the current route, which is just the latest peer found for a flow 💖. but GIST lets signalling applications keep using prior signalling paths for a while, as long as they still need them 🧚. NSLP peers are only one GIST hop apart, so to represent a path you can just use an entry in the node's routing state table for that flow (more generally, anything that uniquely identifies the peer, like the NLI, could work too) 🍓. GIST doesn't have to juggle multiple generations of this info. instead, it hands the signalling application an opaque form of it, in the same node, for each message received from that peer 🫧. the app can store it if it needs to, and give it back to GIST whenever it's needed. since this is a reference to info about where a prior signalling message came from, it's called 'SII-Handle' (for Source Identification Information) in the abstract API of Appendix B 🔥.
if possible, GIST SHOULD use the same SII-Handle for multiple sessions to the same peer. this lets signalling applications bundle things together, like summary refreshes or bulk teardowns 💜.
messages sent using the SII-Handle MUST bypass the routing state tables at the sender 😤, and that MUST be signalled by setting the E-flag in the common header (Appendix A.1). messages other than Data messages MUST NOT be sent this way 🙅♀️. at the receiver, GIST MUST NOT check the MRI/SID/NSLPID against local routing state. instead it tells signalling applications what mode the message arrived in, through the API (Appendix B.2) 🌸. signalling applications should check the source and effect of the message themselves. and if it's appropriate, they should tell GIST (see Appendix B.5) that routing state isn't needed for this flow anymore 🙈. this matters because otherwise GIST on the nodes of the old path could start refreshing routing state and cause state conflicts at the crossover router 💀.
GIST tells signalling applications about route modifications as two kinds of event: additions and deletions 🌈. an addition is reported as a change to the current routing state, using the Bad/Tentative/Good classification above. a deletion is reported as a statement that an SII-Handle is no longer on the path ✨. both can be reported through the NetworkNotification API call (Appendix B.4) 💅. a minimal implementation MAY report a route change as a single (add, delete) operation. but a more sophisticated implementation MAY delay the delete notification, for example if it knows the old route is still used in parallel, or that the true route is flapping between the two 🦋. after that, it's up to the signalling application design whether to tear down state on the old path, leave it alone, or change it in some app-specific way to reflect that multiple paths are running in parallel 👑.
7.1.5. Signalling Application Operation ⭐
signalling applications can use these functions from GIST to do rapid local repair after rerouting events 🔥. the signalling application instances handle the multi-hop parts of the procedure, including crossover node detection and the tear-down and reinstallation of signalling application state 💖. they also tell GIST to run the local routing state maintenance operations over each individual hop 🫶. local repair depends heavily on stateful NSLP nodes being a single GIST hop apart, and the details of GIST peer discovery are what enforce that 🧚.
here's an outline of one possible set of NSLP actions, using the scenario in Figure 10 as the example 🎀.
- the signalling application at node E1 gets notified by GIST about route changes in the downstream and upstream directions 👀. the downstream status flipped to Bad because of a trigger from the local forwarding tables, and the upstream status automatically changed to Tentative as a result 💅. the app at E1 MAY start local repair right away, or MAY send a notification upstream to D1 saying rerouting happened 🌸.
- the signalling application at node D1 hears about the route change, either through signalling application notifications or from the GIST level (e.g., a trigger from a link-state topology database) ✨. if the info spreads faster within the IP routing protocol, GIST will switch the upstream/downstream routing state to Tentative/Bad on its own, and that will make the signalling application pass the notification further upstream 🦋.
- this keeps going until the notification reaches node A 🫧. there's no downstream routing change at A, so GIST only learns about the update through the signalling application trigger. since the upstream status is still Good, A starts the repair handshake immediately 🚀.
- the handshake from node A confirms its downstream routing state as Good and unchanged there 💖. it also confirms the (Tentative) upstream routing state at B as Good 🫶. that's enough to identify B as the crossover router, and the signalling application and GIST can start the local repair process 👑.
there's another way to get to step (4) 💅. node B can work out on its own that an upstream route change is very unlikely. for example, it could be an area border router and the route change is only within its area 🌈. in that case, the signalling application and GIST will see the upstream state is Good and can start local repair directly ✨.
after a route deletion, a signalling application might want to remove state at another node that's no longer on the path 🥺. but since that node is off the path now, GIST in principle can't send messages to it anymore 💀. generally, as long as this state is soft, it'll time out anyway 🙃. the catch is that the timeouts might have been set really long to cut down on signalling load 😭. so instead, signalling applications MAY use the SII-Handle described above to route explicit teardown messages 🧚.
7.2. NAT Traversal 🌍
GIST messages, like the ones for the path-coupled MRM, must carry addressing and higher layer information as payload data so they can define the flow being signalled for 🎀. this applies to all GIST messages, no matter how they're encapsulated or which direction they're going 💜. at an addressing boundary, the data flow packets get their headers translated 🦋. if the signalling payloads aren't translated consistently, the signalling messages end up referring to the wrong (and probably meaningless) flows after crossing the boundary 💀. on top of that, GIST handshake messages carry extra addressing info about the GIST nodes themselves, and that has to be processed properly when going through a NAT too 🫶.
there's a two-sided problem here 👀. can the GIST peers on either side of the boundary work out how to address each other? and can they figure out what translation to apply to the signalling packet payloads? generic NAT traversal techniques like Session Traversal Utilities for NAT (STUN) [26] or Traversal Using Relays around NAT (TURN) [27] can only operate on the two addresses visible in the IP header 😩. so it's really hard to use them to find a consistent translation for the three or four interdependent addresses of the flow and the signalling source and destination 🌀.
for legacy NATs and MRMs that carry addressing info, the base GIST spec is limited to detecting the situation and triggering the right error conditions to end the signalling path 🚫. (MRMs that don't contain addressing info could safely cross such NATs, with some changes to the GIST processing rules. those changes could be described in the documents that define those MRMs 💖.) legacy NAT handling is covered in Section 7.2.1 below ✨. a more general solution can be built using GIST-awareness in the NATs themselves 🧚. that solution is outlined in Section 7.2.2, with processing rules in Section 7.2.3 🎀.
in every case, how GIST interacts with the NAT depends on how the NAT handles the Query/Response messages in the initial GIST handshake 🔥. those messages are UDP datagrams 🦋. the best current practice for NAT treatment of UDP traffic is defined in [38], and the legacy NAT handling in this spec is fully consistent with that document 💅. the GIST-aware NAT traversal technique is equivalent to requiring an Application Layer Gateway in the NAT for a specific class of UDP transactions 🌈. that class is the ones where the destination UDP port of the initial message is the GIST port (see Section 9) 🫶.
7.2.1. Legacy NAT Handling ✨
Okay so legacy NAT detection during the GIST handshake is all about three things: the IP header, the S-flag in the GIST common header, and the NLI object in the handshake messages. 💅 How the whole dance plays out depends on whether the Querying node is on the internal or external side of the NAT.
Let's start with the internal case. If the S-flag is not set in the Query (S=0), a legacy NAT cannot be detected 😭 The receiver will still generate a normal Response to the interface-address given in the NLI, but that interface-address isn't routable, so the Response never gets delivered. If retransmitted Queries keep S=0, this just keeps happening until the Querying node times out. The signalling path ends right there and never gets across the NAT. Not iconic at all 💀
The plot twists once S=1 shows up in a Query. Note that the Q-mode encapsulation rules recommend S=1 for at least some retransmissions (see Section 5.8) 🎀 If S=1, the receiver MUST check the source address in the IP header against the interface-address in the NLI. A legacy NAT has been found if those addresses don't match. For MRMs that contain addressing information needing translation, legacy NAT traversal is not possible, so the receiver MUST return an "Object Type Error" message (Appendix A.4.4.9) with subcode 4 ("Untranslated Object"), pointing at the MRI as the object in question. That error MUST be addressed to the source address from the IP header of the incoming message. The Responding node SHOULD use the destination IP address of the original datagram as the source address in the IP header of the Response 🦋 This makes the NAT more likely to accept the incoming message, because it looks like a totally normal UDP/IP request/reply exchange. If this message makes it back through the NAT, the Querying node terminates the handshake immediately. If not, it's basically the earlier case of a lost Response, and the Querying node gives up when it hits its retransmission limit.
Now the external case. When the Querying node is on the external side of the NAT, the Query only traverses the NAT if some static configuration has been set up on the NAT to forward GIST Q-mode traffic to a node on the internal network. Regardless of the S-flag in the Query, the Responding node cannot directly detect the NAT's presence 🙈 So it MUST send a normal Response with S=1 to an address derived from the Querying node's NLI, one that will traverse the NAT as regular UDP traffic. The Querying node MUST check the source address in the IP header against the NLI in the Response, and when it finds a mismatch, it MUST terminate the handshake. Main character energy for the NAT, honestly 👑
In either of the error cases (internal or external Querying node), terminating the handshake is not the only option. A legacy NAT traversal procedure could be invoked instead. This specification doesn't define any such procedure, although one possible approach is described in [43]. Any such traversal procedure MUST be incorporated into GIST using the existing GIST extensibility capabilities.
One more thing, bestie 🫶 this detection process only works with the handshake exchange. It can't operate on simple Data messages, whether they're Q-mode or normally encapsulated. So Nodes SHOULD NOT send Data messages outside a messaging association if they cannot ensure they're operating in an environment free of legacy NATs. Protect your Data messages like they're your phone 📱🔒
7.2.2. GIST-Aware NAT Traversal 🦋
The most robust solution to the NAT traversal problem is to require that a NAT is GIST-aware, and to let it modify messages based on the contents of the MRI 💖 This assumes that NATs only rewrite the header fields included in the MRI, and not other higher-layer identifiers. As long as this is done consistently with the data flow header translation, signalling messages can be valid on each side of the boundary, and the NAT doesn't need to be signalling application aware. Note, though, that if the NAT doesn't understand the MRI and the N-flag in the MRI is clear (see Appendix A.3.1), it should reject the message with an "Object Type Error" message (Appendix A.4.4.9) with subcode 4 ("Untranslated Object").
The basic concept is that GIST-aware NATs modify any signalling messages that have to be interpreted without any routing state being available. These messages are identified by the context-free flag C=1 in the common header, and they include the Query in the GIST handshake. On top of that, NATs have to modify the remaining handshake messages that set up routing state ✨ When routing state gets set up, GIST records how subsequent messages related to that routing state should be translated. If no routing state is being used for a message, GIST directly uses the modifications the NAT made to translate it.
This specification defines an additional NAT traversal object that a NAT inserts into all Q-mode encapsulated messages with the context-free flag C=1, and which GIST echoes back in any replies, i.e., Response or Error messages 🎀 NATs only apply GIST-specific processing to Q-mode encapsulated messages with C=1, or to D-mode messages carrying the NAT traversal object. All other GIST messages, whether they're in C-mode or in D-mode with no NAT-Traversal object, should be treated as normal data traffic by the NAT. That means IP and transport layer header translation, with no GIST-specific processing. The distinction between Q-mode and D-mode encapsulation may not be observable to the NAT, which is exactly why the setting of the C-flag or the presence of the NAT traversal object is used as the interception criteria. The NAT decisions are based purely on the value of the C-flag and the presence of the NAT traversal object, not on the message type 🌸
The NAT-Traversal object (Appendix A.3.9) carries the translation between the MRIs that are appropriate for the internal and external sides of the NAT. It also carries a list of which other objects in the message have been translated. This should always include the NLI, and the Stack-Configuration-Data if present. If GIST is extended with further objects that carry addressing data, this list lets a message receiver figure out whether the NAT supported those new objects. Finally, the NAT-Traversal object MAY be used to carry data that helps the NAT back-translate D-mode responses. This could be the original NLI or SCD, or opaque equivalents in the case of topology hiding 🧚
Here's the plot twist 😭 a consequence of all this is that the routing state tables at the signalling application peers on each side of the NAT are no longer directly compatible. In particular, they use different MRI values to refer to the same flow. However, messages after the Query/Response (the initial Confirm and subsequent Data messages) need to use a common MRI, since the NAT doesn't rewrite these. That common MRI is chosen to be the MRI of the Querying node. It's the responsibility of the Responding node to translate between the two MRIs on inbound and outbound messages, which is exactly why the unmodified MRI gets propagated in the NAT-Traversal object 💅💜
7.2.3. Message Processing Rules ✨
okay so this part is the NAT rulebook, and bestie, the big thing to know is that the spec only normatively defines what a GIST node does when it gets a message with a NAT-Traversal object 💅. The NAT's own behaviour is informative only, because it depends on how the NAT is built and what its bindings policy says. Full NAT details for GIST messages are in [44] if you're nerdy like me 🤓🫶
A possible set of operations for a NAT to process a message with C=1 looks like this. Heads up: for a Data message, only some of these steps apply 🎀
- Verify that bindings for any data flow are actually in place.
- Create a new Message-Routing-Information object with fields modified according to the data flow bindings.
- Create bindings for subsequent C-mode signalling based on the information in the Network-Layer-Information and Stack-Configuration-Data objects.
- Create new Network-Layer-Information and if necessary Stack-Configuration-Data objects with fields to force D-mode response messages through the NAT, and to allow C-mode exchanges using the C-mode signalling bindings.
- Add a NAT-Traversal object, listing the objects that have been modified and including the unmodified MRI and any other data needed to interpret the response. If a NAT-Traversal object is already present, in the case of a sequence of NATs, the list of modified objects may be updated and further opaque data added, but the MRI contained in it is left unchanged. 🧚
- Encapsulate the message according to the normal rules of this specification for the Q-mode encapsulation. If the S-flag was set in the original message, the same IP source address selection policy should be applied to the forwarded message. 🌸
- Forward the message with these new payloads. 🚀
Now the GIST node side, which is where the real drama is 😭 A GIST node receiving such a message MUST verify that all mandatory objects containing addressing have been translated correctly. If not, it has to reject the message with an "Object Type Error" message (Appendix A.4.4.9) with subcode 4 ("Untranslated Object"). The error message MUST include the NAT-Traversal object as the first TLV after the common header, and this is also true for any other error message generated as a reply. Otherwise, the message is processed essentially as normal. If no state needs to be updated for the message, the NAT-Traversal object can be effectively ignored ✨
The other possibility is that a Response must be returned, because the message is either the beginning of a handshake for a new flow or a refresh for existing state. In both cases, the GIST node MUST create the Response in the normal way using the local form of the MRI, plus its own NLI and (if necessary) SCD. It MUST also include the NAT-Traversal object as the first object in the Response after the common header. Main character energy 👑
A NAT will intercept D-mode messages containing those echoed NAT-Traversal objects. Its processing is a subset of the C=1 case:
- Verify the existence of bindings for the data flow.
- Leave the Message-Routing-Information object unchanged.
- Modify the NLI and SCD objects for the Responding node if necessary, and create or update any bindings for C-mode signalling traffic.
- Forward the message.
A GIST node receiving such a message (Response or Error) MUST use the MRI from the NAT-Traversal object as the key to index its internal routing state. It MAY also store the translated MRI for additional (e.g., diagnostic) information, but this is not used in the GIST processing. The remainder of GIST processing is unchanged 💜
Heads up, bestie: Confirm messages do NOT get GIST-specific processing from the NAT 🙈 So a Responding node that has delayed state installation until it receives the Confirm only has the untranslated MRI describing the flow, plus the untranslated NLI as peer routing state. That would stop it interpreting the signalling messages correctly, and later Query (refresh) messages would always look like route changes because the NLI changed. 💀
So a Responding node that wants to delay state installation until a Confirm arrives must somehow reconstruct the translations when the Confirm shows up. How to do that is an implementation issue ✨ One approach is to carry the translated objects as part of the Responder-Cookie that gets echoed in the Confirm. And for one of the cookie constructions in Section 8.5, this happens automatically 🎀
7.3. Interaction with IP Tunnelling 🦋
The interaction between GIST and IP tunnelling is very simple, honestly iconic 💅 An IP packet carrying a GIST message is treated exactly the same as any other packet with the same source and destination addresses. In other words, it gets the tunnel encapsulation and is forwarded with the other data packets 🌊
Tunnelled packets won't be identifiable as GIST messages until they leave the tunnel, because any Router Alert Option and the standard GIST protocol encapsulation (e.g., port numbers) get hidden inside the standard tunnel encapsulation 🙈 If signalling is needed for the tunnel itself, one of the tunnel endpoints has to start it as a separate signalling session. That means the tunnel counts as a new flow 🧚
The relationship between signalling for the microflow and signalling for the whole tunnel depends on the signalling application in question. So it's a signalling application responsibility to be aware that tunnelling is happening and to carry out additional signalling if necessary. In other words, at least one tunnel endpoint must be signalling application aware 👑
Sometimes it's the tunnel exit point (the node where tunnelled data and downstream signalling packets leave the tunnel) that wants to run the tunnel signalling. But that node has no knowledge or control of how the tunnel entry point does the data flow encapsulation 😭 So the information about how the inner MRI/SID relate to the tunnel MRI/SID needs to be carried in the signalling data from the tunnel entry point. This job is the equivalent of the RSVP SESSION_ASSOC object of [18] 🌸 In the NSIS protocol suite, these bindings are managed by the signalling applications. They can be implicit (e.g., by SID re-use) or explicit, by carrying objects that bind the inner and outer SIDs as part of the NSLP payload ✨
7.4. IPv4-IPv6 Transition and Interworking 🌈
GIST itself is essentially IP version neutral. Version dependencies are isolated in the formats of the Message-Routing-Information, Network-Layer-Information, and Stack-Configuration-Data objects, and GIST also depends on the version independence of the protocols that support messaging associations 💖 In mixed environments, GIST operation will be influenced by whichever IP transition mechanisms are in use. This section gives a high-level overview of how GIST is affected, considering only the currently predominant mechanisms 🧚
- Dual Stack: (As described in [35].) In mixed environments, GIST MUST use the same IP version for Q-mode encapsulated messages as given by the MRI of the flow it is signalling for, and SHOULD do so for other signalling too (see Section 5.2.2). Messages with mismatching versions MUST be rejected with an "MRI Validation Failure" error message (Appendix A.4.4.12) with subcode 1 ("IP Version Mismatch"). The IP version used in D-mode is closely tied to the IP version used by the data flow, so it's intrinsically impossible for an IPv4-only or IPv6-only GIST node to support signalling for flows using the other IP version 🙅♀️ Hosts that are dual stack for applications, and routers that are dual stack for forwarding, need GIST implementations that can support both IP versions 💅 Applications with a choice of IP versions might select a version based on which one GIST can support in the network. That could be established by invoking parallel discovery procedures 🔥
- Packet Translation: (Applicable to SIIT [7].) Some transition mechanisms let IPv4 and IPv6 nodes communicate by placing packet translators between them 🦋 From the GIST perspective, this should be treated essentially the same way as any other NAT operation (e.g., between internal and external addresses) as described in Section 7.2. The translating node needs to be GIST-aware, because it has to translate the addressing payloads between IPv4 and IPv6 formats for flows that cross between the two. The translation rules for the fields in the MRI payload (including, e.g., diffserv-codepoint and flow-label) are as defined in [7]. The same analysis applies to NAT-PT, although that technique is no longer proposed as a general purpose transition mechanism [40] 🙈
- Tunnelling: (Applicable to 6to4 [19].) Many transition mechanisms handle the problem of how an end-to-end IPv6 (or IPv4) flow can be carried over intermediate IPv4 (or IPv6) regions by tunnelling. The methods tend to focus on minimising the tunnel administration overhead ✨ For GIST, the treatment should be similar to any other IP tunnelling mechanism, as described in Section 7.3. In particular, the end-to-end flow signalling passes transparently through the tunnel, and signalling for the tunnel itself will have to be managed by the tunnel endpoints. However, additional considerations may arise because of special features of the tunnel management procedures. In particular, [20] is based on using an anycast address as the destination tunnel endpoint. GIST MAY use anycast destination addresses in the Q-mode encapsulation of D-mode messages if necessary, but MUST NOT use them in the Network-Layer-Information addressing field; unicast addresses MUST be used instead 🫶 Note that the addresses from the IP header are not used by GIST in matching requests and replies, so there's no requirement to use anycast source addresses 💜
8. Security Considerations ✨
okay bestie, security is where GIST gets serious 🔒💅. The whole goal is protecting the signalling plane from the threats that [30] lays out, and the NSIS framework [29] hands the NTLP a specific subset of those responsibilities. The main things to handle are:
- Message Protection: signalling message content can be protected against eavesdropping, modification, injection, and replay while it's in transit 🛡️. This covers GIST payloads, and GIST should also offer that protection as a service to signalling applications between adjacent peers 🫶.
- Routing State Integrity Protection: signalling messages have to reach the correct nodes, and nowhere else 🎯. Here, "correct" means "the appropriate nodes for the signalling given the Message-Routing-Information". When the MRI is based on flow identification for path-coupled signalling, "appropriate" means "the same nodes that the infrastructure will route data flow packets through" 🌸. GIST has no role in deciding whether the data flow itself is being routed correctly. All it can do is make sure signalling and data routing are consistent with each other 💖. GIST uses internal state to decide how to route signalling messages, so that state needs protecting against corruption 🧚.
- Prevention of Denial-of-Service Attacks: GIST nodes and the network have finite resources (state storage, processing power, bandwidth) 🥺. The protocol tries to minimise exhaustion attacks against those resources, and it won't let GIST nodes be used to launch attacks on other network elements 🚫.
The main extra issue is handling authorisation for executing signalling operations (e.g., allocating resources) 👑. This is assumed to be done in each signalling application.
In lots of cases, GIST leans on the security mechanisms available in messaging associations instead of inventing new ones 🫧. Obvi, that means the interaction between those mechanisms and the rest of GIST has to be understood and verified, and Section 5.7 discusses some aspects of that 🔍.
8.1. Message Confidentiality and Integrity
GIST can use messaging association functionality to keep messages confidential and intact, and in this version that means TLS (Section 5.7.3) 🔐. Implementing this functionality is REQUIRED, but using it for any given flow or signalling application is OPTIONAL 🎀. Confidentiality of GIST information itself often isn't a huge concern, especially since messages are frequently sent to parties nobody knows in advance 🤷♀️. Even so, the content that's visible at the GIST level gives plenty of opportunities for traffic analysis 👀. Signalling applications can have their own way of securing content if they need it. They might find it handy to rely on the protection from messaging associations, though, since that protection runs unbroken between signalling application peers 🧵.
8.2. Peer Node Authentication
Cryptographic protection (of confidentiality or integrity) needs a security association with session keys 🗝️. Those keys can be set up by an authentication and key exchange protocol based on shared secrets, public key techniques, or a mix of both. Authentication and key agreement are possible using the protocols tied to the messaging association being secured, and TLS builds this functionality right in 💜. GIST nodes rely on the messaging association protocol to authenticate the identity of the next hop, and GIST has no authentication capability of its own 🙈.
With routing state discovery, there are few effective ways to tell a legitimate next or previous hop from an impostor 😬. In other words, cryptographic authentication here only proves that a node is "who" it is (the legitimate owner of an identity in some namespace), not "what" it is (a node that's genuinely on the flow path and can therefore carry out signalling for a particular flow) 🕵️♀️. Authentication gives only limited protection, since a known peer is unlikely to lie about its role. More protection against this kind of attack is covered in Section 8.3 below 👇.
It's an implementation issue whether peer node authentication should depend on the signalling application. For example, successful authentication could be tied to presenting credentials for a particular signalling role (like signalling for QoS) 🎟️. The abstract API of Appendix B leaves that kind of policy and authentication interaction between GIST and the NSLP it's serving open 🌈. It does let applications inspect the authenticated identity of the peer a message will be sent to before transmission, which is a nice little perk 💅.
8.3. Routing State Integrity
Internal state in a node (see Section 4.2) is what gets used to route messages 🗺️. If that state is corrupted, signalling messages may be misdirected 💀.
When the MRM is path-coupled, the messages need to be routed identically to the data flow described by the MRI. The routing state table is GIST's view of how these flows are being routed through the network in the immediate neighbourhood of the node 🦋. Routes are only weakly secured (for example, there's no cryptographic binding of a flow to a route), and there's no authoritative information about flow routes other than the current state of the network itself 😭. So consistency between GIST and network routing state has to be ensured by directly interacting with the IP routing mechanisms, to make sure the signalling peers are the appropriate ones for any given flow 🧭. An overview of security issues and techniques in this context is provided in [37] 📚.
In one direction, peer identification is installed and refreshed only on receiving a Response (compare Figure 5) 🌷. That Response MUST echo the cookie from a previous Query, which was sent along the flow path with the Q-mode encapsulation, i.e., end-to-end addressed ✨. So only the true next peer or an on-path attacker can generate such a message, as long as freshness of the cookie can be checked at the Querying node ⏰.
In the other direction, peer identification MAY be installed directly on receiving a Query that contains addressing information for the signalling source 🤔. Here's the thing though: any node in the network could generate such a message, and plenty of nodes could be the genuine upstream peer for a given flow 😱. To protect against this, four strategies are used:
- Filtering: the receiving node MAY reject signalling messages that claim to be for flows with flow source addresses that could be ruled out by ingress filtering 🚧. An extension of this would be for the receiving node to monitor the data plane and explicitly check that flow packets arrive over the same interface, and if possible from the same link layer neighbour, as the D-mode signalling packets 👀. If they don't, at least one of the signalling or flow packets is likely being spoofed 🚨.
- Return routability checking: the receiving node MAY refuse to install upstream state until it has completed a Confirm handshake with the peer 🤝. The Confirm echoes the Responder-Cookie of the Response, which discourages nodes from using forged source addresses 🙅♀️. This also plays a role in denial-of-service prevention, as covered below 🛡️.
- Authorisation: a stronger approach is to carry out a peer authorisation check (see Section 4.4.2) as part of messaging association setup 💪. The ideal situation is that the receiving node can work out the correct upstream node address from routing table analysis or knowledge of local topology constraints, and then verify from the authorised peer database (APD) that the peer has this IP address 🗂️. This is only technically feasible in a limited set of deployment environments 🥲. The APD can also list the subsets of nodes that are feasible peers for particular source or destination subnets, or blacklist nodes that have previously originated attacks or exist in untrustworthy networks, which provide weaker levels of authorisation checking 🚫.
- SID segregation: the routing state lookup for a given MRI and NSLPID MUST also take the SID into account 🔑. A malicious node can only overwrite existing GIST routing state if it can guess the corresponding SID 🎲. It can insert state with random SID values, but generally that won't be used to route signalling messages for which state has already been legitimately established 🙅♀️.
8.4. Denial-of-Service Prevention and Overload Protection 🛡️
Okay so GIST is designed so that, in general, each Query only generates at most one Response, and that Response is at most only slightly larger than the Query. 💅 That means a GIST node can't become the source of a denial-of-service amplification attack. (There's a special case with retransmitted Response messages, so check Section 5.3.3 for that one. 🫶)
BUT, bestie, GIST can still get hit with denial-of-service attacks. An attacker using forged source addresses can force a node to establish state without return routability, which is basically a TCP SYN flood situation. 😭 An adversary might also use modified or replayed unprotected signalling messages as part of that. There are two types of state attacks and one computational resource attack. 💀
In the first state attack, an attacker floods a node with messages that the node has to store until it can figure out the next hop. If the destination address is chosen so there's no GIST-capable next hop, the node would be stuck accumulating messages for several seconds until the discovery retransmission attempt times out. Rude. 🙈
The second type of state-based attack causes GIST state to get established by bogus messages. And the related computational or network-resource attack uses unverified messages to make a node query an authentication or authorisation infrastructure, or try to cryptographically verify a digital signature. The main character energy of attackers is WILD. 🔥
We use a combination of two defences against these attacks:
- The Responding node need not establish a session or discover its next hop on receiving the Query, but MAY wait for a Confirm, possibly on a secure channel. If the channel exists, the additional delay is one one-way delay, and the total is no more than the minimal theoretically possible delay of a three-way handshake, i.e., 1.5 node-to-node round-trip times. The delay gets significantly larger if a new connection needs to be established first. ⏳
- The Response to the Query contains a cookie, which is repeated in the Confirm. State is only established for messages that contain a valid cookie. The setup delay is also 1.5 round-trip times. This mechanism is similar to the one in SCTP [39] and other modern protocols. 🦋
There's a potential overload condition if a node is flooded with Query or Confirm messages. One option is for the node to bypass these messages altogether, as described in Section 4.3.2, which effectively means falling back to being a non-NSIS node. 🌸 If that's not possible, a node MAY still choose to limit the rate at which it processes Query messages and discard the excess, although it SHOULD first adapt its policy to one of sending Responses statelessly, if it isn't already doing so. ✨
A conformant GIST node will automatically decrease the load by retransmitting Queries with an exponential backoff. 🌈 A non-conformant node (the one launching a DoS attack) can generate uncorrelated Queries at an arbitrary rate, which makes it hard to apply rate-limiting without also messing with genuine handshake attempts. 😤 However, if Confirm messages are requested, the cookie binds the message to a Querying node address that has been validated by a return routability check, and then rate-limits can be applied per source. 🎀
Once a node has decided to establish routing state, there may still be transport and security state to set up between peers. This state setup is also vulnerable to denial-of-service attacks. GIST relies on the implementations of the lower layer protocols that make up messaging associations to mitigate such attacks. In the current specification, the Querying node is always the one wishing to establish a messaging association, so it's the Responding node that needs protecting. It's possible for an attacking node to execute these protocols legally to set up large numbers of associations that were never used, and Responding node implementations MAY use rate-limiting or other techniques to control the load in such cases. 🧚
Signalling applications can use the services GIST provides to defend against certain (e.g., flooding) denial-of-service attacks. In particular, they can elect to process only messages from peers that have passed a return routability check or been authenticated at the messaging association level (see Appendix B.2). Signalling applications that accept messages under other circumstances (in particular, before routing state has been fully established at the GIST level) need to take this into account when designing their denial-of-service prevention mechanisms, for example, by not creating local state as a result of processing such messages. 👑 Signalling applications can also manage overload by invoking flow control, as described in Section 4.1.1.
8.5. Requirements on Cookie Mechanisms 🍓
Let's talk cookies, bestie. 🍪 The requirements on the Query-Cookie can be summarised like this:
- Liveness: The cookie must be live; that is, it must change from one handshake to the next. This prevents replay attacks.
- Unpredictability: The cookie must not be guessable, e.g., from a sequence or timestamp. This prevents direct forgery after capturing a set of earlier messages.
- Easily validated: It must be efficient for the Q-Node to validate that a particular cookie matches an in-progress handshake, for a routing state machine that already exists. This allows discarding responses that have been randomly generated by an adversary, or discarding responses to queries that were generated with forged source addresses or an incorrect address in the included NLI object. 🔍
- Uniqueness: Each handshake must have a unique cookie, since the cookie is used to match responses within a handshake, e.g., when multiple messaging associations are multiplexed over the same transport connection. 🦋
Likewise, the requirements on the Responder-Cookie can be summarised as follows:
- Liveness: The cookie must be live as above, to prevent replay attacks. 🔁
- Creation simplicity: The cookie must be lightweight to generate, in order to avoid resource exhaustion at the responding node. 💖
- Validation simplicity: It must be simple for the R-node to validate that an R-Cookie was generated by itself and no one else, without storing state about the handshake for which it was generated. 🧠
- Binding: The cookie must be bound to the routing state that will be installed, to prevent use with different routing state, e.g., in a modified Confirm. The routing state here includes the Peer-Identity and Interface-Address given in the NLI of the Query, and the MRI/NSLPID for the messaging.
It can also include the interface on which the Query was received, for use later in route change detection (Section 7.1.2). Since a Q-mode encapsulated message is the one that will best follow the data path, subsequent changes in this arrival interface indicate route changes between the peers. 🛣️
A suitable implementation for the Q-Cookie is a cryptographically strong random number that is unique for this routing state machine handshake. A node MUST implement this or an equivalently strong mechanism. Guidance on random number generation can be found in [31]. 🎲
A suitable basic implementation for the R-Cookie is as follows:
R-Cookie = liveness data + reception interface
+ hash (locally known secret,
Q-Node NLI identity and address, MRI, NSLPID,
liveness data)A node MUST implement this or an equivalently strong mechanism. There are several alternatives for the liveness data. One is to use a timestamp, like SCTP. Another is to give the local secret a (rapid) rollover, with the liveness data as the generation number of the secret, like IKEv2. In both cases, the liveness data has to be carried outside the hash, to allow the hash to be verified at the Responder. Another approach is to replace the hash with encryption under a locally known secret, in which case the liveness data does not need to be carried in the clear. Any symmetric cipher immune to known plaintext attacks can be used. In the case of GIST-aware NAT traversal with delayed state installation, it is necessary to carry additional data in the cookie; appropriate constructions are described in [44]. 🔐
To support the validation simplicity requirement, the Responder can check the liveness data to filter out some blind (flooding) attacks before beginning any cryptographic cookie verification. To support this usage, the liveness data must be carried in the clear and must not be easily guessable. This rules out the timestamp approach and suggests the use of a sequence of secrets, with the liveness data identifying the position in the sequence. The secret strength and rollover frequency must be high enough that the secret cannot be brute-forced during its lifetime. Note that any node can use a Query to discover the current liveness data, so it remains hard to defend against sophisticated attacks that disguise such probes within a flood of Queries from forged source addresses. Therefore, it remains important to use an efficient hashing mechanism or equivalent. 🙃
If a node receives a message for which cookie validation fails, it MAY return an "Object Value Error" message (Appendix A.4.4.10) with subcode 4 ("Invalid Cookie") to the sender, and SHOULD log an error condition locally, as well as dropping the message. 📝 However, sending the error in general makes a node a source of backscatter. 🚨 Therefore, this MUST only be enabled selectively, e.g., during initial deployment or debugging. > Don't leave it switched on in production, bestie. 💅
8.6. Security Protocol Selection Policy ✨
okay so GIST only defines one security protocol that every implementation has to support, and that's TLS (Section 5.7.3) 💖 But the door is open for more later, like for using other kinds of credentials or moving to protocols with stronger security properties 🦋 Also, using any security protocol for a messaging association is optional 🫶 Picking the security protocol happens during the GIST handshake (Section 4.4.1) 💅
Now the tricky part 😭 The selection process can get downgrade attacked. That's when a man in the middle changes the capabilities offered in the Query or the Response, so the peers end up accepting less protection than they could've actually had 💀 GIST has a two-part defence against this, based on the same ideas as [25] 🔥
- The Response doesn't depend on the Stack-Proposal in the Query (see Section 5.7.1) 🎀 So if someone messes with the Query, it doesn't change the final messaging association setup at all ✨
- The Responding node's Stack-Proposal gets echoed back in the Confirm 🌸 The Responding node checks that the proposal it sent in the Response matches what the Querying node got. And since point 1 holds, the Responding node doesn't need to remember its proposal, because it's just a fixed result of its local policy 🧚
BUT here's the catch 🙈 The second part only works if the Confirm is protected strongly enough. If the Querying node is fine creating messaging associations with no security at all (like plain TCP), the defence basically doesn't work 😭 The man in the middle can slip the original Responder's Stack-Proposal back in, and the Responding node will just think the weak protection is because the Querying node is limited 💀 However, if the messaging association gives at least integrity protection that can't be broken in real time, then the Confirm can't be tampered with like that 🔒 So if the Querying node doesn't apply a security policy that guarantees at least this minimum level of protection on the messaging association protocols it creates, it's still open to a downgrade going unnoticed 👀 Having that policy in place is what makes sure the capability discovery process ends up setting up a messaging association with the right security properties for both peers 👑
8.7. Residual Threats 🌈
okay real talk, even with all the security mechanisms above, there are still some leftover threats 🥺 The main ones are three kinds of on-path attack, weaknesses from certain limited ways of using TLS, and bugs in implementations 😬
First up, an on-path attacker who can catch the initial Query can pretty much do whatever they want to the signalling that comes after 💀 Stopping this at the GIST level is really hard 😭 The only real defence is strong messaging association security, which lets you check whether the Responding node is actually allowed to take part in NSLP signalling exchanges 🔐 The annoying part is that this behaviour can look exactly like normal, correct operation, so it's super easy to see why defending against it is so tough 🙈 And an on-path attacker like this can mess with the traffic too, not just the signalling 😳 So the extra threat from the signalling weakness seems tolerable, ngl 🫠
Next, at the NSLP level, there's a worry about trust being passed along the chain 🔗 The NSLP on the querying node can be pretty confident it's talking to an on-path peer, or to a node that an on-path node delegated to, because GIST's security protection covers that 🦋 BUT it has no way of knowing that the node past the responder is also on-path, or that the MRI (especially) hasn't been changed by the responder to point at a different flow 😱 So if it sends signalling messages carrying payloads that are valuable to nodes beyond the next hop (like authorisation tokens), the NSLP itself has to make sure a proper chain of trust is in place 💖 One way to do that is higher layer security protection, such as Cryptographic Message Syntax (CMS) [28] 🎀
There's also a further residual attack from a node that isn't on the path of the Query but is on the path of the Response, or that can use a Response from one handshake to mess with a different handshake 👀 The attacker changes the Response so the Querying node forms an adjacency with them instead of the real peer 😭 In theory, this could be stopped by adding another cryptographic object to the Response, one that ties it to the initial Query and the routing state and that the Querying node can verify ✨
GIST relies on TLS for peer node authentication and for protecting the channel afterwards 🔐 The analysis in [30] shows the threats that come up when peer node authentication is incomplete, specifically when only unilateral authentication happens (one node authenticates the other, but not the reverse) 😬 In this specification, mutual authentication can be supported either through certificate exchange or with pre-shared keys (see Section 5.7.3) 🔑 If some other TLS authentication mechanism gets negotiated, its properties would need to be analysed to see whether they're acceptable for GIST 🧐 And if mutual authentication happens, the requirements for NTLP security are met 💜
BUT, with certificate exchange, this specification allows for only a server certificate to be provided 😭 That means the Querying node authenticates the Responding node, but not the other way around 🙃 Accepting that kind of unilateral authentication does give partial security in environments where client certificates aren't common, and it's way better than no security at all 🌸 However, it does expose the Responding node to certain threats described in Section 3.1 of [30] 💀 For example, the Responding node can't check whether there's a man in the middle between it and the Querying node who might be messing with the signalling messages 👀 It also can't verify who the Querying node is if that node asks for authorisation of resources 😱 And for host-network signalling, the Responding node could be either the host or the first hop router, depending on which direction the signalling goes 🧚 Because of these vulnerabilities, TLS modes or deployments that don't provide mutual authentication can be seen as, at best, transitional stages, not a robust security solution 🥀
Last one! Certain security aspects of GIST operation depend on how the signalling application behaves 🙃 A poorly implemented or compromised NSLP could weaken GIST security 😬 But that degradation would only affect how GIST handles that NSLP's own signalling traffic, or the overall resource usage at the node where the weakness happened 🫤 And honestly, an implementation weakness or compromise could have just as big an effect inside the NSLP itself 💅 GIST also depends on NSLPs choosing SIDs properly (Section 4.1.3) 🍓 If NSLPs pick non-random SIDs, off-path attacks based on guessing SIDs become easier to pull off 😭 NSLPs can also leak information through structured SIDs, but they could leak similar information in the NSLP payload data anyway 🙈 So yeah, it's a whole mood, but these are the threats we're still watching out for 👑
9. IANA Considerations ✨
okay so this section is where GIST sets up its registries 📋 and the codepoints that go in them, plus the rules IANA has to follow when handing out new ones 🫶. the technical criteria for evaluating new codepoint requests are covered normatively in a separate document that looks at the whole NSIS protocol suite together, so if you want the deeper reasoning on NSIS extensibility, go check [12] 📚.
the registry definitions below leave big blocks of codes marked "Reserved" 🦋. that's on purpose! it lets a future revision of this spec, or another Experimental document, reshuffle how much space each allocation policy gets, without having to retroactively change the initial rules if they turn out to be a bad call. like, if one policy's space gets used up way too fast, there's room to adjust 💅.
the allocation policies in this section follow the guidance in [4] 🌸. on top of that, a bunch of the GIST registries also define private/experimental ranges, as discussed in [9] 🧪. just know that those codepoints can only be used validly in a closed environment where the experimenter knows about every experiment in progress. outside that, no bestie, don't use them 🙈.
This specification allocates the following codepoints in existing registries:
- Well-known UDP port
270as the destination port for Q-mode encapsulated GIST messages (Section 5.3) 🎀
This specification creates the following registries with the structures as defined below:
NSLP Identifiers: each signalling application needs one or more NSLPIDs 🍓. this spec allocates the following one:
+---------+---------------------------------------------------------+
| NSLPID | Application |
+---------+---------------------------------------------------------+
| 0 | Used for GIST messages not related to any signalling |
| | application. |
+---------+---------------------------------------------------------+ok so, every other NSLPID that uses an MRM that requires RAO usage MUST be associated with a specific RAO value 👑. multiple NSLPIDs MAY be associated with the same RAO value, so they can share one. RAO value assignments require a specification of the processing for messages that carry the value ✨. NSLP specifications MUST normatively depend on this document for that processing, specifically Sections 4.3.1, 4.3.4 and 5.3.2. the NSLPID is a 16-bit integer, and the registration procedure is IESG Aproval. the values go like this:
1-32703: Unassigned32704-32767: Private/Experimental Use32768-65536: Reserved
GIST Message Type: the GIST common header (Appendix A.1) has a 7-bit message type field 💜. this spec allocates these values:
+---------+----------+
| MType | Message |
+---------+----------+
| 0 | Query |
| | |
| 1 | Response |
| | |
| 2 | Confirm |
| | |
| 3 | Data |
| | |
| 4 | Error |
| | |
| 5 | MA-Hello |
+---------+----------+registration procedures are:
0-31: IETF Review32-55: Expert Review
and the rest:
6-55: Unassigned56-63: Private/Experimental Use64-127: Reserved
Object Types: there's a 12-bit field in the object header (Appendix A.2) 🧚. these are the object type values this spec defines:
+---------+-----------------------------+
| OType | Object Type |
+---------+-----------------------------+
| 0 | Message Routing Information |
| | |
| 1 | Session ID |
| | |
| 2 | Network Layer Information |
| | |
| 3 | Stack Proposal |
| | |
| 4 | Stack Configuration Data |
| | |
| 5 | Query-Cookie |
| | |
| 6 | Responder-Cookie |
| | |
| 7 | NAT Traversal |
| | |
| 8 | NSLP Data |
| | |
| 9 | Error |
| | |
| 10 | Hello ID |
+---------+-----------------------------+registration procedures:
0-1023: IETF Review1024-1999: Specification Required
and the rest:
11-1999: Unassigned2000-2047: Private/Experimental Use2048-4095: Reserved
when a new object type gets allocated under one of these procedures, the specification MUST provide the object format and define the setting of the extensibility bits (A/B; see Appendix A.2.1). no skipping this part!! 🙅♀️
Message Routing Methods: GIST allows multiple message routing methods (see Section 3.3) 🦋. the MRM is indicated in the leading byte of the MRI object (Appendix A.3.1). this spec defines:
+------------+------------------------+
| MRM-ID | Message Routing Method |
+------------+------------------------+
| 0 | Path-Coupled MRM |
| | |
| 1 | Loose-End MRM |
+------------+------------------------+registration procedures:
0-63: IETF Review64-119: Specification Required
and the rest:
2-119: Unassigned120-127: Private/Experimental Use128-255: Reserved
when a new MRM is allocated under one of the registration procedures, the specification MUST provide the information described in Section 3.3 📝.
MA-Protocol-IDs: each protocol that can be used in a messaging association is identified by a 1-byte MA-Protocol-ID (Section 5.7) 💖. note that the MA-Protocol-ID is not an IP protocol number! some messaging association protocols, like TLS, don't even have an IP protocol number, so that's a whole vibe check 🙈. it's used as a tag in the Stack-Proposal and Stack-Configuration-Data objects (Appendix A.3.4 and Appendix A.3.5). this spec defines:
+---------------------+-----------------------------------------+
| MA-Protocol-ID | Protocol |
+---------------------+-----------------------------------------+
| 0 | Reserved |
| | |
| 1 | TCP opened in the forwards direction |
| | |
| 2 | TLS initiated in the forwards direction |
+---------------------+-----------------------------------------+registration procedures:
0-63: IETF Review64-119: Expert Review
and the rest:
3-119: Unassigned120-127: Private/Experimental Use128-255: Reserved
when a new MA-Protocol-ID is allocated under one of the registration procedures, a specification document will be required 📚. it MUST define the format for the MA-protocol-options field (if any) in the Stack-Configuration-Data object that's needed to configure it. if a protocol is going to be used for reliable message transfer, it MUST be described how GIST detects delivery errors 🚨. extensions that add new channel security protocols MUST include a description of how to integrate the functionality described in Section 3.9 with the rest of GIST operation 🔐. and if the new MA-Protocol-ID can be used alongside existing ones (say, a new transport protocol that could be used with Transport Layer Security), the specification MUST define the interaction between the two 🫶.
Error Codes/Subcodes: there's a 2-byte error code and a 1-byte subcode in the Value field of the Error Object (Appendix A.4.1) 💀. error codes 1-12 are defined in Appendix A.4.4, together with subcodes 0-5 (code 1), 0-5 (code 9), 0-5 (code 10), and 0-2 (code 12). extra codes and subcodes get handed out first-come, first-served ✨. when a new code/subcode combo is allocated, the following information MUST be provided:
- Error case: textual name of error
- Error class: from the categories given in Appendix A.4.3
- Error code: allocated by IANA, if a new code is required
- Error subcode: subcode point, also allocated by IANA
- Additional information: which Additional Information fields are mandatory to include in the error message, from Appendix A.4.2
Additional Information Types: an Error Object (Appendix A.4.1) can contain Additional Information fields 🌈. each possible field type is identified by a 16-bit AI-Type. AI-Types 1-4 are defined in Appendix A.4.2, and additional AI-Types are allocated first-come, first-served 💅.
10. Acknowledgements ✨
This doc is based on all the discussions in the IETF NSIS working group 🫶 It also got a ton of help from prior work and from formal and informal input by Cedric Aoun, Attila Bader, Vitor Bernado, Roland Bless, Bob Braden, Marcus Brunner, Benoit Campedel, Yoshiko Chong, Luis Cordeiro, Elwyn Davies, Michel Diaz, Christian Dickmann, Pasi Eronen, Alan Ford, Xiaoming Fu, Bo Gao, Ruediger Geib, Eleanor Hepworth, Thomas Herzog, Cheng Hong, Teemu Huovila, Jia Jia, Cornelia Kappler, Georgios Karagiannis, Ruud Klaver, Max Laier, Chris Lang, Lauri Liuhto, John Loughney, Allison Mankin, Jukka Manner, Pete McCann, Andrew McDonald, Mac McTiffin, Glenn Morrow, Dave Oran, Andreas Pashalidis, Henning Peters, Tom Phelan, Akbar Rahman, Takako Sanda, Charles Shen, Melinda Shore, Martin Stiemerling, Martijn Swanink, Mike Thomas, Hannes Tschofenig, Sven van den Bosch, Nuutti Varis, Michael Welzl, Lars Westberg, and Mayi Zoumaro-djayoon 💜
Bits of the TLS usage description (Section 5.7.3) were borrowed from the Diameter base protocol spec, RFC 3588 📚 Hannes Tschofenig gave a super detailed set of review comments on the security section 🔒, and Andrew McDonald wrote the formal description for the initial packet formats and the name matching algorithm for TLS 🙌
Chris Lang's implementation work gave really honest feedback on whether the spec was clear and actually doable 🛠️ He also wrote the state machine description and the first error catalogue and formats, which is so iconic 👑 Magnus Westerlund did a detailed AD review that caught a bunch of issues and led to major clarifications 🌸 That was followed by an even more detailed IESG review, with comments from Jari Arkko, Ross Callon, Brian Carpenter, Lisa Dusseault, Lars Eggert, Ted Hardie, Sam Hartman, Russ Housley, Cullen Jennings, and Tim Polk, plus a very detailed analysis by Adrian Farrel from the Routing Area directorate 🦋 And Suresh Krishnan did a detailed review for the Gen-ART 💖
11. References 🌈
11.1. Normative References
- [1] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
- [2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [6] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
- [7] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
- [8] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
- [9] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
- [10] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
- [11] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
- [12] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010.
11.2. Informative References
- [13] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
- [14] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
- [15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
- [16] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
- [17] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
- [18] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
- [19] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
- [20] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
- [21] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
- [22] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
- [23] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
- [24] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
- [25] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003.
- [26] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
- [27] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
- [28] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
- [29] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
- [30] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
- [31] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
- [32] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
- [33] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
- [34] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, April 2010.
- [35] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
- [36] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [37] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
- [38] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
- [39] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
- [40] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
- [41] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
- [42] Floyd, S. and V. Jacobson, "The Synchronisation of Periodic Routing Messages", SIGCOMM Symposium on Communications Architectures and Protocols pp. 33--44, September 1993.
- [43] Pashalidis, A. and H. Tschofenig, "GIST Legacy NAT Traversal", Work in Progress, July 2007.
- [44] Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal", Work in Progress, July 2007.
- [45] Tsenov, T., Tschofenig, H., Fu, X., Aoun, C., and E. Davies, "GIST State Machine", Work in Progress, April 2010.
- [46] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", Work in Progress, May 2010.
Appendix A. Bit-Level Formats and Error Messages 🧚
This appendix gives the formats for the different component parts of the GIST messages that Section 5.2 describes abstractly 💅 The whole thing is normative, so no skipping!
Each GIST message is a header plus a sequence of objects 🍓 The GIST header has its own specific format, which gets more detail in Appendix A.1 below. An NSLP message is just one object inside a GIST message. GIST itself handles the NSLP message length info and the signalling application identification, so that's covered 🫶 General object formatting guidelines are in Appendix A.2 below, then Appendix A.3 has the format for each object, and Appendix A.4 covers the formats used for error reporting ✨
In the object diagrams that follow, // marks a variable-sized field and : marks a field that is optionally present 🦋 Any part of an object that's used for padding or defined as reserved (marked Reserved or Rsv or, for individual bits, r in the diagrams) MUST be set to 0 on transmission and MUST be ignored on reception 🔒 That's a big one, bestie!
The objects are encoded using big endian, which is also called network byte order 🌸
A.1. The GIST Common Header ✨
okay so this header starts every GIST message, bestie 💅 it has a fixed format, and it looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | GIST hops | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSLPID |C| Type |S|R|E| Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version (8 bits): the GIST protocol version number. This specification defines version number 1 🎀
GIST hops (8 bits): a hop count for the number of GIST-aware nodes this message can still be processed by (including the destination) 🦋
Message Length (16 bits): the total number of 32-bit words in the message after the common header itself 📏
NSLPID (16 bits): the IANA-assigned identifier of the signalling application that the message refers to 💜
C-flag: C=1 if the message has to be able to be interpreted in the absence of routing state (Section 5.2.1) 🧚
Type (7 bits): the GIST message type (Query, Response, etc.) ✨
S-flag: S=1 if the IP source address is the same as the signalling source address, S=0 if it is different 🌸
R-flag: R=1 if a reply to this message is explicitly requested 🔥
E-flag: E=1 if the message was explicitly routed (Section 7.1.5) 👑
Okay, the R-flag rules are where it gets spicy, so pay attention 🙈 They depend on the GIST message type. It MUST always be set (R=1) in Query messages, since those always elicit a Response, and it MUST NOT be set in Confirm, Data, or Error messages. It MAY be set in an MA-Hello; if it is set, another MA-Hello MUST be sent in reply. It MAY be set in a Response, but it MUST be set if the Response contains a Responder-Cookie; if it is set, a Confirm MUST be sent in reply. The E-flag MUST NOT be set unless the message type is a Data message.
Parsing failures can be caused by unknown Version or Type values, by inconsistent setting of the C-flag, R-flag, or E-flag, or by a Message Length that doesn't match the set of objects carried. In every case, the receiver MUST, if possible, return a "Common Header Parse Error" message (Appendix A.4.4.1) with the appropriate subcode, and it must not process the message any further 😭
A.2. General Object Format
every object starts with a fixed header that gives its object Type and object Length. After that comes the object Value, which is a whole number of 32-bit words long 🧁
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A/B flags: the bits marked 'A' and 'B' are extensibility flags, which are defined in Appendix A.2.1 below. The remaining bits marked 'r' are reserved 🔒
Type (12 bits): an IANA-assigned identifier for the type of object 🎀
Length (12 bits): Length has units of 32-bit words and measures the length of Value. If there is no Value, Length=0. If the Length is not consistent with the contents of the object, an "Object Value Error" message (Appendix A.4.4.10) with subcode 0 "Incorrect Length" MUST be returned and the message dropped. Not consistent = not vibing = dropped 💀
Value (variable): Value is (therefore) a whole number of 32-bit words. If any padding is required, the length and location are be defined by the object-specific format information. Objects that contain variable-length (e.g., string) types may need to include additional length subfields to do so 🦋
A.2.1. Object Extensibility
the leading 2 bits of the TLV header are used to signal the desired treatment for objects whose Type field is unknown at the receiver. There are three categories of objects, and here they are 🌈
AB=00 ("Mandatory"): If the object is not understood, the entire message containing it MUST be rejected with an "Object Type Error" message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object") 🚫
AB=01 ("Ignore"): If the object is not understood, it MUST be deleted and the rest of the message processed as usual 🗑️
AB=10 ("Forward"): If the object is not understood, it MUST be retained unchanged in any message forwarded as a result of message processing, but not stored locally 📦
The combination AB=11 is reserved. If a message is received containing an object with AB=11, it MUST be rejected with an "Object Type Error" message (Appendix A.4.4.9) with subcode 5 ("Invalid Extensibility Flags") ⛔
These extensibility rules only define processing within the GIST layer. GIST implementations don't have to support an extensible service interface to signalling applications, so unrecognised objects with AB=01 or AB=10 do not need to be indicated to NSLPs 🫶
A.3. GIST TLV Objects
A.3.1. Message-Routing-Information (MRI)
Type: Message-Routing-Information 🗺️
Length: Variable (depends on MRM)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRM-ID |N| Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
// Method-specific addressing information (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+MRM-ID (8 bits): an IANA-assigned identifier for the message routing method 🧭
N-flag: if set (N=1), NATs do not need to translate this MRM. If clear (N=0), the method-specific information contains network or transport layer information that a NAT must process 🌐
The rest of the object holds method-specific addressing information, which is described below 🍓
A.3.1.1. Path-Coupled MRM
For basic path-coupled routing, the addressing information takes the following format. The N-flag has a value of 0 for this MRM 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IP-Ver |P|T|F|S|A|B|D|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Source Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Destination Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Prefix | Dest Prefix | Protocol | DS-field |Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Reserved | Flow Label :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SPI :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Source Port : Destination Port :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IP-Ver (4 bits): the IP version number, 4 or 6 🌍
Source/Destination address (variable): the source and destination addresses are always present and of the same type. Their length depends on the value in the IP-Ver field 📍
Source/Dest Prefix (each 8 bits): the length of the mask to be applied to the source and destination addresses for address wildcarding. In the normal case where the MRI refers only to traffic between specific host addresses, the Source/Dest Prefix values would both be 32 or 128 for IPv4 and IPv6, respectively 🎯
P-flag: P=1 means that the Protocol field is significant 🔑
Protocol (8 bits): the IP protocol number. This MUST be ignored if P=0. For IPv6, the Protocol field refers to the true upper layer protocol carried by the packets, i.e., excluding any IP option headers. This is therefore not necessarily the same as the Next Header value from the base IPv6 header 🧠
T-flag: T=1 means that the Diffserv field (DS-field) is significant 💅
DS-field (6 bits): the Diffserv field. See [6] and [24] ✨
F-flag: F=1 means that the flow label is present and is significant. F MUST NOT be set if IP-Ver is not 6 🌊
Flow Label (20 bits): the flow label. It is only present if F=1. If F=0, the entire 32-bit word containing the Flow Label is absent 🪄
S-flag: S=1 means that the SPI field is present and is significant. The S-flag MUST be 0 if the P-flag is 0 🔐
SPI field (32 bits): the SPI field. See [36]. If S=0, the entire 32-bit word containing the SPI is absent 🗝️
A/B flags: these can only be set if P=1. If either is set, the port fields are also present. The A flag indicates the presence of a source port, and the B flag indicates a destination port. If P=0, the A/B flags MUST both be zero and the word containing the port numbers is absent 🚪
Source/Destination Port (each 16 bits): if either A (source) or B (destination) is set, the word containing the port numbers is included in the object. The contents of each field only matter if the corresponding flag is set. Otherwise, the contents of the field are regarded as padding, and the MRI refers to all ports (i.e., acts as a wildcard) 🃏 If the flag is set and Port=0x0000, the MRI applies to a specific port whose value is not yet known. If neither A nor B is set, the word is absent 🫧
D-flag: the Direction flag has the following meaning. The value 0 means 'in the same direction as the flow' (i.e., downstream), and the value 1 means 'in the opposite direction to the flow' (i.e., upstream) ↕️
The MRI format defines a number of constraints on the allowed combinations of flags and fields in the object. If these constraints are violated, that's a parse error, and an "Object Value Error" message (Appendix A.4.4.10) with subcode 2 ("Invalid Flag-Field Combination") MUST be returned 🚨
A.3.1.2. Loose-End MRM 🦋
okay so the loose-end MRM is giving addressing info in a totally different shape, bestie 💅 and the N-flag has a value of 0 for this one, so keep that in mind ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IP-Ver |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Source Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Destination Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the breakdown 🌸
- IP-Ver (4 bits): The IP version number, 4 or 6.
- Source/Destination address (variable): The source and destination addresses are always present and of the same type. Their length depends on the value in the IP-Ver field.
- D-flag: The Direction flag means the value 0 is 'towards the edge of the network', and the value 1 is 'from the edge of the network' 🧚 Note that for Q-mode messages, the only valid value is D=0 (see Section 5.8.2).
A.3.2. Session Identifier 🌈
okay, this one is so simple it's iconic 💖
- Type: Session-Identifier
- Length: Fixed (4 32-bit words)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A.3.3. Network-Layer-Information (NLI) 💜
this one is a whole vibe, the length depends on the Peer-Identity and the IP version 🎀
- Type: Network-Layer-Information
- Length: Variable (depends on length of Peer-Identity and IP version)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PI-Length | IP-TTL |IP-Ver | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing State Validity Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer Identity //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Interface Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The fields, bestie 🧚
- PI-Length (8 bits): The byte length of the Peer Identity field.
- Peer Identity (variable): The Peer Identity field. Note that the Peer-Identity field itself is padded to a whole number of words.
- IP-TTL (8 bits): Initial or reported IP layer TTL.
- IP-Ver (4 bits): The IP version for the Interface Address field.
- Interface Address (variable): The IP address allocated to the interface, matching the IP-Ver field.
- Routing State Validity Time (32 bits): The time for which the routing state for this flow can be considered correct without a refresh. Given in milliseconds. The value 0 (zero) is reserved and MUST NOT be used. 🚫
A.3.4. Stack-Proposal 🍓
the Stack-Proposal is literally a menu of profiles, and the count rules are strict, so pay attention 👑
- Type: Stack-Proposal
- Length: Variable (depends on number of profiles and size of each profile)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prof-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Prof-Count (8 bits): The number of profiles listed. MUST be > 0.
Each profile is itself a sequence of protocol layers, and the profile is formatted as a list like this 🌸
- The first byte is a count of the number of layers in the profile. MUST be > 0.
- This is followed by a sequence of 1-byte MA-Protocol-IDs as described in Section 5.7.
- The profile is padded to a word boundary with 0, 1, 2, or 3 zero bytes. These bytes MUST be ignored at the receiver.
If there are no profiles (Prof-Count=0), then an "Object Value Error" message (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") MUST be returned. If a particular profile is empty (the leading byte of the profile is zero), then subcode 3 ("Empty List") MUST be used. In both cases, the message MUST be dropped. 💀
A.3.5. Stack-Configuration-Data 🎀
this one's the config drop, and the MPO-Count is a bit of a plot twist 🙈
- Type: Stack-Configuration-Data
- Length: Variable (depends on number of protocols and size of each MA-protocol-options field)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPO-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MA-Hold-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// MA-protocol-options 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// MA-protocol-options N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- MPO-Count (8 bits): The number of MA-protocol-options fields present (these contain their own length information). The MPO-Count MAY be zero, but this will only be the case if none of the MA-protocols referred to in the Stack-Proposal require option data.
- MA-Hold-Time (32 bits): The time for which the messaging association will be held open without traffic or a hello message. Note that this value is given in milliseconds, so the default time of 30 seconds (Section 4.4.5) corresponds to a value of 30000. The value 0 (zero) is reserved and MUST NOT be used.
The MA-protocol-options fields are formatted like this ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MA-Protocol-ID | Profile | Length |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Options Data //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- MA-Protocol-ID (8 bits): Protocol identifier as described in Section 5.7.
- Profile (8 bits): Tag indicating which profile from the accompanying Stack-Proposal object this applies to. Profiles are numbered from 1 upwards; the special value 0 indicates 'applies to all profiles'.
- Length (8 bits): The byte length of MA-protocol-options field that follows. This will be zero-padded up to the next word boundary.
- D-flag: If set (D=1), this protocol MUST NOT be used for a messaging association.
- Options Data (variable): Any options data for this protocol. Note that the format of the options data might differ depending on whether the field is in a Query or Response.
A.3.6. Query-Cookie 🧁
this cookie is the Query one, and it's basically a mystery box 🍪
- Type: Query-Cookie
- Length: Variable (selected by Querying node)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Query-Cookie //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The content is defined by the implementation. See Section 8.5 for further discussion. 🦋
A.3.7. Responder-Cookie 🌸
the Responder version of the cookie, same energy, different side of the convo 💜
- Type: Responder-Cookie
- Length: Variable (selected by Responding node)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Responder-Cookie //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The content is defined by the implementation. See Section 8.5 for further discussion. 🫶
A.3.8. Hello-ID 🧚
last one in this chunk, and it's a short and sweet one 🍓
- Type: Hello-ID
- Length: Fixed (1 32-bit word)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hello-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The content is defined by the implementation. See Section 5.2.2 for further discussion. ✨
A.3.9. NAT-Traversal 🦋
Okay bestie, this one is the NAT-Traversal object 🌸 It's how GIST carries the NAT traversal stuff from Section 7.2.2 along for the ride.
- Type:
NAT-Traversal - Length: Variable (depends on length of contained fields)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRI-Length | Type-Count | NAT-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Original Message-Routing-Information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// List of translated objects //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of opaque information | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ //
// Information replaced by NAT #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of opaque information | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ //
// Information replaced by NAT #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the field rundown 💅
MRI-Length(8 bits): The length of the included MRI payload in 32-bit words.Original Message-Routing-Information(variable): The MRI data from when the message was first sent, not including the object header.Type-Count(8 bits): The number of objects in the 'List of translated objects' field.List of translated objects(variable): This field lists the types of objects that were translated by every NAT through which the message has passed. Each element in the list is a 16-bit field containing the first 16 bits of the object TLV header, including the AB extensibility flags, 2 reserved bits, and 12-bit object type. The list is initialised by the first NAT on the path; subsequent NATs may delete elements in the list. Padded with 2 null bytes if necessary.NAT-Count(8 bits): The number of NATs traversed by the message, and the number of opaque payloads at the end of the object. The length fields for each opaque payload are byte counts, not including the 2 bytes of the length field itself. Note that each opaque information field is zero-padded to the next 32-bit word boundary if necessary.
A.3.10. NSLP-Data 🧚
Next up is NSLP-Data, the object that moves data between NSLPs 🫶 GIST treats the data as a bunch of complete 32-bit words, based on the length field in the TLV. Any padding to a word boundary must be carried out within the NSLP itself, so that's on the NSLP, not GIST 💖
- Type:
NSLP-Data - Length: Variable (depends on NSLP)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NSLP Data //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A.4. Errors 🚨
Now we're in the error zone 😭 Errors are where things get a little dramatic, but it's all very organised.
A.4.1. Error Object 💀
- Type:
Error - Length: Variable (depends on error)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Class | Error Code | Error Subcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|M|C|D|Q| Reserved | MRI Length | Info Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Common Header +
| (of original message) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Session ID :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Message Routing Information :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Additional Information Fields :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Debugging Comment :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The flags are:
S: S=1 means the Session ID object is present.M: M=1 means MRI object is present.C: C=1 means a debug Comment is present after header.D: D=1 means the original message was received in D-mode.Q: Q=1 means the original message was received Q-mode encapsulated (can't be set if D=0).
A GIST Error Object holds an 8-bit error-class (see Appendix A.4.3), a 16-bit error-code, an 8-bit error-subcode, and as much info about the message that triggered the error as is available. This information MUST include the common header of the original message and MUST also include the Session ID and MRI objects if these could be decoded correctly. These objects are included in their entirety, except for their TLV Headers. The MRI Length field gives the length of the MRI object in 32-bit words.
The Info Count field contains the number of Additional Information fields in the object, and the possible formats for these fields are given in Appendix A.4.2. The precise set of fields to include depends on the error code/subcode. For every error description in the error catalogue Appendix A.4.4, the line "Additional Info:" states what fields MUST be included; further fields beyond these MAY be included by the sender, and the fields may be included in any order. The Debugging Comment is a null-terminated UTF-8 string, padded if necessary to a whole number of 32-bit words with more null characters.
A.4.2. Additional Information Fields (AI) 🎀
The Common Error Header may be followed by some Additional Information fields. Each one has a simple TLV format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AI-Type | AI-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// AI-Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The AI-Type is a 16-bit IANA-assigned value. The AI-Length gives the number of 32-bit words in AI-Value; if an AI-Value is not present, AI-Length=0. The AI-Types, AI-Lengths and AI-Value formats of the currently defined Additional Information fields are shown below.
Message Length Info 📏
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calculated Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AI-Type: 1
AI-Length: 1Calculated Length (16 bits): the length of the original message calculated by adding up all the objects in the message. Measured in 32-bit words.
MTU Info 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link MTU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AI-Type: 2
AI-Length: 1Link MTU (16 bits): the IP MTU for a link along which a message could not be sent. Measured in bytes.
Object Type Info 🍓
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AI-Type: 3
AI-Length: 1Object type (16 bits): This provides information about the type of object that caused the error.
Object Value Info 🔍
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv | Real Object Length | Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Object //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AI-Type: 4
AI-Length: variable (depends on object length)This object carries information about a TLV object that was found to be invalid in the original message. An error message MAY contain more than one Object Value Info object.
Real Object Length(12 bits): Since the length in the original TLV header may be inaccurate, this field provides the actual length of the object (including the TLV header) included in the error message. Measured in 32-bit words.Offset(16 bits): The byte in the object at which the GIST node found the error. The first byte in the object has offset=0.Object(variable): The invalid TLV object (including the TLV header).
A.4.3. Error Classes 🌟
The first byte of the Error Object, "Error Class", indicates the severity level. The currently defined severity levels are:
0(Informational): reply data that should not be thought of as changing the condition of the protocol state machine.1(Success): reply data that indicates that the message being responded to has been processed successfully in some sense.2(Protocol-Error): the message has been rejected because of a protocol error (e.g., an error in message format).3(Transient-Failure): the message has been rejected because of a particular local node status that may be transient (i.e., it may be worthwhile to retry after some delay).4(Permanent-Failure): the message has been rejected because of local node status that will not change without additional out-of-band (e.g., management) operations.
Additional error class values are reserved.
The allocation of error classes to particular errors is not precise; the above descriptions are deliberately informal. Actual error processing SHOULD take into account the specific error in question; the error class may be useful supporting information (e.g., in network debugging).
A.4.4. Error Catalogue 📚
This section lists all the possible GIST errors, including when they are raised and what Additional Information fields MUST be carried in the Error Object.
A.4.4.1. Common Header Parse Error
Class: Protocol-Error Code: 1 Additional Info: For subcode 3 only, Message Length Info carries the calculated message length.
okay so this one is for when a GIST node gets a message whose common header can't be parsed properly, or when the overall message format is just busted 💀. and bestie, in this case the original MRI and Session ID MUST NOT be included in the Error Object 🙅♀️ no exceptions, no cap. this error code is split into subcodes, so let's go:
- 0: Unknown Version 🎀: the GIST version is unknown. the (highest) supported version the node can handle can be inferred from the common header of the Error message itself ✨
- 1: Unknown Type 🦋: the GIST message type is unknown.
- 2: Invalid R-flag 🌸: the R-flag in the header doesn't match the message type, which is giving major mismatch energy.
- 3: Incorrect Message Length 🧚: the overall message length doesn't line up with the set of objects carried. this is the one where Message Length Info is actually filled in 🫶
- 4: Invalid E-flag 💜: the E-flag is set in the header, but this isn't a Data message. not it 😭
- 5: Invalid C-flag 🍓: the C-flag was set on something other than a Query message or Q-mode Data message, or it was clear on a Query message. so picky, periodt 💅
A.4.4.2. Hop Limit Exceeded
Class: Permanent-Failure Code: 2 Additional Info: None
okay this one is lowkey tragic 😭. it's sent if a GIST node receives a message with a GIST hop count of zero, or if a node tries to forward a message after its GIST hop count got decremented to zero on reception. it basically means either there's a routing loop going on 🔁 or the initial hop count was way too small 🙈
A.4.4.3. Incorrect Encapsulation
Class: Protocol-Error Code: 3 Additional Info: None
this is sent if a GIST node gets a message using the wrong encapsulation method 🎁 like a Query arriving over an MA, or the Confirm for a handshake that sets up a messaging association showing up in D-mode. wrong vibe, wrong lane 🚫
A.4.4.4. Incorrectly Delivered Message
Class: Protocol-Error Code: 4 Additional Info: None
this one's sent if a GIST node gets a message over an MA that isn't associated with the MRI/NSLPID/SID combination in the message. so it's like, wrong mailbox, bestie 📬💌
A.4.4.5. No Routing State
Class: Protocol-Error Code: 5 Additional Info: None
this is for when a node gets a message for which routing state should exist, but hasn't been created yet, so there's no appropriate Querying-SM or Responding-SM 🫠. it can happen when a Data or Confirm message shows up at a node whose policy says routing state has to exist before those messages get accepted. see also Section 6.1 and Section 6.3 📖✨
A.4.4.6. Unknown NSLPID
Class: Permanent-Failure Code: 6 Additional Info: None
sent if a router gets a directly addressed message for an NSLP it doesn't support. not its vibe 🙅♀️
A.4.4.7. Endpoint Found
Class: Permanent-Failure Code: 7 Additional Info: None
this one's sent if a GIST node sitting at a flow endpoint gets a Query message for an NSLP it doesn't support. found the endpoint, but no NSLP for you, sorry 🧚💅
A.4.4.8. Message Too Large
Class: Permanent-Failure Code: 8 Additional Info: MTU Info
sent if a router gets a message it can't forward because it's bigger than the IP MTU on the next or subsequent hops 📦🚧 too thicc for the road, bestie 🍑
A.4.4.9. Object Type Error
Class: Protocol-Error Code: 9 Additional Info: Object Type Info
this is sent if a GIST node gets a message containing a TLV object with an invalid type. the message tells you which object type is at fault in the additional info field 🕵️♀️ and it's split into subcodes too, obviously:
- 0: Duplicate Object 👯: used if a GIST node gets a message with multiple instances of an object that can only show up once in a message. in the current specification, this applies to all objects, so no doubles, iykyk 🙅♀️
- 1: Unrecognised Object 🫥: used if a GIST node gets an object it doesn't support, and the extensibility flags are AB=00.
- 2: Missing Object 🥺: used if a GIST node gets a message that's missing one or more mandatory objects. this also gets sent if a Stack-Proposal shows up without a matching Stack-Configuration-Data object when one was needed, or vice versa. it's giving "where's my other half" 💔
- 3: Invalid Object Type 🙃: used if the object type is known, but it's not valid for this particular GIST message type. known, just not here 🚪
- 4: Untranslated Object 🗺️: used if the object type is known and is mandatory to interpret, but it has addressing data that an intervening NAT never translated. the NAT forgot to do its job 🙄
- 5: Invalid Extensibility Flags 🌈: used if an object is received with the extensibility flags AB=11. literally the flags said no 💀
A.4.4.10. Object Value Error
Class: Protocol-Error Code: 10 Additional Info: 1 or 2 Object Value Info fields as given below
this is sent if a node gets a message containing an object that can't be properly parsed ✂️. the error message contains a single Object Value Info object, except for subcode 5, which is the exception 👑. subcodes again:
- 0: Incorrect Length 📏: the overall length doesn't match the object length calculated from the object contents. measuring fail 😭
- 1: Value Not Supported 🙅: the value of a field isn't supported by the GIST node. not in the menu, bestie 🍽️
- 2: Invalid Flag-Field Combination 🧩: an object has an invalid combo of flags and/or fields. right now this only relates to the Path-Coupled MRI (Appendix A.3.1.1), but in future there may be more 👀
- 3: Empty List 🫙: right now this only relates to Stack-Proposals. it's sent if a stack proposal with a length > 0 contains only null bytes. (a length of 0 is handled as "Value Not Supported", so that one's already covered 🙅♀️)
- 4: Invalid Cookie 🍪: the message has a cookie the node couldn't verify. that cookie is not it 🚫
- 5: Stack-Proposal - Stack-Configuration-Data Mismatch 🥊: used if a GIST node gets a message where the data in the Stack-Proposal object doesn't match the info in the Stack Configuration Data object. in this case, BOTH the Stack-Proposal object and the Stack-Configuration-Data object MUST be included in separate Object Value Info fields, in that order 📑💖
A.4.4.11. Invalid IP-Layer TTL
Class: Permanent-Failure Code: 11 Additional Info: None
this one's about a message arriving with an IP-layer TTL outside an acceptable range 🧭. like, an upstream Query that came in with an IP-layer TTL less than 254 (aka more than one IP hop away from the sender) 🏃♀️. the actual IP distance can be worked out from the IP-TTL info in the NLI object carried in the same message 🧮✨
A.4.4.12. MRI Validation Failure
Class: Permanent-Failure Code: 12 Additional Info: Object Value Info
this is for when a message comes in with an MRI that can't be accepted, like because there's way too much wildcarding or it fails some validation check (see Section 5.8.1.2) 🙅♀️. the Object Value Info includes the MRI so the error sender can point to the exact part of the MRI that caused the problem 🎯. subcodes:
- 0: MRI Too Wild 🌪️: the MRI had too much wildcarding (like a destination address prefix that's way too short) to be forwarded correctly down a single path 🛣️
- 1: IP Version Mismatch 🆚: the MRI in a path-coupled Query message refers to an IP version that isn't implemented on the interface being used, or it's different from the IP version of the Query encapsulation (see Section 7.4) 🌐
- 2: Ingress Filter Failure 🚧: the MRI in a path-coupled Query message describes a flow that would not pass ingress filtering on the interface used. no entry, bestie 🙅♀️
Appendix B. API between GIST and Signalling Applications
okay this appendix is the abstract API between GIST and signalling applications 🎀. it SHOULD NOT constrain implementers, but rather help clarify the interface between the layers of the NSIS protocol suite. also, even though some data types carry info from GIST information elements, that doesn't mean the format has to match over the API 💅
conceptually, the API has similarities to the sockets API, especially the one for unconnected UDP sockets 🧦. an extension for an API like the one for UDP connected sockets could be considered. in that case, the only info needed in a SendMessage primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle (which can be null) 📨. other info that stayed persistent for a group of messages could be configured once for the socket. those extensions could make a concrete implementation more efficient but don't change the API semantics, so we're not going further into them here 🦋✨
B.1. SendMessage 💌
This primitive goes from a signalling application down to GIST. It's what the app uses whenever it wants to start sending a message. 📨
SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle,
NSLPID, Session-ID, MRI, SII-Handle,
Transfer-Attributes, Timeout, IP-TTL, GIST-Hop-Count )These arguments are mandatory, so they always have to be there: 🎀
- NSLP-Data: the NSLP message itself. 💖
- NSLP-Data-Size: the length of NSLP-Data. 📏
- NSLP-Message-Handle: a handle for this message that GIST can use as a reference in later MessageStatus notifications (Appendix B.3). Those notifications can be about error conditions or about the security attributes that will be used for the message. A NULL handle is allowed if the NSLP doesn't care about those notifications. 🙈
- NSLPID: an identifier saying which NSLP this is. 🧚
- Session-ID: the NSIS session identifier. The assumption here is that the signalling application hands this to GIST, rather than GIST making up a value on its own. 🦋
- MRI: the message routing information GIST uses to work out the correct next GIST hop for this message. The MRI tells you which message routing method to use and which direction the message is going. 🗺️
These arguments are optional: ✨
- SII-Handle: a handle, previously given to the app by GIST, pointing at a data structure that should be used to route the message explicitly to one particular GIST next hop. 🎯
- Transfer-Attributes: attributes that define how the message should be handled (see Section 4.1.2). The following attributes can be considered:
- Reliability: the values are 'unreliable' or 'reliable'. 💪
- Security: this one lets the NSLP say what level of security protection it wants for the message, like 'integrity' or 'confidentiality'. It can also be used to say which authenticated signalling source and destination identities should be used to send the message. The signalling application can find out what's possible from earlier MessageStatus or RecvMessage notifications. If an NSLP-Message-Handle is provided, GIST will tell the app which values it actually picked for this attribute, through a MessageStatus callback. That could happen right away (when GIST is picking from messaging associations that already exist) or later (when a new messaging association has to be made). 🔐
- Local Processing: this one carries hints from the signalling application about what local policy should be applied to the message. The big things are its transmission priority compared to other messages, and whether GIST should try to set up or keep forward routing state. 🚦
- Timeout: how long GIST should keep trying to send this message before it reports an error. ⏳
- IP-TTL: the IP layer TTL value to use when sending this message. GIST is allowed to override it for particular messages. 🔢
- GIST-Hop-Count: the value of the hop count when the message is sent. 🦘
B.2. RecvMessage 📬
This primitive goes from GIST up to a signalling application. GIST uses it whenever it gets a message from the network. That includes null messages (zero-length NSLP payload), which are usually the initial Query messages. For Queries, GIST uses the results of this call to decide whether message routing state should be created (see the discussion of the 'Routing-State-Check' argument below). 🕵️♀️
RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLPID, Session-ID, MRI,
Routing-State-Check, SII-Handle, Transfer-Attributes,
IP-TTL, IP-Distance, GIST-Hop-Count,
Inbound-Interface )- NSLP-Data: the NSLP message itself. It might be empty. 🫙
- NSLP-Data-Size: the length of NSLP-Data. It can be zero. 0️⃣
- NSLPID: an identifier saying which NSLP this message is meant for. 🧚
- Session-ID: the NSIS session identifier. 🦋
- MRI: the message routing information GIST used to forward this message. It implicitly defines which message routing method was used and which direction the message is going, relative to the MRI. 🗺️
- Routing-State-Check: this boolean is True when GIST is asking the signalling application whether routing state should be created with the peer, or whether the message should just be forwarded further (see Section 4.3.2). When it's True, the signalling application should send back these values through the RecvMessage call:
- A boolean saying whether to set up the state. ✅
- Optionally, an NSLP-Payload to carry in the generated Response or the forwarded Query, depending on the case. 📦
This mechanism could be extended so the signalling application can tell GIST whether state installation should happen right away or be deferred (see Section 5.3.3 and Section 6.3 for further discussion). 🌙
- SII-Handle: a handle to a data structure that identifies a peer address and interface. It can be used to spot route changes, and for explicit routing to one particular GIST next hop. 🎯
- Transfer-Attributes: the reliability and security attributes that went with receiving this particular message. On top of the attributes that come with SendMessage, GIST may also say how well the addresses in the MRI were verified. Three attributes can be indicated:
- Whether the signalling source address is one of the flow endpoints (in other words, whether this is the first or last GIST hop). 🏁
- Whether the signalling source address has been validated by a return routability check. 🔁
- Whether the message was explicitly routed, which means GIST hasn't checked that it was delivered in line with local routing state. 🧭
- IP-TTL: the IP layer TTL value the message arrived with, if that's available. ⏱️
- IP-Distance: the number of IP hops from the peer signalling node that sent this message along the path. It's 0 if this information isn't available. 📍
- GIST-Hop-Count: the value of the hop count the message arrived with, after GIST decremented it during its receive-side processing. ➖
- Inbound-Interface: attributes of the interface the message came in on, such as whether it sits on the internal or external side of a NAT. These attributes only have local significance, and the implementation defines them. 🏠
B.3. MessageStatus 🚦
This primitive goes from GIST up to a signalling application. It's there to tell the app either that a message it asked to send couldn't be dispatched, or about the transfer attributes that were picked for the message (specifically the security attributes). If the attributes aren't acceptable, the signalling application can answer this message with a return code to abort sending it. 🛑
MessageStatus ( NSLP-Message-Handle, Transfer-Attributes, Error-Type )- NSLP-Message-Handle: the handle for the message that the signalling application gave in SendMessage. 🎟️
- Transfer-Attributes: the reliability and security attributes that will be used to transmit this particular message. 🔐
- Error-Type: the kind of error that happened, for example, 'no next node found'. 🙅♀️
B.4. NetworkNotification 🌐
This primitive goes from GIST up to a signalling application. It tells the app that a network event that might matter to it has happened. 👀
NetworkNotification ( NSLPID, MRI, Network-Notification-Type )- NSLPID: an identifier saying which NSLP this message is meant for. 🧚
- MRI: the message routing information the network notification applies to. 🗺️
- Network-Notification-Type: the type of event that triggered the notification, along with any extra data attached to it. Five events have been identified: 🔔
- Last Node: GIST has found out that this is the last NSLP-aware node on the path. See Section 4.3.4. 🏁
- Routing Status Change: GIST has installed new routing state, has found out that existing routing state might no longer be valid, or has re-established existing routing state. See Section 7.1.3. The new status gets reported. If the status is Good, the SII-Handle of the peer gets reported too, just like it does for RecvMessage. 🔄
- Route Deletion: GIST has decided that an old route is now definitely invalid, for example because flows are definitely not using it anymore (see Section 7.1.4). The SII-Handle of the peer is reported too. 🗑️
- Node Authorisation Change: the authorisation status of a peer has changed. That means routing state is no longer valid, or a signalling peer is no longer reachable. See Section 4.4.2. 🔑
- Communication Failure: communication with the peer has failed, so messages may have been lost. 📉
B.5. SetStateLifetime ⏰
This primitive goes from a signalling application down to GIST. It says how long the signalling application would like GIST to keep its routing state. It can also hint that the app isn't interested in that state anymore. 🧹
SetStateLifetime ( NSLPID, MRI, SID, State-Lifetime )- NSLPID: the NSLPID that the routing state lifetime applies to. 🧚
- MRI: the message routing information the routing state lifetime applies to. It includes the direction, which is carried in the D-flag. 🧭
- SID: the session ID the signalling application will use with this routing state. It can be wildcarded. 🃏
- State-Lifetime: how long the signalling application wants GIST to keep its routing state. It can be zero, which means the signalling application has no further interest in the GIST state. 0️⃣
B.6. InvalidateRoutingState 💥
This primitive goes from a signalling application down to GIST. It says the app knows that the next signalling hop GIST knows about might not be valid anymore. That could be because the network routing changed, or because the processing capabilities of signalling application nodes changed. See Section 7.1. 🙅♀️
InvalidateRoutingState ( NSLPID, MRI, Status, NSLP-Data,
NSLP-Data-Size, Urgent )- NSLPID: the NSLP that originated the message. It may be null, in which case the invalidation applies to all signalling applications. 🌍
- MRI: the flow whose routing state should be invalidated. It includes the direction of the change, which is carried in the D-flag. 🧭
- Status: the new status the routing state should take on. It's one of Bad or Tentative (see Section 7.1.3). ⚠️
- NSLP-Data, NSLP-Data-Size: (optional) a payload the NSLP provides to be used in the next GIST handshake. This can be part of a conditional peering process (see Section 4.3.2). The payload is sent without any security protection. 🔓
- Urgent: a hint about whether rediscovery should happen right away, or only with the next signalling message. ⏩
Appendix C. Deployment Issues with Router Alert Options 🎀
okay so the GIST peer discovery handshake (Section 4.4.1) depends on routers catching Q-mode encapsulated IP packets (Section 4.3.1 and Section 5.3.2) 🦋 there are two fundamental requirements here, and they're non-negotiable:
- GIST-relevant packets need to get intercepted. 💅
- Packets that aren't relevant to GIST need to get forwarded transparently. 🫶
This spec sets up the GIST behaviour so that both requirements are met for a GIST-capable node ✨ but GIST packets are also going to run into non-GIST nodes, and requirement (2) still applies to those. If non-GIST nodes block Q-mode packets, GIST just won't work 😭 middleboxes can always block specific traffic types, btw. By using a normal UDP encapsulation for Q-mode traffic, GIST at least lets NATs pass these messages (Section 7.2.1), and firewalls can be set up with standard policies. 💖 But when the Q-mode encapsulation uses a Router Alert Option (RAO) at the IP level, this can cause extra problems 💀 and it's a different story for IPv4 vs IPv6.
The IPv4 RAO is defined by [13]. It defines the RAO format with a 2-byte value field, but only one value (zero) is defined, and there's no IANA registry for more allocations 🥲 it says unknown values should be ignored (meaning the packets get forwarded as normal IP traffic). However, it's been reported that some existing implementations just ignore the RAO value completely, so they'll process any packet with an RAO as if the option value was zero. 😳 So you can't rely on non-zero RAO values to make GIST traffic transparent to existing implementations. (Side note: being able to allocate non-zero RAO values for IPv4 could still be valuable 🍓 it makes interception more efficient for nodes that actually check the value field, and it makes no difference to nodes that incorrectly ignore it. Whether non-zero RAO values get used doesn't change how the GIST protocol operates, but it does need to be decided when new NSLPs get registered.)
So the second stage of the analysis is what happens when a non-GIST node that handles RAO sees a Q-mode packet. The RAO spec basically says "Routers that recognize this option shall examine packets carrying it more closely (check the IP Protocol field, for example) to determine whether or not further processing is necessary." 🙄 There are two possible basic behaviours for GIST traffic:
- The "closer examination" is smart enough to realise the node doesn't need to process the packet and should forward it. This could happen because the node was never configured to match IP-Protocol=UDP for RAO packets at all, or because even if UDP traffic gets intercepted, the port numbers don't match anything configured locally. 🧚
- The "closer examination" identifies the packet as UDP and hands it to the UDP stack on the node. Once that happens, there's no guarantee it'll be processed properly 💀 most likely it just gets dropped or rejected with an ICMP error, since there's no GIST process on the destination port to deliver it to.
Open-source operating system source code shows the first type of behaviour, and it's also been seen in direct GIST experiments with commercial routers, including when they process other uses of the RAO (like RSVP). ✨ But other RAO implementations have been reported to do the second thing 😭 which means Q-mode packets get blocked in the network and GIST can't be used. Even though this comes from some subtle details in the RAO processing rules, the end result is the same as if the packet was just blocked for other reasons (for example, lots of IPv4 firewalls drop packets with options by default). 🔥
The GIST spec gives two main options for getting around nodes that block Q-mode traffic in IPv4. Whether to use them is an implementation and configuration choice 💅
- A GIST node can be configured to send Q-mode packets without the RAO at all. This should avoid the problems above, but it should only be done if it's known that nodes on the path to the receiver can intercept such packets. (See Section 5.3.2.1.) 🌸
- If a GIST node can figure out exactly where the packets are getting blocked (e.g., from ICMP messages), or can find some point on the path past the blockage (e.g., with traceroute or by analysing the routing table), it can send the Q-mode messages to that point using IP-in-IP tunnelling without any RAO. This skips the input side processing on the blocking node but picks up normal GIST behaviour beyond it. 🦋
If the blocked Q-mode traffic problem ends up being widespread in real deployments and these techniques aren't enough, there's one more option: define an alternative Q-mode encapsulation that doesn't use UDP. 👑 That would need a specification change. It'd also be restricted to network-internal use, since operating through NATs and firewalls would be way harder with it. 😬
IPv6 is a totally different vibe, since non-zero RAO values are already well established in the specification ([17]) and there's an IANA registry for them 🌈 The main problem is that several implementations are still immature. For example, some treat any RAO-marked packet as if it's for local processing without any further analysis. 🙈 Since that blocks any RAO usage at all in such a network (including the existing standardised ones), it seems reasonable to assume these implementations will get fixed as part of the general rollout of IPv6. ⭐
Appendix D. Example Routing State Table and Handshake 🧚
Figure 11 shows a signalling scenario where one flow is managed by two signalling applications using the path-coupled message routing method. ✨ The flow sender, the receiver, and one router support both applications, and two other routers support one each. The figure also shows the routing state table at node B. 💜
A B C D E
+------+ +-----+ +-----+ +-----+ +--------+
| Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow |
|Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver|
| | +-+ +-+ |GIST | |GIST | |GIST | | |
+------+ +-----+ +-----+ +-----+ +--------+
Flow Direction ------------------------------>>
+------------------------------------+---------+--------+-----------+
| Message Routing Information | Session | NSLPID | Routing |
| | ID | | State |
+------------------------------------+---------+--------+-----------+
| MRM = Path-Coupled; Flow ID = | 0xABCD | NSLP1 | IP-A |
| {IP-A, IP-E, proto/ports}; D=up | | | |
| | | | |
| MRM = Path-Coupled; Flow ID = | 0xABCD | NSLP1 | (null) |
| {IP-A, IP-E, proto/ports}; D=down | | | |
| | | | |
| MRM = Path-Coupled; Flow ID = | 0x1234 | NSLP2 | IP-A |
| {IP-A, IP-E, proto/ports}; D=up | | | |
| | | | |
| MRM = Path-Coupled; Flow ID = | 0x1234 | NSLP2 | Points to |
| {IP-A, IP-E, proto/ports}; D=down | | | B-D MA |
+------------------------------------+---------+--------+-----------+Figure 11: A Signalling Scenario 🎀
The upstream state is just the same address for each application. 🫶 For the downstream direction, NSLP1 only needs D-mode messages, so no explicit routing state towards C is needed. NSLP2 needs a messaging association for its messages towards node D, and node C doesn't process NSLP2 at all, so the peer state for NSLP2 is a pointer to a messaging association that runs directly from B to D. 🔥 E isn't visible in the state table (except implicitly, in the address in the message routing information), because routing state is only stored for adjacent peers. 👀 (On top of the peer identification, IP hop counts are stored for each peer where the state itself is not null. This isn't shown in the table.)
Figure 12 shows a GIST handshake setting up a messaging association for B-D signalling, with Stack Proposals and MA-protocol-options getting exchanged in each direction. 🌈 The Querying node picks TLS/TCP as the stack configuration and sets up the messaging association it'll use to send the Confirm. 💅
-------------------------- Query ---------------------------->
IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST)
D-mode magic number (0x4e04 bda5)
GIST(Header(Type=Query; NSLPID=NSLP2; C=1; R=1; S=0)
MRI(MRM=Path-Coupled; Flow=F; Direction=down)
SessionID(0x1234) NLI(Peer='string1'; IA=IP#B)
QueryCookie(0x139471239471923526)
StackProposal(#Proposals=3;1=TLS/TCP; 2=TLS/SCTP; 3=TCP)
StackConfigurationData(HoldTime=300; #MPO=2;
TCP(Applicable: all; Data: null)
SCTP(Applicable: all; Data: null)))
<---------------------- Response ----------------------------
IP(Src=IP#D; Dst=IP#B); UDP(Src=GIST; Dst=6789)
D-mode magic number (0x4e04 bda5)
GIST(Header(Type=Response; NSLPID=NSLP2; C=0; R=1; S=1)
MRI(MRM=Path-Coupled; Flow=F; Direction=up)
SessionID(0x1234) NLI(Peer='stringr2', IA=IP#D)
QueryCookie(0x139471239471923526)
ResponderCookie(0xacdefedcdfaeeeded)
StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)
StackConfigurationData(HoldTime=200; #MPO=3;
TCP(Applicable: 3; Data: port=6123)
TCP(Applicable: 1; Data: port=5438)
SCTP(Applicable: all; Data: port=3333)))
-------------------------TCP SYN----------------------->
<----------------------TCP SYN/ACK----------------------
-------------------------TCP ACK----------------------->
TCP connect(IP Src=IP#B; IP Dst=IP#D; Src Port=9166; Dst Port=6123)
<-----------------------TLS INIT----------------------->
------------------------ Confirm ---------------------------->
[Sent within messaging association]
GIST(Header(Type=Confirm; NSLPID=NSLP2; C=0; R=0; S=1)
MRI(MRM=Path-Coupled; Flow=F; Direction=down)
SessionID(0x1234) NLI(Peer='string1'; IA=IP#B)
ResponderCookie(0xacdefedcdfaeeeded)
StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)
StackConfigurationData(HoldTime=300))Figure 12: GIST Handshake Message Sequence ✨
Authors' Addresses 🦋
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7042
EMail: hgs+nsis@cs.columbia.edu
URI: http://www.cs.columbia.edu
Robert Hancock
Roke Manor Research
Old Salisbury Lane
Romsey, Hampshire SO51 0ZN
UK
EMail: robert.hancock@roke.co.uk
URI: http://www.roke.co.uk📦 where this page comes from
- ietf: rfc5971 2010-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms