Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 5971

GIST: General Internet Signalling Transport

Pages: 154
Part 3 of 6 – Pages 45 to 70
First   Prev   Next

Top   ToC   RFC5971 - Page 45   prevText

5. Message Formats and Transport

5.1. GIST Messages

All GIST messages begin with a common header, followed by a sequence of type-length-value (TLV) objects. This subsection describes the various GIST messages and their contents at a high level in ABNF [11]; a more detailed description of the header and each object is given in Section 5.2 and bit formats in Appendix A. Note that the NAT traversal mechanism for GIST involves the insertion of an additional NAT-Traversal-Object in Query, Response, and some Data and Error messages; the rules for this are given in Section 7.2.
Top   ToC   RFC5971 - Page 46
   GIST-Message: The primary messages are either part of the three-way
   handshake or a simple message carrying NSLP data.  Additional types
   are defined for errors and keeping messaging associations alive.

       GIST-Message = Query / Response / Confirm /
                      Data / Error / MA-Hello

   The common header includes a version number, message type and size,
   and NSLPID.  It also carries a hop count to prevent infinite message
   looping and various control flags, including one (the R-flag) to
   indicate if a reply of some sort is requested.  The objects following
   the common header MUST be carried in a fixed order, depending on
   message type.  Messages with missing, duplicate, or invalid objects
   for the message type MUST be rejected with an "Object Type Error"
   message with the appropriate subcode (Appendix A.4.4.9).  Note that
   unknown objects indicate explicitly how they should be treated and
   are not covered by the above statement.

   Query: A Query MUST be sent in D-mode using the special Q-mode
   encapsulation.  In addition to the common header, it contains certain
   mandatory control objects, and MAY contain a signalling application
   payload.  A stack proposal and configuration data MUST be included if
   the message exchange relates to setup of a messaging association, and
   this is the case even if the Query is intended only for refresh
   (since a routing change might have taken place in the meantime).  The
   R-flag MUST always be set (R=1) in a Query, since this message always
   elicits a Response.

       Query = Common-Header
               [ NAT-Traversal-Object ]
               [ Stack-Proposal Stack-Configuration-Data ]
               [ NSLP-Data ]

   Response: A Response MUST be sent in D-mode if no existing messaging
   association can be re-used.  If one is being re-used, the Response
   MUST be sent in C-mode.  It MUST echo the MRI, SID, and Query-Cookie
   of the Query, and carries its own Network-Layer-Information.  If the
   message exchange relates to setup of a new messaging association,
   which MUST involve a D-mode Response, a Responder-Cookie MUST be
   included, as well as the Responder's own stack proposal and
   configuration data.  The R-flag MUST be set (R=1) if a Responder-
   Cookie is present but otherwise is optional; if the R-flag is set, a
   Confirm MUST be sent as a reply.  Therefore, in particular, a Confirm
   will always be required if a new MA is being set up.  Note that the
Top   ToC   RFC5971 - Page 47
   direction of this MRI will be inverted compared to that in the Query,
   that is, an upstream MRI becomes downstream and vice versa (see
   Section 3.3).

       Response = Common-Header
                  [ NAT-Traversal-Object ]
                  [ Responder-Cookie
                    [ Stack-Proposal Stack-Configuration-Data ] ]
                  [ NSLP-Data ]

   Confirm: A Confirm MUST be sent in C-mode if a messaging association
   is being used for this routing state, and MUST be sent before other
   messages for this routing state if an association is being set up.
   If no messaging association is being used, the Confirm MUST be sent
   in D-mode.  The Confirm MUST include the MRI (with inverted
   direction) and SID, and echo the Responder-Cookie if the Response
   carried one.  In C-mode, the Confirm MUST also echo the Stack-
   Proposal from the Response (if present) so it can be verified that
   this has not been tampered with.  The first Confirm on a new
   association MUST also repeat the Stack-Configuration-Data from the
   original Query in an abbreviated form, just containing the MA-Hold-

       Confirm = Common-Header
                 [ Responder-Cookie
                   [ Stack-Proposal
                     [ Stack-Configuration-Data ] ] ]
                 [ NSLP-Data ]

   Data: The Data message is used to transport NSLP data without
   modifying GIST state.  It contains no control objects, but only the
   MRI and SID associated with the NSLP data being transferred.
   Network-Layer-Information (NLI) MUST be carried in the D-mode case,
   but MUST NOT be included otherwise.

       Data = Common-Header
              [ NAT-Traversal-Object ]
              [ Network-Layer-Information ]
Top   ToC   RFC5971 - Page 48
   Error: An Error message reports a problem determined at the GIST
   level.  (Errors generated by signalling applications are reported in
   NSLP-Data payloads and are not treated specially by GIST.)  If the
   message is being sent in D-mode, the originator of the error message
   MUST include its own Network-Layer-Information object.  All other
   information related to the error is carried in a GIST-Error-Data

       Error = Common-Header
               [ NAT-Traversal-Object ]
               [ Network-Layer-Information ]

   MA-Hello: This message MUST be sent only in C-mode.  It contains the
   common header, with a NSLPID of zero, and a message identifier, the
   Hello-ID.  It always indicates that a node wishes to keep a messaging
   association open, and if sent with R=0 and zero Hello-ID this is its
   only function.  A node MAY also invoke a diagnostic request/reply
   exchange by setting R=1 and providing a non-zero Hello-ID; in this
   case, the peer MUST send another MA-Hello back along the messaging
   association echoing the same Hello-ID and with R=0.  Use of this
   diagnostic is entirely at the discretion of the initiating node.

       MA-Hello = Common-Header

5.2. Information Elements

This section describes the content of the various objects that can be present in each GIST message, both the common header and the individual TLVs. The bit formats are provided in Appendix A.

5.2.1. The Common Header

