Tech-invite   3GPPspecs   RFCs   Search in Tech-invite

in Index   Prev   Next

RFC 5971

GIST: General Internet Signalling Transport

Pages: 154
Group: NSIS
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

   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",
   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

   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

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

   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

   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

               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