in Index   Prev   Next

RFC 5971

GIST: General Internet Signalling Transport

Pages: 154
Part 1 of 6 – Pages 1 to 20
None   None   Next

Top   ToC   RFC5971 - Page 1
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 Transport


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
Top   ToC   RFC5971 - Page 2
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
   ( 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
Top   ToC   RFC5971 - Page 3
     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
Top   ToC   RFC5971 - Page 4

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
Top   ToC   RFC5971 - Page 5
   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].
Top   ToC   RFC5971 - Page 6
   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.
Top   ToC   RFC5971 - Page 7
   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

   [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.
Top   ToC   RFC5971 - Page 8
   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
Top   ToC   RFC5971 - Page 9
   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
Top   ToC   RFC5971 - Page 10

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
Top   ToC   RFC5971 - Page 11
   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

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.
Top   ToC   RFC5971 - Page 12
   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 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 and Section
      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

   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.
Top   ToC   RFC5971 - Page 13
   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.
Top   ToC   RFC5971 - Page 14
   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
Top   ToC   RFC5971 - Page 15
   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.
Top   ToC   RFC5971 - Page 16
   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.
Top   ToC   RFC5971 - Page 17

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.
Top   ToC   RFC5971 - Page 18

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.
Top   ToC   RFC5971 - Page 19
   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

   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:
Top   ToC   RFC5971 - Page 20
       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

       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)

Next Section