Each message begins with a fixed format common header, which contains the following information: Version: The version number of the GIST protocol. This specification defines GIST version 1. GIST hop count: A hop count to prevent a message from looping indefinitely. Length: The number of 32-bit words in the message following the common header. Upper layer identifier (NSLPID): This gives the specific NSLP for which this message is used.
Top   ToC   RFC5971 - Page 49
   Context-free flag:  This flag is set (C=1) if the receiver has to be
      able to process the message without supporting routing state.  The
      C-flag MUST be set for Query messages, and also for Data messages
      sent in Q-mode.  The C-flag is important for NAT traversal

   Message type:  The message type (Query, Response, etc.).

   Source addressing mode:  If set (S=1), this indicates that the IP
      source address of the message is the same as the IP address of the
      signalling peer, so replies to this message can be sent safely to
      this address.  S is always set in C-mode.  It is cleared (S=0) if
      the IP source address was derived from the message routing
      information in the payload and this is different from the
      signalling source address.

   Response requested:  A flag that if set (R=1) indicates that a GIST
      message should be sent in reply to this message.  The appropriate
      message type for the reply depends on the type of the initial

   Explicit routing:  A flag that if set (E=1) indicates that the
      message was explicitly routed (see Section 7.1.5).

   Note that in D-mode, Section 5.3, there is a 32-bit magic number
   before the header.  However, this is regarded as part of the
   encapsulation rather than part of the message itself.

5.2.2. TLV Objects

All data following the common header is encoded as a sequence of type-length-value objects. Currently, each object can occur at most once; the set of required and permitted objects is determined by the message type and encapsulation (D-mode or C-mode). Message-Routing-Information (MRI): Information sufficient to define how the signalling message should be routed through the network. Message-Routing-Information = message-routing-method method-specific-information The format of the method-specific-information depends on the message-routing-method requested by the signalling application. Note that it always includes a flag defining the direction as either 'upstream' or 'downstream' (see Section 3.3). It is provided by the NSLP in the message sender and used by GIST to select the message routing.
Top   ToC   RFC5971 - Page 50
   Session-Identifier (SID):  The GIST session identifier is a 128-bit,
      cryptographically random identifier chosen by the node that
      originates the signalling exchange.  See Section 3.7.

   Network-Layer-Information (NLI):  This object carries information
      about the network layer attributes of the node sending the
      message, including data related to the management of routing
      state.  This includes a peer identity and IP address for the
      sending node.  It also includes IP-TTL information to allow the IP
      hop count between GIST peers to be measured and reported, and a
      validity time (RS-validity-time) for the routing state.

       Network-Layer-Information = peer-identity

   The use of the RS-validity-time field is described in Section 4.4.4.
   The peer-identity and interface-address are used for matching
   existing associations, as discussed in Section 4.4.3.

   The interface-address must be routable, i.e., it MUST be usable as a
   destination IP address for packets to be sent back to the node
   generating the signalling message, whether in D-mode or C-mode.  If
   this object is carried in a message with the source addressing mode
   flag S=1, the interface-address MUST match the source address used in
   the IP encapsulation, to assist in legacy NAT detection
   (Section 7.2.1).  If this object is carried in a Query or Confirm,
   the interface-address MUST specifically be set to an address bound to
   an interface associated with the MRI, to allow its use in route
   change handling as discussed in Section 7.1.  A suitable choice is
   the interface that is carrying the outbound flow.  A node may have
   several choices for which of its addresses to use as the
   interface-address.  For example, there may be a choice of IP
   versions, or addresses of limited scope (e.g., link-local), or
   addresses bound to different interfaces in the case of a router or
   multihomed host.  However, some of these interface addresses may not
   be usable by the peer.  A node MUST follow a policy of using a global
   address of the same IP version as in the MRI, unless it can establish
   that an alternative address would also be usable.

   The setting and interpretation of the IP-TTL field depends on the
   message direction (upstream/downstream as determined from the MRI as
   described above) and encapsulation.

      *  If the message is sent downstream, if the TTL that will be set
         in the IP header for the message can be determined, the IP-TTL
         value MUST be set to this value, or else set to 0.
