RFC 5971
GIST: General Internet Signalling Transport
Pages: 154
Experimental
Experimental
Part 1 of 6 – Pages 1 to 20
Internet Engineering Task Force (IETF) H. Schulzrinne Request for Comments: 5971 Columbia U. Category: Experimental R. Hancock ISSN: 2070-1721 RMR October 2010 GIST: General Internet Signalling TransportAbstract
This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5971.
Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . 151
1. Introduction
Signalling involves the manipulation of state held in network elements. 'Manipulation' could mean setting up, modifying, and tearing down state; or it could simply mean the monitoring of state that is managed by other mechanisms. This specification concentrates mainly on path-coupled signalling, controlling resources on network elements that are located on the path taken by a particular data flow, possibly including but not limited to the flow endpoints. Examples of state management include network resource reservation, firewall configuration, and state used in active networking; examples of state monitoring are the discovery of instantaneous path properties, such as available bandwidth or cumulative queuing delay. Each of these different uses of signalling is referred to as a signalling application. GIST assumes other mechanisms are responsible for controlling routing within the network, and GIST is not designed to set up or modify paths itself; therefore, it is complementary to protocols like Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [22] or LDP [23] rather than an alternative. There are almost always more than two participants in a path-coupled signalling session, although there is no need for every node on the path to participate; indeed, support for GIST and any signalling applications imposes a performance cost, and deployment for flow-level signalling is much more likely on edge devices than core routers. GIST path-coupled signalling does not directly support multicast flows, but the current GIST design could be extended to do so, especially in environments where the multicast replication points can be made GIST-capable. GIST can also be extended to cover other types of signalling pattern, not related to any end-to-end flow in the network, in which case the distinction between GIST and end-to-end higher-layer signalling will be drawn differently or not at all. Every signalling application requires a set of state management rules, as well as protocol support to exchange messages along the data path. Several aspects of this protocol support are common to all or a large number of signalling applications, and hence can be developed as a common protocol. The NSIS framework given in [29] provides a rationale for a function split between the common and application-specific protocols, and gives outline requirements for the former, the NSIS Transport Layer Protocol (NTLP). Several concepts in the framework are derived from RSVP [14], as are several aspects of the GIST protocol design. The application-specific protocols are referred to as NSIS Signalling Layer Protocols (NSLPs), and are defined in separate documents. The NSIS framework [29] and the accompanying threats document [30] provide important background
information to this specification, including information on how GIST is expected to be used in various network types and what role it is expected to perform. This specification provides a concrete solution for the NTLP. It is based on the use of existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST). GIST does not handle signalling application state itself; in that crucial respect, it differs from higher layer signalling protocols such as SIP, the Real-time Streaming Protocol (RTSP), and the control component of FTP. Instead, GIST manages its own internal state and the configuration of the underlying transport and security protocols to ensure the transfer of signalling messages on behalf of signalling applications in both directions along the flow path. The purpose of GIST is thus to provide the common functionality of node discovery, message routing, and message transport in a way that is simple for multiple signalling applications to re-use. The structure of this specification is as follows. Section 2 defines terminology, and Section 3 gives an informal overview of the protocol design principles and operation. The normative specification is contained mainly in Section 4 to Section 8. Section 4 describes the message sequences and Section 5 their format and contents. Note that the detailed bit formats are given in Appendix A. The protocol operation is captured in the form of state machines in Section 6. Section 7 describes some more advanced protocol features, and security considerations are contained in Section 8. In addition, Appendix B describes an abstract API for the service that GIST provides to signalling applications, and Appendix D provides an example message flow. Parts of the GIST design use packets with IP options to probe the network, that leads to some migration issues in the case of IPv4, and these are discussed in Appendix C. Because of the layered structure of the NSIS protocol suite, protocol extensions to cover a new signalling requirement could be carried out either within GIST, or within the signalling application layer, or both. General guidelines on how to extend different layers of the protocol suite, and in particular when and how it is appropriate to extend GIST, are contained 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].
The terminology used in this specification is defined in this section. The basic entities relevant at the GIST level are shown in Figure 1. In particular, this diagram distinguishes the different address types as being associated with a flow (end-to-end addresses) or 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; a bidirectional communication is considered a pair of unidirectional flows. Session: A single application layer exchange of information for which some state information is to be manipulated or monitored. See Section 3.7 for further detailed discussion. 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, regardless of what
signalling applications it supports.
[Adjacent] Peer: The next node along the signalling path, in the
upstream or downstream direction, with which a GIST node
explicitly interacts.
Querying Node: The GIST node that initiates the handshake process to
discover the adjacent peer.
Responding Node: The GIST node that responds to the handshake,
becoming the adjacent peer to the Querying node.
Datagram Mode (D-mode): A mode 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 previously discovered adjacency information.
Connection Mode (C-mode): A mode of sending GIST messages directly
between nodes using point-to-point messaging associations (see
below). Connection mode allows the re-use of existing transport
and security protocols where such functionality is required.
Messaging Association (MA): A single connection between two
explicitly identified GIST adjacent peers, i.e., 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: signalling messages can be
sent over it in either direction, referring to flows of either
direction.
[Message] Routing: Message routing describes the process of
determining which is the next GIST peer along the signalling path.
For signalling along a flow path, the message routing carried out
by GIST is built on top of normal IP routing, that is, forwarding
packets within the network layer based on their destination IP
address. In this document, the term 'routing' generally refers to
GIST message routing unless particularly specified.
Message Routing Method (MRM): There can be different algorithms for
discovering the route that signalling messages should take. These
are referred to as 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 that
is 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, and protocol and port
numbers. See Section 3.3.
Router Alert Option (RAO): An option that can be included in IPv4
and v6 headers to assist in the packet interception process; see
[13] and [17].
Transfer Attributes: A description of the requirements that 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
The generic requirements identified in the NSIS framework [29] for
transport of signalling messages are essentially two-fold:
Routing: Determine how to reach the adjacent signalling node along
each direction of the data path (the GIST peer), and if necessary
explicitly establish addressing and identity information about
that peer;
Transport: Deliver the signalling information to that peer.
To meet the routing requirement, one possibility is for the node to
use local routing state information to determine the identity of the
GIST peer explicitly. GIST defines a three-way handshake that probes
the network to set up the necessary routing state between adjacent
peers, during which signalling applications can also exchange data.
Once the routing decision has been made, the node has to select a
mechanism for transport of the message to the peer. GIST divides the
transport functionality into two parts, a minimal capability provided
by GIST itself, with the use of well-understood transport protocols
for the harder cases. Here, with details discussed later, the
minimal capability is restricted to messages that are sized well
below the lowest maximum transmission unit (MTU) along a path, are
infrequent enough not to cause concerns about congestion and flow
control, and do not need security protection or guaranteed delivery.
In [29], all of these routing and transport requirements are assigned
to a single notional protocol, the NSIS Transport Layer Protocol
(NTLP). The strategy of splitting the transport problem leads to a
layered structure for the NTLP, with a specialised GIST messaging
layer running over standard transport and security protocols. The basic concept is shown in Figure 2. Note that not every combination of transport and security protocols implied by the figure is actually possible for use in GIST; the actual combinations allowed by this specification are defined in Section 5.7. The figure also shows GIST offering its services to upper layers at an abstract interface, the GIST API, further discussed 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 Transport
3.2. Modes and Messaging Associations
Internally, GIST has two modes of operation: Datagram mode (D-mode): used for small, infrequent messages with modest delay constraints and no security requirements. A special case of D-mode called Query-mode (Q-mode) is used when no routing state exists. Connection mode (C-mode): used for all other signalling traffic. In particular, it can support large messages and channel security and provides congestion control for signalling traffic. C-mode can in principle use any stream or message-oriented transport protocol; this specification defines TCP as the initial choice. It can in principle employ specific network layer security associations, or an internal transport layer security association; this specification defines TLS as the initial choice. When GIST messages are carried in C-mode, they are treated just like any other traffic by intermediate routers between the GIST peers. Indeed, it would be impossible for intermediate routers to carry out any processing on the messages without terminating the transport and security protocols used. D-mode uses UDP, as a suitable NAT-friendly encapsulation that does not require per-message shared state to be maintained between the peers. Long-term evolution of GIST is assumed to preserve the simplicity of the current D-mode design. Any extension to the security or transport capabilities of D-mode can be viewed as the selection of a different protocol stack under the GIST messaging layer; this is then equivalent to defining another option within the overall C-mode framework. This includes both the case of using existing protocols and the specific development of a message exchange and payload encapsulation to support GIST requirements. Alternatively, if any necessary parameters (e.g., a shared secret for use in integrity or confidentiality protection) can be negotiated out-of-band, then the additional functions can be added directly to D-mode by adding an optional object to the message (see Appendix A.2.1). Note that in such an approach, downgrade attacks as discussed in Section 8.6 would need to be prevented by policy at the destination node. It is possible to mix these two modes along a path. This allows, for example, the use of D-mode at the edges of the network and C-mode towards the core. Such combinations may make operation more efficient for mobile endpoints, while allowing shared security associations and transport connections to be used for messages for multiple flows and signalling applications. The setup for these
protocols imposes an initialisation cost for the use of C-mode, but in the long term this cost can be shared over all signalling sessions between peers; once the transport layer state exists, retransmission algorithms can operate much more aggressively than would be possible in a pure D-mode design. It must be understood that the routing and transport functions within GIST are not independent. If the message transfer has requirements that require C-mode, for example, if the message is so large that fragmentation is required, this can only be used between explicitly identified nodes. In such cases, GIST carries out the three-way handshake initially in D-mode to identify the peer and then sets up the necessary connections if they do not already exist. It must also be understood that the signalling application does not make the D-mode/C-mode selection directly; rather, this decision is made by GIST on the basis of the message characteristics and the transfer attributes stated by the application. The distinction is not visible at the GIST service interface. In general, the state associated with C-mode messaging to a particular peer (signalling destination address, protocol and port numbers, internal protocol configuration, and state information) is referred to as a messaging association (MA). MAs are totally internal to GIST (they are not visible to signalling applications). Although GIST may be using an MA to deliver messages about a particular flow, there is no direct correspondence between them: the GIST message routing algorithms consider each message in turn and select an appropriate MA to transport it. There may be any number of MAs between two GIST peers although the usual case is zero or one, and they are set up and torn down by management actions within GIST itself.3.3. Message Routing Methods
The baseline message routing functionality in GIST is that signalling messages follow a route defined by an existing flow in the network, visiting a subset of the nodes through which it passes. This is the appropriate behaviour for application scenarios where the purpose of the signalling is to manipulate resources for that flow. However, there are scenarios for which other behaviours are applicable. Two examples are: Predictive Routing: Here, the intent is to signal along a path that the data flow may follow in the future. Possible cases are pre- installation of state on the backup path that would be used in the event of a link failure, and predictive installation of state on the path that will be used after a mobile node handover.
NAT Address Reservations: This applies to the case where a node
behind a NAT wishes to reserve an address at which it can be
reached by a sender on the other side. This requires a message to
be sent outbound from what will be the flow receiver although no
reverse routing state for the flow yet exists.
Most of the details of GIST operation are independent of the routing
behaviour being used. Therefore, the GIST design encapsulates the
routing-dependent details as a message routing method (MRM), and
allows multiple MRMs to be defined. This specification defines the
path-coupled MRM, corresponding to the baseline functionality
described above, and a second ("Loose-End") MRM for the NAT Address
Reservation case. The detailed specifications are given in
Section 5.8.
The content of an MRM definition is as follows, using the path-
coupled MRM as an example:
o The format of the information that describes the path that 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) and some additional control information.
Specifically, the MRI always includes a flag to distinguish
between the two directions that signalling messages can take,
denoted 'upstream' and 'downstream'.
o A specification of the IP-level encapsulation of the messages
which 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
information is given in Section 5.8.1.2 and Section 5.8.1.3.
Current MRMs rely on the interception of probe messages in the
data plane, but other mechanisms are also possible within the
overall GIST design and would be appropriate for other types of
signalling pattern.
o 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 be dependent 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.
o The mechanism(s) available for route change detection, i.e., any
change in the neighbour relationships that the MRM discovers. The
default case for any MRM is soft-state refresh, but additional
supporting techniques may be possible; see Section 7.1.2.
In addition, it should be noted that NAT traversal may require translation of 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 indicate if some kind of translation is necessary. Development of a new MRM therefore includes updates to the GIST specification, and may include updates to specifications of NAT behaviour. These updates may be done in separate documents as is the case for NAT traversal for the MRMs of the base GIST specification, as described in Section 7.2.3 and [44]. The MRI is passed explicitly between signalling applications and GIST; therefore, signalling application specifications must define which MRMs they require. Signalling applications may use fields in the MRI in their packet classifiers; if they use additional information for packet classification, this would be carried at the NSLP level and so would be invisible to GIST. Any node hosting a particular signalling application needs to use a GIST implementation that supports the corresponding MRMs. The GIST processing rules allow nodes not hosting the signalling application to ignore messages for it at the GIST level, so it does not matter if these 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 invocation of the messaging association protocols used by C-mode, all GIST communication consists of these messages. In addition, all signalling application data is carried as additional payloads in these messages, alongside the GIST information. The Query, Response, and Confirm messages implement the handshake that GIST uses to set up routing state and messaging associations. The handshake is initiated from the Querying node towards the Responding node. The first message is the Query, which is encapsulated in a specific way depending on the message routing method, in order to probe the network infrastructure so that the correct peer will intercept it and become the Responding node. A Query always triggers a Response in the reverse direction as the second message of the handshake. The content of the Response controls whether a Confirm message is sent: as part of the defence against denial-of-service attacks, the Responding node can delay state installation until a return routability check has been performed, and require the Querying node to complete the handshake with the Confirm message. In addition, if the handshake is being used to set up a new MA, the Response is required to request a Confirm. All of these three messages can optionally carry signalling application data. The handshake is fully described in Section 4.4.1.
The Data message is used purely to encapsulate and deliver signalling application data. Usually, it is sent using pre-established routing state. However, if there are no security or transport requirements and no need for persistent reverse routing state, it can also be sent in the same way as the Query. Finally, Error messages are used to indicate error conditions at the GIST level, and the MA-Hello message can be used as a diagnostic and keepalive for the messaging association protocols.3.5. GIST Peering Relationships
Peering is the process whereby 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 from another. Issuing the initial Query is a result of an NSLP request on that node, and the Query itself is formatted according to the rules of the message routing method. For current MRMs, the identity of the Responding node is not known explicitly at the time the Query is sent; instead, the message is examined by nodes along the path until one decides to send a Response, thereby becoming the peer. If the node hosts the NSLP, local GIST and signalling application policy determine whether to peer; the details are given in Section 4.3.2. Nodes not hosting the NSLP forward the Query transparently (Section 4.3.4). Note that the design of the Query message (see Section 5.3.2) is such that nodes have to opt-in specifically to carry out the message interception -- GIST-unaware nodes see the Query as a normal data packet and so 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. As well as network-level rerouting, changes could include modifications to NSIS signalling functions deployed at a node, or alterations to signalling application policy. A change could cause an existing node to drop out of the signalling path, or a new node to become part of it. All these possibilities are handled as rerouting events by GIST; further details of the process are described in Section 7.1.3.6. Effect on Internet Transparency
GIST relies on routers inside the network to intercept and process packets that would normally be transmitted end-to-end. This processing may be non-transparent: messages may be forwarded with modifications, or not forwarded at all. This interception applies
only 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 to which they are directly addressed, i.e.,
as normal Internet traffic.
Because this interception potentially breaks Internet transparency
for packets that have nothing to do with GIST, the encapsulation used
by GIST in this case (called Query-mode or Q-mode) has several
features to avoid accidental collisions with other traffic:
o Q-mode messages are always sent as UDP traffic, and to a specific
well-known port (270) allocated by IANA.
o 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 these checks it will be ignored at the GIST
level and forwarded transparently. Further discussion of the
reception process is in Section 4.3.1 and the encapsulation in
Section 5.3.
3.7. Signalling Sessions
GIST requires signalling applications to associate each of their
messages with a signalling session. Informally, given an application
layer exchange of information for which some network control state
information is to be manipulated or monitored, the corresponding
signalling messages should be associated with the same session.
Signalling applications provide the session identifier (SID) whenever
they wish to send a message, and GIST reports the SID when a message
is received; on messages forwarded at the GIST level, the SID is
preserved unchanged. Usually, NSLPs will preserve the SID value
along the entire signalling path, but this is not enforced by or even
visible to GIST, which only sees the scope of the SID as the single
hop between adjacent NSLP peers.
Most GIST processing and state information is related to the flow
(defined by the MRI; see above) and signalling application (given by
the NSLP identifier, see below). There are several possible
relationships between flows and sessions, for example:
o The simplest case is that all signalling messages for the same
flow have the same SID.
o 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.
o 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, nor does it perform any direct validation on the properties
of the SID itself, such as any enforcement of 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:
o Messages with the same SID that are to be delivered reliably
between the same GIST peers are delivered in order.
o All other messages are handled independently.
o GIST identifies routing state (upstream and downstream peer) by
the MRI/SID/NSLPID combination.
Strictly speaking, the routing state should not depend on the SID.
However, if the routing state is keyed only by (MRI, NSLP), there is
a trivial denial-of-service attack (see Section 8.3) where a
malicious off-path node asserts that it is the peer for a particular
flow. Such an attack would not redirect the traffic but would
reroute the signalling. Instead, the routing state is also
segregated between different SIDs, which means that 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
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, such as 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: o to protect GIST state from corruption, and to protect the nodes on which it runs from resource exhaustion attacks; and o to provide secure transport for NSLP messages to the signalling applications. The protocol mechanisms to achieve 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: o mutual authentication of the GIST peer nodes; o ability to verify the authenticated identity against a database of nodes authorised to take part in GIST signalling; o 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
This section presents an example of GIST usage in a relatively simple (in particular, NAT-free) signalling scenario, to illustrate its main features. 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 Operation Consider the case of an RSVP-like signalling application that makes receiver-based resource reservations for a single unicast flow. In general, signalling can take place along the entire end-to-end path (between flow source and destination), but the role of GIST is only to transfer signalling messages over a single segment of the path, between neighbouring resource-capable nodes. Basic GIST operation is the same, whether it involves the endpoints or only interior nodes: in either case, GIST is triggered by a request from a local signalling application. The example here describes how GIST transfers messages between two adjacent peers some distance along the path, GN1 and GN2 (see Figure 3). We take up the story at the point where a message is being processed above the GIST layer by the signalling application in GN1. 1. The signalling application in GN1 determines that this message is a simple description of resources that would be appropriate for the flow. It determines that it has no special security or transport requirements for the message, but simply that it should be transferred to the next downstream signalling application peer on the path that the flow will take.
2. The message payload is passed to the GIST layer in GN1, along
with a definition of the flow and description of the message
transfer attributes (in this case, requesting no reliable
transmission or channel security protection). GIST determines
that this particular message does not require fragmentation and
that it has no knowledge of the next peer for this flow and
signalling application; however, it also determines that this
application is likely to require secured upstream and downstream
transport of large messages in the future. This determination is
a function of node-internal policy interactions between GIST and
the signalling application.
3. GN1 therefore constructs a GIST Query carrying the NSLP payload,
and additional payloads at the GIST level which will be used to
initiate a messaging association. The Query is encapsulated 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 also included.
4. The Query passes through the network towards the flow receiver,
and is seen by each router in turn. GIST-unaware routers will
not recognise the RAO value and will forward the message
unchanged; GIST-aware routers that do not support the NSLP in
question will also forward the message basically unchanged,
although they may need to process more of the message to decide
this after initial interception.
5. The message is intercepted at GN2. The GIST layer identifies the
message as relevant to a local signalling application, and passes
the NSLP payload and flow description upwards to it. This
signalling application in GN2 indicates to GIST that it will peer
with GN1 and so GIST should proceed to set up any routing state.
In addition, the signalling application continues to process the
message as in GN1 (compare step 1), passing the message back down
to GIST so that it is sent further downstream, and this will
eventually result in the message reaching the flow receiver.
GIST itself operates hop-by-hop, and the signalling application
joins these hops together to manage the end-to-end signalling
operations.
6. In parallel, the GIST instance in GN2 now knows that it should
maintain routing state and a messaging association for future
signalling with GN1. This is recognised because the message is a
Query, and because the local signalling application has indicated
that 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 simply records the identity of GN1 as
its upstream peer for that flow and NSLP, and 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, identifying itself and agreeing to the messaging
association setup. The protocol exchanges needed to
complete this will proceed in parallel with the following
stages.
In each case, the result is that GN1 and GN2 are now in a peering
relationship for the flow.
7. Eventually, another NSLP message works its way upstream from the
receiver to GN2. This message contains a description of the
actual resources requested, along with authorisation and other
security information. The signalling application in GN2 passes
this payload to the GIST level, along with the flow definition
and transfer attributes; in this case, it could request reliable
transmission and use of a secure channel for integrity
protection. (Other combinations of attributes are possible.)
8. The GIST layer in GN2 identifies the upstream peer for this flow
and NSLP as GN1, and determines that it has an MA with the
appropriate properties. The message is queued on the MA for
transmission; this may incur some delay if the procedures begun
in step 6.B have not yet completed.
Further messages can be passed in each direction in the same way.
The GIST layer in each node can in parallel carry out maintenance
operations such as route change detection (see Section 7.1).
It should be understood that several of these details of GIST
operations can be varied, either by local policy or according to
signalling application requirements. The authoritative details are
contained in the remainder of this document.
(page 20 continued on part 2)