Top   ToC   RFC5971 - Page 51
      *  On receiving a downstream message in D-mode, a non-zero IP-TTL
         is compared to the TTL in the IP header, and the difference is
         stored as the IP-hop-count-to-peer for the upstream peer in the
         routing state table for that flow.  Otherwise, the field is

      *  If the message is sent upstream, the IP-TTL MUST be set to the
         value of the IP-hop-count-to-peer stored in the routing state
         table, or 0 if there is no value yet stored.

      *  On receiving an upstream message, the IP-TTL is stored as the
         IP-hop-count-to-peer for the downstream peer.

      In all cases, the IP-TTL value reported to signalling applications
      is the one stored with the routing state for that flow, after it
      has been updated if necessary from processing the message in

   Stack-Proposal:  This field contains information about which
      combinations of transport and security protocols are available for
      use in messaging associations, and is also discussed further in
      Section 5.7.

       Stack-Proposal = 1*stack-profile

       stack-profile = protocol-count 1*protocol-layer
                       ;; padded on the right with 0 to 32-bit boundary

       protocol-count = %x01-FF
                       ;; number of the following <protocol-layer>,
                       ;; represented as one byte.  This doesn't include
                       ;; padding.

       protocol-layer = %x01-FF

   Each protocol-layer field identifies a protocol with a unique tag;
   any additional data, such as higher-layer addressing or other options
   data associated with the protocol, will be carried in an
   MA-protocol-options field in the Stack-Configuration-Data TLV (see

   Stack-Configuration-Data (SCD):  This object carries information
      about the overall configuration of a messaging association.

       Stack-Configuration-Data = MA-Hold-Time
Top   ToC   RFC5971 - Page 52
   The MA-Hold-Time field indicates how long a node will hold open an
   inactive association; see Section 4.4.5 for more discussion.  The
   MA-protocol-options fields give the configuration of the protocols
   (e.g., TCP, TLS) to be used for new messaging associations, and they
   are described in more detail in Section 5.7.

   Query-Cookie/Responder-Cookie:  A Query-Cookie is contained in a
      Query and MUST be echoed in a Response; a Responder-Cookie MAY be
      sent in a Response, and if present MUST be echoed in the following
      Confirm.  Cookies are variable-length bit strings, chosen by the
      cookie generator.  See Section 8.5 for further details on
      requirements and mechanisms for cookie generation.

   Hello-ID:  The Hello-ID is a 32-bit quantity that is used to
      correlate messages in an MA-Hello request/reply exchange.  A non-
      zero value MUST be used in a request (messages sent with R=1) and
      the same value must be returned in the reply (which has R=0).  The
      value zero MUST be used for all other messages; if a message is
      received with R=1 and Hello-ID=0, an "Object Value Error" message
      (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") MUST be
      returned and the message dropped.  Nodes MAY use any algorithm to
      generate the Hello-ID; a suitable approach is a local sequence
      number with a random starting point.

   NSLP-Data:  The NSLP payload to be delivered to the signalling
      application.  GIST does not interpret the payload content.

   GIST-Error-Data:  This contains the information to report the cause
      and context of an error.

       GIST-Error-Data = error-class error-code error-subcode
                         [ Message-Routing-Information-content ]
                         [ Session-Identification-content ]
                         [ comment ]

   The error-class indicates the severity level, and the error-code and
   error-subcode identify the specific error itself.  A full list of
   GIST errors and their severity levels is given in Appendix A.4.  The
   common-error-header carries the Common-Header from the original
   message, and contents of the Message-Routing-Information (MRI) and
   Session-Identifier (SID) objects are also included if they were
   successfully decoded.  For some errors, additional information fields
   can be included, and these fields themselves have a simple TLV
   format.  Finally, an optional free-text comment may be added.
Top   ToC   RFC5971 - Page 53

5.3. D-mode Transport

This section describes the various encapsulation options for D-mode messages. Although there are several possibilities, depending on message type, MRM, and local policy, the general design principle is that the sole purpose of the encapsulation is to ensure that the message is delivered to or intercepted at the correct peer. Beyond that, minimal significance is attached to the type of encapsulation or the values of addresses or ports used for it. This allows new options to be developed in the future to handle particular deployment requirements without modifying the overall protocol specification.

5.3.1. Normal Encapsulation

Normal encapsulation MUST be used for all D-mode messages where the signalling peer is already known from previous signalling. This includes Response and Confirm messages, and Data messages except if these are being sent without using local routing state. Normal encapsulation is simple: the message is carried in a single UDP datagram. UDP checksums MUST be enabled. The UDP payload MUST always begin with a 32-bit magic number with value 0x4e04 bda5 in network byte order; this is followed by the GIST common header and the complete set of payloads. If the magic number is not present, the message MUST be silently dropped. The normal encapsulation is shown in outline in Figure 6. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // IP Header // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // UDP Header // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GIST Magic Number (0x4e04bda5) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // GIST Common Header // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // GIST Payloads // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Normal Encapsulation Packet Format The message is IP addressed directly to the adjacent peer as given by the routing state table. Where the message is a direct reply to a Query and no routing state exists, the destination address is derived from the input message using the same rules as in Section 4.4.1. The UDP port numbering MUST be compatible with that used on Query messages (see below), that is, the same for messages in the same
Top   ToC   RFC5971 - Page 54
   direction and with source and destination port numbers swapped for
   messages in the opposite direction.  Messages with the normal
   encapsulation MUST be sent with source addressing mode flag S=1
   unless the message is a reply to a message that is known to have
   passed through a NAT, and the receiver MUST check the IP source
   address with the interface-address given in the NLI as part of legacy
   NAT detection.  Both these aspects of message processing are
   discussed further in Section 7.2.1.

5.3.2. Q-mode Encapsulation

Q-mode encapsulation MUST be used for messages where no routing state is available or where the routing state is being refreshed, in particular, for Query messages. Q-mode can also be used when requested by local policy. Q-mode encapsulation is similar to normal encapsulation, with changes in IP address selection, rules about IP options, and a defined method for selecting UDP ports. It is an essential property of the Q-mode encapsulation that it is possible for a GIST node to intercept these messages efficiently even when they are not directly addressed to it and, conversely, that it is possible for a non-GIST node to ignore these messages without overloading the slow path packet processing. This document specifies that interception is done based on RAOs. Encapsulation and Interception in IPv4
In general, the IP addresses are derived from information in the MRI; the exact rules depend on the MRM. For the case of messages with source addressing mode flag S=1, the receiver MUST check the IP source address against the interface-address given in the NLI as part of legacy NAT detection; see Section 7.2.1. Current MRMs define the use of a Router Alert Option [13] to assist the peer in intercepting the message depending on the NSLPID. If the MRM defines the use of RAO, the sender MUST include it unless it has been specifically configured not to (see below). A node MAY make the initial interception decision based purely on IP-Protocol number transport header analysis. Implementations MAY provide an option to disable the setting of RAO on Q-mode packets on a per-destination prefix basis; however, the option MUST be disabled by default and MUST only be enabled when it has been separately verified that the next GIST node along the path to the destination is capable of intercepting packets without RAO. The purpose of this option is to allow operation across networks that do not properly support RAO; further details are discussed in Appendix C.
Top   ToC   RFC5971 - Page 55
   It is likely that fragmented datagrams will not be correctly
   intercepted in the network, since the checks that a datagram is a
   Q-mode packet depend on data beyond the IP header.  Therefore, the
   sender MUST set the Don't Fragment (DF) bit in the IPv4 header.  Note
   that ICMP "packet too large" messages will be sent to the source
   address of the original IP datagram, and since all MRM definitions
   recommend S=1 for at least some retransmissions, ICMP errors related
   to fragmentation will be seen at the Querying node.

   The upper layer protocol, identified by the IP-Protocol field in the
   IP header, MUST be UDP. Encapsulation and Interception in IPv6
As for IPv4, the IP addresses are derived from information in the MRI; the exact rules depend on the MRM. For the case of messages with source addressing mode flag S=1, the receiver MUST check the IP source address with the interface-address given in the NLI as part of legacy NAT detection; see Section 7.2.1. For all current MRMs, the IP header is given a Router Alert Option [8] to assist the peer in intercepting the message depending on the NSLPID. If the MRM defines the use of RAO, the sender MUST include it without exception. It is RECOMMENDED that a node bases its initial interception decision purely on the presence of a hop-by-hop option header containing the RAO, which will be at the start of the header chain. The upper layer protocol MUST be UDP without intervening encapsulation layers. Following any hop-by-hop option header, the IP header MUST NOT include any extension headers other than routing or destination options [5], and for the last extension header MUST have a next-header field of UDP. Upper Layer Encapsulation and Overall Interception Requirements
For both IP versions, the above rules require that the upper layer protocol identified by the IP header MUST be UDP. Other packets MUST NOT be identified as GIST Q-mode packets; this includes IP-in-IP tunnelled packets, other tunnelled packets (tunnel mode AH/ESP), or packets that have undergone some additional transport layer processing (transport mode AH/ESP). If IP output processing at the originating node or an intermediate router causes such additional encapsulations to be added to a GIST Q-mode packet, this packet will not be identified as GIST until the encapsulation is terminated. If the node wishes to signal for data over the network region where the
Top   ToC   RFC5971 - Page 56
   encapsulation applies, it MUST generate additional signalling with an
   MRI matching the encapsulated traffic, and the outbound GIST Q-mode
   messages for it MUST bypass the encapsulation processing.

   Therefore, the final stage of the interception process and the final
   part of encapsulation is at the UDP level.  The source UDP port is
   selected by the message sender as the port at which it is prepared to
   receive UDP messages in reply, and the sender MUST use the
   destination UDP port allocated for GIST by IANA (see Section 9).
   Note that for some MRMs, GIST nodes anywhere along the path can
   generate GIST packets with source addresses that spoof the source
   address of the data flow.  Therefore, destinations cannot distinguish
   these packets from genuine end-to-end data purely on address
   analysis.  Instead, it must be possible to distinguish such GIST
   packets by port analysis; furthermore, the mechanism to do so must
   remain valid even if the destination is GIST-unaware.  GIST solves
   this problem by using a fixed destination UDP port from the "well
   known" space for the Q-mode encapsulation.  This port should never be
   allocated on a GIST-unaware host, and therefore Q-mode encapsulated
   messages should always be rejected with an ICMP error.  The usage of
   this destination port by other applications will result in reduced
   performance due to increased delay and packet drop rates due to their
   interception by GIST nodes.

   A GIST node will need to be capable to filter out all IP/UDP packets
   that have a UDP destination port number equal to the one registered
   for GIST Q-mode encapsulation.  These packets SHOULD then be further
   verified to be GIST packets by checking the magic number (see
   Section 5.3.1).  The packets that meet both port and magic number
   requirements are further processed as GIST Q-mode packets.  Any
   filtered packets that fail this GIST magic number check SHOULD be
   forwarded towards the IP packet's destination as a normal IP
   datagram.  To protect against denial-of-service attacks, a GIST node
   SHOULD have a rate limiter preventing more packets (filtered as
   potential Q-mode packets) from being processed than the system can
   safely handle.  Any excess packets SHOULD be discarded. IP Option Processing
For both IPv4 and IPv6, for Q-mode packets with IP options allowed by the above requirements, IP options processing is intended to be carried out independently of GIST processing. Note that for the options allowed by the above rules, the option semantics are independent of the payload: UDP payload modifications are not prevented by the options and do not affect the option content, and conversely the presence of the options does not affect the UDP payload.
Top   ToC   RFC5971 - Page 57
   On packets originated by GIST, IP options MAY be added according to
   node-local policies on outgoing IP data.  On packets forwarded by
   GIST without NSLP processing, IP options MUST be processed as for a
   normally forwarded IP packet.  On packets locally delivered to the
   NSLP, the IP options MAY be passed to the NSLP and equivalent options
   used on subsequently generated outgoing Q-mode packets.  In this
   case, routing related options SHOULD be processed identically as they
   would be for a normally forwarded IP packet.

5.3.3. Retransmission and Rate Control

D-mode uses UDP, and hence has no automatic reliability or congestion control capabilities. Signalling applications requiring reliability should be serviced using C-mode, which should also carry the bulk of signalling traffic. However, some form of messaging reliability is required for the GIST control messages themselves, as is rate control to handle retransmissions and also bursts of unreliable signalling or state setup requests from the signalling applications. Query messages that do not receive Responses MAY be retransmitted; retransmissions MUST use a binary exponential backoff. The initial timer value is T1, which the backoff process can increase up to a maximum value of T2 seconds. The default value for T1 is 500 ms. T1 is an estimate of the round-trip time between the Querying and Responding nodes. Nodes MAY use smaller values of T1 if it is known that the Query should be answered within the local network. T1 MAY be chosen larger, and this is RECOMMENDED if it is known in advance (such as on high-latency access links) that the round-trip time is larger. The default value of T2 is 64*T1. Note that Queries may go unanswered either because of message loss (in either direction) or because there is no reachable GIST peer. Therefore, implementations MAY trade off reliability (large T2) against promptness of error feedback to applications (small T2). If the NSLP has indicated a timeout on the validity of this payload (see Appendix B.1), T2 MUST be chosen so that the process terminates within this timeout. Retransmitted Queries MUST use different Query-Cookie values. If the Query carries NSLP data, it may be delivered multiple times to the signalling application. These rules apply equally to the message that first creates routing state, and those that refresh it. In all cases, Responses MUST be sent promptly to avoid spurious retransmissions. Nodes generating any type of retransmission MUST be prepared to receive and match a reply to any of them, not just the one most recently sent. Although a node SHOULD terminate its retransmission process when any reply is received, it MUST continue to process further replies as normal.
Top   ToC   RFC5971 - Page 58
   This algorithm is sufficient to handle lost Queries and Responses.
   The case of a lost Confirm is more subtle.  The Responding node MAY
   run a retransmission timer to resend the Response until a Confirm is
   received; the timer MUST use the same backoff mechanism and
   parameters as for Responses.  The problem of an amplification attack
   stimulated by a malicious Query is handled by requiring the cookie
   mechanism to enable the node receiving the Response to discard it
   efficiently if it does not match a previously sent Query.  This
   approach is only appropriate if the Responding node is prepared to
   store per-flow state after receiving a single (Query) message, which
   includes the case where the node has queued NSLP data.  If the
   Responding node has delayed state installation, the error condition
   will only be detected when a Data message arrives.  This is handled
   as a routing state error (see Section 4.4.6) that causes the Querying
   node to restart the handshake.

   The basic rate-control requirements for D-mode traffic are
   deliberately minimal.  A single rate limiter applies to all traffic,
   for all interfaces and message types.  It applies to retransmissions
   as well as new messages, although an implementation MAY choose to
   prioritise one over the other.  Rate-control applies only to locally
   generated D-mode messages, not to messages that are being forwarded.
   When the rate limiter is in effect, D-mode messages MUST be queued
   until transmission is re-enabled, or they MAY be dropped with an
   error condition indicated back to local signalling applications.  In
   either case, the effect of this will be to reduce the rate at which
   new transactions can be initiated by signalling applications, thereby
   reducing the load on the network.

   The rate-limiting mechanism is implementation-defined, but it is
   RECOMMENDED that a token bucket limiter as described in [33] be used.
   The token bucket MUST be sized to ensure that a node cannot saturate
   the network with D-mode traffic, for example, when re-probing the
   network for multiple flows after a route change.  A suitable approach
   is to restrict the token bucket parameters so that the mean output
   rate is a small fraction of the node's lowest-speed interface.  It is
   RECOMMENDED that this fraction is no more than 5%.  Note that
   according to the rules of Section 4.3.3, in general, D-mode SHOULD
   only be used for Queries and Responses rather than normal signalling
   traffic unless capacity for normal signalling traffic can be

5.4. C-mode Transport

It is a requirement of the NTLP defined in [29] that it should be able to support bundling of small messages, fragmentation of large messages, and message boundary delineation. TCP provides both bundling and fragmentation, but not message boundaries. However, the
Top   ToC   RFC5971 - Page 59
   length information in the GIST common header allows the message
   boundary to be discovered during parsing.  The bundling together of
   small messages either can be done within the transport protocol or
   can be carried out by GIST during message construction.  Either way,
   two approaches can be distinguished:

   1.  As messages arrive for transmission, they are gathered into a
       bundle until a size limit is reached or a timeout expires (cf.
       the Nagle algorithm of TCP).  This provides maximal efficiency at
       the cost of some latency.

   2.  Messages awaiting transmission are gathered together while the
       node is not allowed to send them, for example, because it is
       congestion controlled.

   The second type of bundling is always appropriate.  For GIST, the
   first type MUST NOT be used for trigger messages (i.e., messages that
   update GIST or signalling application state), but may be appropriate
   for refresh messages (i.e., messages that just extend timers).  These
   distinctions are known only to the signalling applications, but MAY
   be indicated (as an implementation issue) by setting the priority
   transfer attribute (Section 4.1.2).

   It can be seen that all of these transport protocol options can be
   supported by the basic GIST message format already presented.  The
   GIST message, consisting of common header and TLVs, is carried
   directly in the transport protocol, possibly incorporating transport
   layer security protection.  Further messages can be carried in a
   continuous stream.  This specification defines only the use of TCP,
   but other possibilities could be included without additional work on
   message formatting.

5.5. Message Type/Encapsulation Relationships

GIST has four primary message types (Query, Response, Confirm, and Data) and three possible encapsulation methods (normal D-mode, Q-mode, and C-mode). The combinations of message type and encapsulation that are allowed for message transmission are given in the table below. In some cases, there are several possible choices, depending on the existence of routing state or messaging associations. The rules governing GIST policy, including whether or not to create such state to handle a message, are described normatively in the other sections of this specification. If a message that can only be sent in Q-mode or D-mode arrives in C-mode or vice versa, this MUST be rejected with an "Incorrect Encapsulation" error message (Appendix A.4.4.3). However, it should be noted that the processing of the message at the receiver is not otherwise affected by the encapsulation method used, except that the
Top   ToC   RFC5971 - Page 60
   decapsulation process may provide additional information, such as
   translated addresses or IP hop count to be used in the subsequent
   message processing.

   |  Message |    Normal    |   Query D-mode (Q-mode)   |    C-mode   |
   |          |    D-mode    |                           |             |
   |   Query  |     Never    |   Always, with C-flag=1   |    Never    |
   |          |              |                           |             |
   | Response |   Unless a   |           Never           |     If a    |
   |          |   messaging  |                           |  messaging  |
   |          |  association |                           | association |
   |          |   is being   |                           |   is being  |
   |          |    re-used   |                           |   re-used   |
   |          |              |                           |             |
   |  Confirm |  Only if no  |           Never           |     If a    |
   |          |   messaging  |                           |  messaging  |
   |          |  association |                           | association |
   |          | has been set |                           |   has been  |
   |          |   up or is   |                           |  set up or  |
   |          |     being    |                           |   is being  |
   |          |    re-used   |                           |   re-used   |
   |          |              |                           |             |
   |   Data   |  If routing  | If the MRI can be used to |     If a    |
   |          | state exists |     derive the Q-mode     |  messaging  |
   |          | for the flow | encapsulation, and either | association |
   |          |    but no    |  no routing state exists  |    exists   |
   |          |   messaging  |  or local policy requires |             |
   |          |  association |     Q-mode; MUST have     |             |
   |          |              |          C-flag=1         |             |

5.6. Error Message Processing

Special rules apply to the encapsulation and transmission of Error messages. GIST only generates Error messages in reaction to incoming messages. Error messages MUST NOT be generated in reaction to incoming Error messages. The routing and encapsulation of the Error message are derived from that of the message that caused the error; in particular, local routing state is not consulted. Routing state and messaging association state MUST NOT be created to handle the error, and Error messages MUST NOT be retransmitted explicitly by GIST, although they are subject to the same rate control as other messages.
Top   ToC   RFC5971 - Page 61
   o  If the incoming message was received in D-mode, the error MUST be
      sent in D-mode using the normal encapsulation, using the
      addressing information from the NLI object in the incoming
      message.  If the NLI could not be determined, the error MUST be
      sent to the IP source of the incoming message if the S-flag was
      set in it.  The NLI object in the Error message reports
      information about the originator of the error.

   o  If the incoming message was received over a messaging association,
      the error MUST be sent back over the same messaging association.

   The NSLPID in the common header of the Error message has the value
   zero.  If for any reason the message cannot be sent (for example,
   because it is too large to send in D-mode, or because the MA over
   which the original message arrived has since been closed), an error
   SHOULD be logged locally.  The receiver of the Error message can
   infer the NSLPID for the message that caused the error from the
   Common Header that is embedded in the Error Object.

5.7. Messaging Association Setup

5.7.1. Overview

A key attribute of GIST is that it is flexible in its ability to use existing transport and security protocols. Different transport protocols may have performance attributes appropriate to different environments; different security protocols may fit appropriately with different authentication infrastructures. Even given an initial default mandatory protocol set for GIST, the need to support new protocols in the future cannot be ruled out, and secure feature negotiation cannot be added to an existing protocol in a backwards- compatible way. Therefore, some sort of capability discovery is required. Capability discovery is carried out in Query and Response messages, using Stack-Proposal and Stack-Configuration-Data (SCD) objects. If a new messaging association is required, it is then set up, followed by a Confirm. Messaging association multiplexing is achieved by short-circuiting this exchange by sending the Response or Confirm messages on an existing association (Section 4.4.3); whether to do this is a matter of local policy. The end result of this process is a messaging association that is a stack of protocols. If multiple associations exist, it is a matter of local policy how to distribute messages over them, subject to respecting the transfer attributes requested for each message.
Top   ToC   RFC5971 - Page 62
   Every possible protocol for a messaging association has the following

   o  MA-Protocol-ID, a 1-byte IANA-assigned value (see Section 9).

   o  A specification of the (non-negotiable) policies about how the
      protocol should be used, for example, in which direction a
      connection should be opened.

   o  (Depending on the specific protocol:) Formats for an MA-protocol-
      options field to carry the protocol addressing and other
      configuration information in the SCD object.  The format may
      differ depending on whether the field is present in the Query or
      Response.  Some protocols do not require the definition of such
      additional data, in which case no corresponding MA-protocol-
      options field will occur in the SCD object.

   A Stack-Proposal object is simply a list of profiles; each profile is
   a sequence of MA-Protocol-IDs.  A profile lists the protocols in 'top
   to bottom' order (e.g., TLS over TCP).  A Stack-Proposal is generally
   accompanied by an SCD object that carries an MA-protocol-options
   field for any protocol listed in the Stack-Proposal that needs it.
   An MA-protocol-options field may apply globally, to all instances of
   the protocol in the Stack-Proposal, or it can be tagged as applying
   to a specific instance.  The latter approach can for example be used
   to carry different port numbers for TCP depending on whether it is to
   be used with or without TLS.  An message flow that shows several of
   the features of Stack-Proposal and Stack-Configuration-Data formats
   can be found in Appendix D.

   An MA-protocol-options field may also be flagged as not usable; for
   example, a NAT that could not handle SCTP would set this in an MA-
   protocol-options field about SCTP.  A protocol flagged this way MUST
   NOT be used for a messaging association.  If the Stack-Proposal and
   SCD are both present but not consistent, for example, if they refer
   to different protocols, or an MA-protocol-options field refers to a
   non-existent profile, an "Object Value Error" message
   (Appendix A.4.4.10) with subcode 5 ("Stack-Proposal - Stack-
   Configuration-Data Mismatch") MUST be returned and the message

   A node generating an SCD object MUST honour the implied protocol
   configurations for the period during which a messaging association
   might be set up; in particular, it MUST be immediately prepared to
   accept incoming datagrams or connections at the protocol/port
   combinations advertised.  This MAY require the creation of listening
   endpoints for the transport and security protocols in question, or a
   node MAY keep a pool of such endpoints open for extended periods.
Top   ToC   RFC5971 - Page 63
   However, the received object contents MUST be retained only for the
   duration of the Query/Response exchange and to allow any necessary
   association setup to complete.  They may become invalid because of
   expired bindings at intermediate NATs, or because the advertising
   node is using agile ports.  Once the setup is complete, or if it is
   not necessary or fails for some reason, the object contents MUST be
   discarded.  A default time of 30 seconds to keep the contents is

   A Query requesting messaging association setup always contains a
   Stack-Proposal and SCD object.  The Stack-Proposal MUST only include
   protocol configurations that are suitable for the transfer attributes
   of the messages for which the Querying node wishes to use the
   messaging association.  For example, it should not simply include all
   configurations that the Querying node is capable of supporting.

   The Response always contains a Stack-Proposal and SCD object, unless
   multiplexing (where the Responder decides to use an existing
   association) occurs.  For such a Response, the security protocols
   listed in the Stack-Proposal MUST NOT depend on the Query.  A node
   MAY make different proposals depending on the combination of
   interface and NSLPID.  If multiplexing does occur, which is indicated
   by sending the Response over an existing messaging association, the
   following rules apply:

   o  The re-used messaging association MUST NOT have weaker security
      properties than all of the options that would have been offered in
      the full Response that would have been sent without re-use.

   o  The re-used messaging association MUST have equivalent or better
      transport and security characteristics as at least one of the
      protocol configurations that was offered in the Query.

   Once the messaging association is set up, the Querying node repeats
   the responder's Stack-Proposal over it in the Confirm.  The
   Responding node MUST verify that this has not been changed as part of
   bidding-down attack prevention, as well as verifying the Responder-
   Cookie (Section 8.5).  If either check fails, the Responding node
   MUST NOT create the message routing state (or MUST delete it if it
   already exists) and SHOULD log an error condition locally.  If this
   is the first message on a new MA, the MA MUST be torn down.  See
   Section 8.6 for further discussion.
Top   ToC   RFC5971 - Page 64

5.7.2. Protocol Definition: Forwards-TCP

This MA-Protocol-ID denotes a basic use of TCP between peers. Support for this protocol is REQUIRED. If this protocol is offered, MA-protocol-options data MUST also be carried in the SCD object. The MA-protocol-options field formats are: o in a Query: no additional options data (the MA-protocol-options Length field is zero). o in a Response: 2-byte port number at which the connection will be accepted, followed by 2 pad bytes. The connection is opened in the forwards direction, from the Querying node towards the responder. The Querying node MAY use any source address and source port. The destination information MUST be derived from information in the Response: the address from the interface- address from the Network-Layer-Information object and the port from the SCD object as described above. Associations using Forwards-TCP can carry messages with the transfer attribute Reliable=True. If an error occurs on the TCP connection such as a reset, as can be detected for example by a socket exception condition, GIST MUST report this to NSLPs as discussed in Section 4.1.2.

5.7.3. Protocol Definition: Transport Layer Security

This MA-Protocol-ID denotes a basic use of transport layer channel security, initially in conjunction with TCP. Support for this protocol in conjunction with TCP is REQUIRED; associations using it can carry messages with transfer attributes requesting confidentiality or integrity protection. The specific TLS version will be negotiated within the TLS layer itself, but implementations MUST NOT negotiate to protocol versions prior to TLS1.0 [15] and MUST use the highest protocol version supported by both peers. Implementation of TLS1.2 [10] is RECOMMENDED. GIST nodes supporting TLS1.0 or TLS1.1 MUST be able to negotiate the TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD be able to negotiate the TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. They MAY negotiate any mutually acceptable ciphersuite that provides authentication, integrity, and confidentiality. The default mode of TLS authentication, which applies in particular to the above ciphersuites, uses a client/server X.509 certificate exchange. The Querying node acts as a TLS client, and the Responding node acts as a TLS server. Where one of the above ciphersuites is negotiated, the GIST node acting as a server MUST provide a
Top   ToC   RFC5971 - Page 65
   certificate, and MUST request one from the GIST node acting as a TLS
   client.  This allows either server-only or mutual authentication,
   depending on the certificates available to the client and the policy
   applied at the server.

   GIST nodes MAY negotiate other TLS ciphersuites.  In some cases, the
   negotiation of alternative ciphersuites is used to trigger
   alternative authentication procedures, such as the use of pre-shared
   keys [32].  The use of other authentication procedures may require
   additional specification work to define how they can be used as part
   of TLS within the GIST framework, and may or may not require the
   definition of additional MA-Protocol-IDs.

   No MA-protocol-options field is required for this TLS protocol
   definition.  The configuration information for the transport protocol
   over which TLS is running (e.g., TCP port number) is provided by the
   MA-protocol-options for that protocol. Identity Checking in TLS
After TLS authentication, a node MUST check the identity presented by the peer in order to avoid man-in-the-middle attacks, and verify that the peer is authorised to take part in signalling at the GIST layer. The authorisation check is carried out by comparing the presented identity with each Authorised Peer Database (APD) entry in turn, as discussed in Section 4.4.2. This section defines the identity comparison algorithm for a single APD entry. For TLS authentication with X.509 certificates, an identity from the DNS namespace MUST be checked against each subjectAltName extension of type dNSName present in the certificate. If no such extension is present, then the identity MUST be compared to the (most specific) Common Name in the Subject field of the certificate. When matching DNS names against dNSName or Common Name fields, matching is case- insensitive. Also, a "*" wildcard character MAY be used as the left- most name component in the certificate or identity in the APD. For example, * in the APD would match certificates for,, *, etc., but would not match Similarly, a certificate for * would be valid for APD identities of,, *, etc., but not Additionally, a node MUST verify the binding between the identity of the peer to which it connects and the public key presented by that peer. Nodes SHOULD implement the algorithm in Section 6 of [8] for general certificate validation, but MAY supplement that algorithm
Top   ToC   RFC5971 - Page 66
   with other validation methods that achieve equivalent levels of
   verification (such as comparing the server certificate against a
   local store of already-verified certificates and identity bindings).

   For TLS authentication with pre-shared keys, the identity in the
   psk_identity_hint (for the server identity, i.e., the Responding
   node) or psk_identity (for the client identity, i.e., the Querying
   node) MUST be compared to the identities in the APD.

5.8. Specific Message Routing Methods

Each message routing method (see Section 3.3) requires the definition of the format of the message routing information (MRI) and Q-mode encapsulation rules. These are given in the following subsections for the MRMs currently defined. A GIST implementation on a node MUST support whatever MRMs are required by the NSLPs on that node; GIST implementations SHOULD provide support for both the MRMs defined here, in order to minimise deployment barriers for new signalling applications that need them.

5.8.1. The Path-Coupled MRM Message Routing Information
For the path-coupled MRM, the message routing information (MRI) is conceptually the Flow Identifier as in the NSIS framework [29]. Minimally, this could just be the flow destination address; however, to account for policy-based forwarding and other issues a more complete set of header fields SHOULD be specified if possible (see Section 4.3.4 and Section 7.2 for further discussion). MRI = network-layer-version source-address prefix-length destination-address prefix-length IP-protocol diffserv-codepoint [ flow-label ] [ ipsec-SPI / L4-ports] Additional control information defines whether the flow-label, IPsec Security Parameters Index (SPI), and port information are present, and whether the IP-protocol and diffserv-codepoint fields should be interpreted as significant. The source and destination addresses MUST be real node addresses, but prefix lengths other than 32 or 128 (for IPv4 and IPv6, respectively) MAY be used to implement address wildcarding, allowing the MRI to refer to traffic to or from a wider address range. An additional flag defines the message direction relative to the MRI (upstream vs. downstream).
Top   ToC   RFC5971 - Page 67
   The MRI format allows a potentially very large number of different
   flag and field combinations.  A GIST implementation that cannot
   interpret the MRI in a message MUST return an "Object Value Error"
   message (Appendix A.4.4.10) with subcodes 1 ("Value Not Supported")
   or 2 ("Invalid Flag-Field Combination") and drop the message. Downstream Q-mode Encapsulation
Where the signalling message is travelling in the same ('downstream') direction as the flow defined by the MRI, the IP addressing for Q-mode encapsulated messages is as follows. Support for this encapsulation is REQUIRED. o The destination IP address MUST be the flow destination address as given in the MRI of the message payload. o By default, the source address is the flow source address, again from the MRI; therefore, the source addressing mode flag in the common header S=0. This provides the best likelihood that the message will be correctly routed through any region performing per-packet policy-based forwarding or load balancing that takes the source address into account. However, there may be circumstances where the use of the signalling source address (S=1) is preferable, such as: * In order to receive ICMP error messages about the signalling message, such as unreachable port or address. If these are delivered to the flow source rather than the signalling source, it will be very difficult for the querying node to detect that it is the last GIST node on the path. Another case is where there is an abnormally low MTU along the path, in which case the querying node needs to see the ICMP error (recall that Q-mode packets are sent with DF set). * In order to receive GIST Error messages where the error message sender could not interpret the NLI in the original message. * In order to attempt to run GIST through an unmodified NAT, which will only process and translate IP addresses in the IP header (see Section 7.2.1). Because of these considerations, use of the signalling source address is allowed as an option, with use based on local policy. A node SHOULD use the flow source address for initial Query messages, but SHOULD transition to the signalling source address for some retransmissions or as a matter of static configuration,
Top   ToC   RFC5971 - Page 68
      for example, if a NAT is known to be in the path out of a certain
      interface.  The S-flag in the common header tells the message
      receiver which option was used.

   A Router Alert Option is also included in the IP header.  The option
   value depends on the NSLP being signalled for.  In addition, it is
   essential that the Query mimics the actual data flow as closely as
   possible, since this is the basis of how the signalling message is
   attached to the data path.  To this end, GIST SHOULD set the Diffserv
   codepoint and (for IPv6) flow label to match the values in the MRI.

   A GIST implementation SHOULD apply validation checks to the MRI, to
   reject Query messages that are being injected by nodes with no
   legitimate interest in the flow being signalled for.  In general, if
   the GIST node can detect that no flow could arrive over the same
   interface as the Query, it MUST be rejected with an appropriate error
   message.  Such checks apply only to messages with the Q-mode
   encapsulation, since only those messages are required to track the
   flow path.  The main checks are that the IP version used in the
   encapsulation should match that of the MRI and the version(s) used on
   that interface, and that the full range of source addresses (the
   source-address masked with its prefix-length) would pass ingress
   filtering checks.  For these cases, the error message is "MRI
   Validation Failure" (Appendix A.4.4.12) with subcodes 1 or 2 ("IP
   Version Mismatch" or "Ingress Filter Failure"), respectively. Upstream Q-mode Encapsulation
In some deployment scenarios, it is desirable to set up routing state in the upstream direction (i.e., from flow receiver towards the sender). This could be used to support firewall signalling to control traffic from an uncooperative sender, or signalling in general where the flow sender was not NSIS-capable. This capability is incorporated into GIST by defining an encapsulation and processing rules for sending Query messages upstream. In general, it is not possible to determine the hop-by-hop route upstream because of asymmetric IP routing. However, in particular cases, the upstream peer can be discovered with a high degree of confidence, for example: o The upstream GIST peer is one IP hop away, and can be reached by tracing back through the interface on which the flow arrives. o The upstream peer is a border router of a single-homed (stub) network.
Top   ToC   RFC5971 - Page 69
   This section defines an upstream Q-mode encapsulation and validation
   checks for when it can be used.  The functionality to generate
   upstream Queries is OPTIONAL, but if received they MUST be processed
   in the normal way with some additional IP TTL checks.  No special
   functionality is needed for this.

   It is possible for routing state at a given node, for a specific MRI
   and NSLPID, to be created by both an upstream Query exchange
   (initiated by the node itself) and a downstream Query exchange (where
   the node is the responder).  If the SIDs are different, these items
   of routing state MUST be considered as independent; if the SIDs
   match, the routing state installed by the downstream exchange MUST
   take precedence, provided that the downstream Query passed ingress
   filtering checks.  The rationale for this is that the downstream
   Query is in general a more reliable way to install state, since it
   directly probes the IP routing infrastructure along the flow path,
   whereas use of the upstream Query depends on the correctness of the
   Querying node's understanding of the topology.

   The details of the encapsulation are as follows:

   o  The destination address SHOULD be the flow source address as given
      in the MRI of the message payload.  An implementation with more
      detailed knowledge of local IP routing MAY use an alternative
      destination address (e.g., the address of its default router).

   o  The source address SHOULD be the signalling node address, so in
      the common header S=1.

   o  A Router Alert Option is included as in the downstream case.

   o  The Diffserv codepoint and (for IPv6) flow label MAY be set to
      match the values from the MRI as in the downstream case, and the
      UDP port selection is also the same.

   o  The IP layer TTL of the message MUST be set to 255.

   The sending GIST implementation SHOULD attempt to send the Query via
   the same interface and to the same link layer neighbour from which
   the data packets of the flow are arriving.

   The receiving GIST node MAY apply validation checks to the message
   and MRI, to reject Query messages that have reached a node at which
   they can no longer be trusted.  In particular, a node SHOULD reject a
   message that has been propagated more than one IP hop, with an
   "Invalid IP layer TTL" error message (Appendix A.4.4.11).  This can
   be determined by examining the received IP layer TTL, similar to the
   generalised IP TTL security mechanism described in [41].
Top   ToC   RFC5971 - Page 70
   Alternatively, receipt of an upstream Query at the flow source MAY be
   used to trigger setup of GIST state in the downstream direction.
   These restrictions may be relaxed in a future version.

5.8.2. The Loose-End MRM

The Loose-End MRM is used to discover GIST nodes with particular properties in the direction of a given address, for example, to discover a NAT along the upstream data path as in [34]. Message Routing Information
For the loose-end MRM, only a simplified version of the Flow Identifier is needed. MRI = network-layer-version source-address destination-address The source address is the address of the node initiating the discovery process, for example, the node that will be the data receiver in the NAT discovery case. The destination address is the address of a node that is expected to be the other side of the node to be discovered. Additional control information defines the direction of the message relative to this flow as in the path-coupled case. Downstream Q-mode Encapsulation
Only one encapsulation is defined for the loose-end MRM; by convention, this is referred to as the downstream encapsulation, and is defined as follows: o The IP destination address MUST be the destination address as given in the MRI of the message payload. o By default, the IP source address is the source address from the MRI (S=0). However, the use of the signalling source address (S=1) is allowed as in the case of the path-coupled MRM. A Router Alert Option is included in the IP header. The option value depends on the NSLP being signalled for. There are no special requirements on the setting of the Diffserv codepoint, IP layer TTL, or (for IPv6) the flow label. Nor are any special validation checks applied.

(next page on part 4)

Next Section