Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 5971

GIST: General Internet Signalling Transport

Pages: 154
Part 2 of 6 – Pages 20 to 45
First   Prev   Next

Top   ToC   RFC5971 - Page 20   prevText

4. GIST Processing Overview

This section defines the basic structure and operation of GIST. Section 4.1 describes the way in which GIST interacts with local signalling applications in the form of an abstract service interface. Section 4.2 describes the per-flow and per-peer state that GIST maintains for the purpose of transferring messages. Section 4.3 describes how messages are processed in the case where any necessary messaging associations and routing state already exist; this includes
Top   ToC   RFC5971 - Page 21
   the simple scenario of pure D-mode operation, where no messaging
   associations are necessary.  Finally, Section 4.4 describes how
   routing state and messaging associations are created and managed.

4.1. GIST Service Interface

This section describes the interaction between GIST and signalling applications in terms of an abstract service interface, including a definition of the attributes of the message transfer that GIST can offer. The service interface presented here is non-normative and does not constrain actual implementations of any interface between GIST and signalling applications; the interface is provided to aid understanding of how GIST can be used. However, requirements on SID selection and internal GIST behaviour to support message transfer semantics (such as in-order delivery) are stated normatively here. The same service interface is presented at every GIST node; however, applications may invoke it differently at different nodes, depending for example on local policy. In addition, the service interface is defined independently of any specific transport protocol, or even the distinction between D-mode and C-mode. The initial version of this specification defines how to support the service interface using a C-mode based on TCP; if additional protocol support is added, this will support the same interface and so the change will be invisible to applications, except as a possible performance improvement. A more detailed description of this service interface is given in Appendix B.

4.1.1. Message Handling

Fundamentally, GIST provides a simple message-by-message transfer service for use by signalling applications: individual messages are sent, and individual messages are received. At the service interface, the NSLP payload, which is opaque to GIST, is accompanied by control information expressing the application's requirements about how the message should be routed (the MRI), and the application also provides the session identifier (SID); see Section 4.1.3. Additional message transfer attributes control the specific transport and security properties that the signalling application desires. The distinction between GIST D- and C-mode is not visible at the service interface. In addition, the functionality to handle fragmentation and reassembly, bundling together of small messages for efficiency, and congestion control are not visible at the service interface; GIST will take whatever action is necessary based on the properties of the messages and local node state.
Top   ToC   RFC5971 - Page 22
   A signalling application is free to choose the rate at which it
   processes inbound messages; an implementation MAY allow the
   application to block accepting messages from GIST.  In these
   circumstances, GIST MAY discard unreliably delivered messages, but
   for reliable messages MUST propagate flow-control condition back to
   the sender.  Therefore, applications must be aware that they may in
   turn be blocked from sending outbound messages themselves.

4.1.2. Message Transfer Attributes

Message transfer attributes are used by NSLPs to define minimum required levels of message processing. The attributes available are as follows: Reliability: This attribute may be 'true' or 'false'. When 'true', the following rules apply: * messages MUST be delivered to the signalling application in the peer exactly once or not at all; * for messages with the same SID, the delivery MUST be in order; * if there is a chance that the message was not delivered (e.g., in the case of a transport layer error), an error MUST be indicated to the local signalling application identifying the routing information for the message in question. GIST implements reliability by using an appropriate transport protocol within a messaging association, so mechanisms for the detection of message loss depend on the protocol in question; for the current specification, the case of TCP is considered in Section 5.7.2. When 'false', a message may be delivered, once, several times, or not at all, with no error indications in any of these cases. Security: This attribute defines the set of security properties that the signalling application requires for the message, including the type of protection required, and what authenticated identities should be used for the signalling source and destination. This information maps onto the corresponding properties of the security associations established between the peers in C-mode. Keying material for the security associations is established by the authentication mechanisms within the messaging association protocols themselves; see Section 8.2. The attribute can be specified explicitly by the signalling application, or reported by GIST to the signalling application. The latter can take place
Top   ToC   RFC5971 - Page 23
      either on receiving a message, or just before sending a message
      but after configuring or selecting the messaging association to be
      used for it.

      This attribute can also be used to convey information about any
      address validation carried out by GIST, such as whether a return
      routability check has been carried out.  Further details are
      discussed in Appendix B.

   Local Processing:  An NSLP may provide hints to GIST to enable more
      efficient or appropriate processing.  For example, the NSLP may
      select a priority from a range of locally defined values to
      influence the sequence in which messages leave a node.  Any
      priority mechanism MUST respect the ordering requirements for
      reliable messages within a session, and priority values are not
      carried in the protocol or available at the signalling peer or
      intermediate nodes.  An NSLP may also indicate that upstream path
      routing state will not be needed for this flow, to inhibit the
      node requesting its downstream peer to create it; conversely, even
      if routing state exists, the NSLP may request that it is not used,
      which will lead to GIST Data messages being sent Q-mode
      encapsulated instead.

   A GIST implementation MAY deliver messages with stronger attribute
   values than those explicitly requested by the application.

4.1.3. SID Selection

The fact that SIDs index routing state (see Section 4.2.1 below) means that there are requirements for how they are selected. Specifically, signalling applications MUST choose SIDs so that they are cryptographically random, and SHOULD NOT use several SIDs for the same flow, to avoid additional load from routing state maintenance. Guidance on secure randomness generation can be found in [31].

4.2. GIST State

4.2.1. Message Routing State

For each flow, the GIST layer can maintain message routing state to manage the processing of outgoing messages. This state is conceptually organised into a table with the following structure. Each row in the table corresponds to a unique combination of the following three items:
Top   ToC   RFC5971 - Page 24
   Message Routing Information (MRI):  This defines the method to be
      used to route the message, the direction in which to send the
      message, and any associated addressing information; see
      Section 3.3.

   Session Identifier (SID):  The signalling session with which this
      message should be associated; see Section 3.7.

   NSLP Identifier (NSLPID):  This is an IANA-assigned identifier
      associated with the NSLP that is generating messages for this
      flow; see Section 3.8.  The inclusion of this identifier allows
      the routing state to be different for different NSLPs.

   The information associated with a given MRI/SID/NSLPID combination
   consists of the routing state to reach the peer in the direction
   given by the MRI.  For any flow, there will usually be two entries in
   the table, one each for the upstream and downstream MRI.  The routing
   state includes information about the peer identity (see
   Section 4.4.3), and a UDP port number for D-mode, or a reference to
   one or more MAs for C-mode.  Entries in the routing state table are
   created by the GIST handshake, which is described in more detail in
   Section 4.4.

   It is also possible for the state information for either direction to
   be empty.  There are several possible cases:

   o  The signalling application has indicated that no messages will
      actually be sent in that direction.

   o  The node is the endpoint of the signalling path, for example,
      because it is acting as a proxy, or because it has determined that
      there are no further signalling nodes in that direction.

   o  The node is using other techniques to route the message.  For
      example, it can send it in Q-mode and rely on the peer to
      intercept it.

   In particular, if the node is a flow endpoint, GIST will refuse to
   create routing state for the direction beyond the end of the flow
   (see Section 4.3.3).  Each entry in the routing state table has an
   associated validity timer indicating for how long it can be
   considered accurate.  When this timer expires, the entry MUST be
   purged if it has not been refreshed.  Installation and maintenance of
   routing state are described in more detail in Section 4.4.
Top   ToC   RFC5971 - Page 25

4.2.2. Peer-Peer Messaging Association State

The per-flow message routing state is not the only state stored by GIST. There is also the state required to manage the MAs. Since these are not per-flow, they are stored separately from the routing state, including the following per-MA information: o a queue of any messages that require the use of an MA, pending transmission while the MA is being established; o the time since the peer re-stated its desire to keep the MA open (see Section 4.4.5). In addition, per-MA state, such as TCP port numbers or timer information, is held in the messaging association protocols themselves. However, the details of this state are not directly visible to GIST, and they do not affect the rest of the protocol description.

4.3. Basic GIST Message Processing

This section describes how signalling application messages are processed in the case where any necessary messaging associations and routing state are already in place. The description is divided into several parts. First, message reception, local processing, and message transmission are described for the case where the node hosts the NSLPID identified in the message. Second, in Section 4.3.4, the case where the message is handled directly in the IP or GIST layer (because there is no matching signalling application on the node) is given. An overview is given in Figure 4. This section concentrates on the GIST-level processing, with full details of IP and transport layer encapsulation in Section 5.3 and Section 5.4.
Top   ToC   RFC5971 - Page 26
       |        >>  Signalling Application Processing   >>       |
       |                                                         |
                ^ NSLP                             NSLP V
                ^ Payloads                     Payloads V
       |                    >>    GIST    >>                     |
       |  ^           ^  ^     Processing      V  V           V  |
          x           N  Q                     Q  N           x
          x           N  Q>>>>>>>>>>>>>>>>>>>>>Q  N           x
          x           N  Q      Bypass at      Q  N           x
       +--x-----+  +--N--Q--+  GIST level   +--Q--N--+  +-----x--+
       | C-mode |  | D-mode |               | D-mode |  | C-mode |
       |Handling|  |Handling|               |Handling|  |Handling|
       +--x-----+  +--N--Q--+               +--Q--N--+  +-----x--+
          x          N   Q                     Q   N          x
          x    NNNNNN    Q>>>>>>>>>>>>>>>>>>>>>Q    NNNNNN    x
          x   N          Q      Bypass at      Q          N   x
       +--x--N--+  +-----Q--+  IP (router   +--Q-----+  +--N--x--+
       |IP Host |  | Q-mode |  alert) level | Q-mode |  |IP Host |
       |Handling|  |Handling|               |Handling|  |Handling|
       +--x--N--+  +-----Q--+               +--Q-----+  +--N--x--+
          x  N           Q                     Q           N  x
       +--x--N-----------Q--+               +--Q-----------N--x--+
       |      IP Layer      |               |      IP Layer      |
       |   (Receive Side)   |               |  (Transmit Side)   |
       +--x--N-----------Q--+               +--Q-----------N--x--+
          x  N           Q                     Q           N  x
          x  N           Q                     Q           N  x

        NNNNNNNNNNNNNN = Normal D-mode messages
        QQQQQQQQQQQQQQ = D-mode messages that are Q-mode encapsulated
        xxxxxxxxxxxxxx = C-mode messages
                       RAO = Router Alert Option

                Figure 4: Message Paths through a GIST Node

4.3.1. Message Reception

Messages can be received in C-mode or D-mode. Reception in C-mode is simple: incoming packets undergo the security and transport treatment associated with the MA, and the MA provides complete messages to the GIST layer for further processing. Reception in D-mode depends on the message type.
Top   ToC   RFC5971 - Page 27
   Normal encapsulation:  Normal messages arrive UDP-encapsulated and
      addressed directly to the receiving signalling node, at an address
      and port learned previously.  Each datagram contains a single
      message, which is passed to the GIST layer for further processing,
      just as in the C-mode case.

   Q-mode encapsulation:  Where GIST is sending messages to be
      intercepted by the appropriate peer rather than directly addressed
      to it (in particular, Query messages), these are UDP encapsulated,
      and MAY include an IP Router Alert Option (RAO) if required by the
      MRM.  Each GIST node can therefore see every such message, but
      unless the message exactly matches the Q-mode encapsulation rules
      (Section 5.3.2) it MUST be forwarded transparently at the IP
      level.  If it does match, GIST MUST check the NSLPID in the common
      header.  The case where the NSLPID does not match a local
      signalling application at all is considered below in
      Section 4.3.4; otherwise, the message MUST be passed up to the
      GIST layer for further processing.

   Several different RAO values may be used by the NSIS protocol suite.
   GIST itself does not allocate any RAO values (for either IPv4 or
   IPv6); an assignment is made for each NSLP using MRMs that use the
   RAO in the Q-mode encapsulation.  The assignment rationale is
   discussed in a separate document [12].  The RAO value assigned for an
   NSLPID may be different for IPv4 and IPv6.  Note the different
   significance between the RAO and the NSLPID values: the meaning of a
   message (which signalling application it refers to, whether it should
   be processed at a node) is determined only from the NSLPID; the role
   of the RAO value is simply to allow nodes to pre-filter which IP
   datagrams are analysed to see if they might be Q-mode GIST messages.

   For all assignments associated with NSIS, the RAO-specific processing
   is the same and is as defined by this specification, here and in
   Section 4.3.4 and Section 5.3.2.

   Immediately after reception, the GIST hop count is checked.  Any
   message with a GIST hop count of zero MUST be rejected with a "Hop
   Limit Exceeded" error message (Appendix A.4.4.2); note that a correct
   GIST implementation will never send a message with a GIST hop count
   of zero.  Otherwise, the GIST hop count MUST be decremented by one
   before the next stage.

4.3.2. Local Processing and Validation

Once a message has been received, it is processed locally within the GIST layer. Further processing depends on the message type and payloads carried; most of the GIST payloads are associated with internal state maintenance, and details are covered in Section 4.4.
Top   ToC   RFC5971 - Page 28
   This section concentrates on the interaction with the signalling
   application, in particular, the decision to peer and how data is
   delivered to the NSLP.

   In the case of a Query, there is an interaction with the signalling
   application to determine which of two courses to follow.  The first
   option (peering) MUST be chosen if the node is the final destination
   of the Query message.

   1.  The receiving signalling application wishes to become a
       signalling peer with the Querying node.  GIST MUST continue with
       the handshake process to set up message routing state, as
       described in Section 4.4.1.  The application MAY provide an NSLP
       payload for the same NSLPID, which GIST will transfer in the

   2.  The signalling application does not wish to set up state with the
       Querying node and become its peer.  This includes the case where
       a node wishes to avoid taking part in the signalling for overload
       protection reasons.  GIST MUST propagate the Query, similar to
       the case described in Section 4.3.4.  No message is sent back to
       the Querying node.  The application MAY provide an updated NSLP
       payload for the same NSLPID, which will be used in the Query
       forwarded by GIST.  Note that if the node that finally processes
       the Query returns an Error message, this will be sent directly
       back to the originating node, bypassing any forwarders.  For
       these diagnostics to be meaningful, any GIST node forwarding a
       Query, or relaying it with modified NSLP payload, MUST NOT modify
       it except in the GIST hop count; in particular, it MUST NOT
       modify any other GIST payloads or their order.  An implementation
       MAY choose to achieve this by retaining the original message,
       rather than reconstructing it from some parsed internal

   This interaction with the signalling application, including the
   generation or update of an NSLP payload, SHOULD take place
   synchronously as part of the Query processing.  In terms of the GIST
   service interface, this can be implemented by providing appropriate
   return values for the primitive that is triggered when such a message
   is received; see Appendix B.2 for further discussion.

   For all GIST message types other than Queries, if the message
   includes an NSLP payload, this MUST be delivered locally to the
   signalling application identified by the NSLPID.  The format of the
   payload is not constrained by GIST, and the content is not
   interpreted.  Delivery is subject to the following validation checks,
   which MUST be applied in the sequence given:
Top   ToC   RFC5971 - Page 29
   1.  if the message was explicitly routed (see Section 7.1.5) or is a
       Data message delivered without routing state (see Section 5.3.2),
       the payload is delivered but flagged to the receiving NSLP to
       indicate that routing state was not validated;

   2.  else, if the message arrived on an association that is not
       associated with the MRI/NSLPID/SID combination given in the
       message, the message MUST be rejected with an "Incorrectly
       Delivered Message" error message (Appendix A.4.4.4);

   3.  else, if there is no routing state for this MRI/SID/NSLPID
       combination, the message MUST either be dropped or be rejected
       with an error message (see Section 4.4.6 for further details);

   4.  else, the payload is delivered as normal.

4.3.3. Message Transmission

Signalling applications can generate their messages for transmission, either asynchronously or in reply to an input message delivered by GIST, and GIST can also generate messages autonomously. GIST MUST verify that it is not the direct destination of an outgoing message, and MUST reject such messages with an error indication to the signalling application. When the message is generated by a signalling application, it may be carried in a Query if local policy and the message transfer attributes allow it; otherwise, this may trigger setup of an MA over which the NSLP payload is sent in a Data message. Signalling applications may specify a value to be used for the GIST hop count; otherwise, GIST selects a value itself. GIST MUST reject messages for which the signalling application has specified a value of zero. Although the GIST hop count is only intended to control message looping at the GIST level, the GIST API (Appendix B) provides the incoming hop count to the NSLPs, which can preserve it on outgoing messages as they are forwarded further along the path. This provides a lightweight loop-control mechanism for NSLPs that do not define anything more sophisticated. Note that the count will be decremented on forwarding through every GIST-aware node. Initial values for the GIST hop count are an implementation matter; one suitable approach is to use the same algorithm as for IP TTL setting [1]. When a message is available for transmission, GIST uses internal policy and the stored routing state to determine how to handle it. The following processing applies equally to locally generated messages and messages forwarded from within the GIST or signalling
Top   ToC   RFC5971 - Page 30
   application levels.  However, see Section 5.6 for special rules
   applying to the transmission of Error messages by GIST.

   The main decision is whether the message must be sent in C-mode or
   D-mode.  Reasons for using C-mode are:

   o  message transfer attributes: for example, the signalling
      application has specified security attributes that require
      channel-secured delivery, or reliable delivery.

   o  message size: a message whose size (including the GIST header,
      GIST objects and any NSLP payload, and an allowance for the IP and
      transport layer encapsulation required by D-mode) exceeds a
      fragmentation-related threshold MUST be sent over C-mode, using a
      messaging association that supports fragmentation and reassembly
      internally.  The allowance for IP and transport layer
      encapsulation is 64 bytes.  The message size MUST NOT exceed the
      Path MTU to the next peer, if this is known.  If this is not
      known, the message size MUST NOT exceed the least of the first-hop
      MTU, and 576 bytes.  The same limit applies to IPv4 and IPv6.

   o  congestion control: D-mode SHOULD NOT be used for signalling where
      it is possible to set up routing state and use C-mode, unless the
      network can be engineered to guarantee capacity for D-mode traffic
      within the rate control limits imposed by GIST (see
      Section 5.3.3).

   In principle, as well as determining that some messaging association
   must be used, GIST MAY select between a set of alternatives, e.g.,
   for load sharing or because different messaging associations provide
   different transport or security attributes.  For the case of reliable
   delivery, GIST MUST NOT distribute messages for the same session over
   multiple messaging associations in parallel, but MUST use a single
   association at any given time.  The case of moving over to a new
   association is covered in Section 4.4.5.

   If the use of a messaging association (i.e., C-mode) is selected, the
   message is queued on the association found from the routing state
   table, and further output processing is carried out according to the
   details of the protocol stacks used.  If no appropriate association
   exists, the message is queued while one is created (see
   Section 4.4.1), which will trigger the exchange of additional GIST
   messages.  If no association can be created, this is an error
   condition, and should be indicated back to the local signalling
Top   ToC   RFC5971 - Page 31
   If a messaging association is not appropriate, the message is sent in
   D-mode.  The processing in this case depends on the message type,
   local policy, and whether or not routing state exists.

   o  If the message is not a Query, and local policy does not request
      the use of Q-mode for this message, and routing state exists, it
      is sent with the normal D-mode encapsulation directly to the
      address from the routing state table.

   o  If the message is a Query, or the message is Data and local policy
      as given by the message transfer attributes requests the use of
      Q-mode, then it is sent in Q-mode as defined in Section 5.3.2; the
      details depend on the message routing method.

   o  If no routing state exists, GIST can attempt to use Q-mode as in
      the Query case: either sending a Data message with the Q-mode
      encapsulation or using the event as a trigger for routing state
      setup (see Section 4.4).  If this is not possible, e.g., because
      the encapsulation for the MRM is only defined for one message
      direction, then this is an error condition that is reported back
      to the local signalling application.

4.3.4. Nodes not Hosting the NSLP

A node may receive messages where it has no signalling application corresponding to the message NSLPID. There are several possible cases depending mainly on the encapsulation: 1. A message contains an RAO value that is relevant to NSIS, but it does not exactly match the Q-mode encapsulation rules of Section 5.3.2. The message MUST be transparently forwarded at the IP layer. See Section 3.6. 2. A Q-mode encapsulated message contains an RAO value that has been assigned to some NSIS signalling application but that is not used on this specific node, but the IP layer is unable to distinguish whether it needs to be passed to GIST for further processing or whether the packet should be forwarded just like a normal IP datagram. 3. A Q-mode encapsulated message contains an RAO value that has been assigned to an NSIS signalling application that is used on this node, but the signalling application does not process the NSLPID in the message. (This covers the case where a signalling application uses a set of NSLPIDs.)
Top   ToC   RFC5971 - Page 32
   4.  A directly addressed message (in D-mode or C-mode) is delivered
       to a node for which there is no corresponding signalling
       application.  With the current specification, this should not
       happen in normal operation.  While future versions might find a
       use for such a feature, currently this MUST cause an "Unknown
       NSLPID" error message (Appendix A.4.4.6).

   5.  A Q-mode encapsulated message arrives at the end-system that does
       not handle the signalling application.  This is possible in
       normal operation, and MUST be indicated to the sender with an
       "Endpoint Found" informational message (Appendix A.4.4.7).  The
       end-system includes the MRI and SID from the original message in
       the error message without interpreting them.

   6.  The node is a GIST-aware NAT.  See Section 7.2.

   In case (2) and (3), the role of GIST is to forward the message
   essentially as though it were a normal IP datagram, and it will not
   become a peer to the node sending the message.  Forwarding with
   modified NSLP payloads is covered above in Section 4.3.2.  However, a
   GIST implementation MUST ensure that the IP-layer TTL field and GIST
   hop count are managed correctly to prevent message looping, and this
   should be done consistently independently of where in the packet
   processing path the decision is made.  The rules are that in cases
   (2) and (3), the IP-layer TTL MUST be decremented just as if the
   message was a normal IP forwarded packet.  In case (3), the GIST hop
   count MUST be decremented as in the case of normal input processing,
   which also applies to cases (4) and (5).

   A GIST node processing Q-mode encapsulated messages in this way
   SHOULD make the routing decision based on the full contents of the
   MRI and not only the IP destination address.  It MAY also apply a
   restricted set of sanity checks and under certain conditions return
   an error message rather than forward the message.  These conditions

   1.  The message is so large that it would be fragmented on downstream
       links, for example, because the downstream MTU is abnormally
       small (less than 576 bytes).  The error "Message Too Large"
       (Appendix A.4.4.8) SHOULD be returned to the sender, which SHOULD
       begin messaging association setup.

   2.  The GIST hop count has reached zero.  The error "Hop Limit
       Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender,
       which MAY retry with a larger initial hop count.
Top   ToC   RFC5971 - Page 33
   3.  The MRI represents a flow definition that is too general to be
       forwarded along a unique path (e.g., the destination address
       prefix is too short).  The error "MRI Validation Failure"
       (Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be
       returned to the sender, which MAY retry with restricted MRIs,
       possibly starting additional signalling sessions to do so.  If
       the GIST node does not understand the MRM in question, it MUST
       NOT apply this check, instead forwarding the message

   In the first two cases, only the common header of the GIST message is
   examined; in the third case, the MRI is also examined.  The rest of
   the message MUST NOT be inspected in any case.  Similar to the case
   of Section 4.3.2, the GIST payloads MUST NOT be modified or re-
   ordered; an implementation MAY choose to achieve this by retaining
   the original message, rather than reconstructing it from some parsed
   internal representation.

4.4. Routing State and Messaging Association Maintenance

The main responsibility of GIST is to manage the routing state and messaging associations that are used in the message processing described above. Routing state is installed and refreshed by GIST handshake messages. Messaging associations are set up by the normal procedures of the transport and security protocols that comprise them, using peer IP addresses from the routing state. Once a messaging association has been created, its refresh and expiration can be managed independently from the routing state. There are two different cases for state installation and refresh: 1. Where routing state is being discovered or a new association is to be established; and 2. Where a suitable association already exists, including the case where routing state for the flow is being refreshed. These cases are now considered in turn, followed by the case of background general management procedures.

4.4.1. Routing State and Messaging Association Creation

The message sequence for GIST state setup between peers is shown in Figure 5 and described in detail below. The figure informally summarises the contents of each message, including optional elements in square brackets. An example is given in Appendix D.
Top   ToC   RFC5971 - Page 34
   The first message in any routing state maintenance operation is a
   Query, sent from the Querying node and intercepted at the responding
   node.  This message has addressing and other identifiers appropriate
   for the flow and signalling application that state maintenance is
   being done for, addressing information about the node that generated
   the Query itself, and MAY contain an NSLP payload.  It also includes
   a Query-Cookie, and optionally capability information about messaging
   association protocol stacks.  The role of the cookies in this and
   later messages is to protect against certain denial-of-service
   attacks and to correlate the events in the message sequence (see
   Section 8.5 for further details).
Top   ToC   RFC5971 - Page 35
            +----------+                     +----------+
            | Querying |                     |Responding|
            | Node(Q-N)|                     | Node(R-N)|
            +----------+                     +----------+
                               Query                  .............
                       ---------------------->        .           .
                       Router Alert Option            .  Routing  .
                       MRI/SID/NSLPID                 .   state   .
                       Q-N Network Layer Info         . installed .
                       Query-Cookie                   .    at     .
                       [Q-N Stack-Proposal            . Responding.
                        Q-N Stack-Config-Data]        .    node   .
                       [NSLP Payload]                 .  (case 1) .
               .  The responder can use an existing .
               . messaging association if available .
               . from here onwards to short-circuit .
               .     messaging association setup    .

   .............       <----------------------
   .  Routing  .       MRI/SID/NSLPID
   .   state   .       R-N Network Layer Info
   . installed .       Query-Cookie
   .    at     .       [Responder-Cookie
   .  Querying .        [R-N Stack-Proposal
   .   node    .         R-N Stack-Config-Data]]
   .............       [NSLP Payload]

                . If a messaging association needs .
                . to be created, it is set up here .
                .     and the Confirm uses it      .

                           Confirm                    .............
                     ---------------------->          .  Routing  .
                     MRI/SID/NSLPID                   .   state   .
                     Q-N Network Layer Info           . installed .
                     [Responder-Cookie                .    at     .
                      [R-N Stack-Proposal             . Responding.
                       [Q-N Stack-Config-Data]]]      .    node   .
                     [NSLP Payload]                   .  (case 2) .

                 Figure 5: Message Sequence at State Setup
Top   ToC   RFC5971 - Page 36
   Provided that the signalling application has indicated that message
   routing state should be set up (see Section 4.3.2), reception of a
   Query MUST elicit a Response.  This is a normally encapsulated D-mode
   message with additional GIST payloads.  It contains network layer
   information about the Responding node, echoes the Query-Cookie, and
   MAY contain an NSLP payload, possibly a reply to the NSLP payload in
   the initial message.  In case a messaging association was requested,
   it MUST also contain a Responder-Cookie and its own capability
   information about messaging association protocol stacks.  Even if a
   messaging association is not requested, the Response MAY still
   include a Responder-Cookie if the node's routing state setup policy
   requires it (see below).

   Setup of a new messaging association begins when peer addressing
   information is available and a new messaging association is actually
   needed.  Any setup MUST take place immediately after the specific
   Query/Response exchange, because the addressing information used may
   have a limited lifetime, either because it depends on limited
   lifetime NAT bindings or because it refers to agile destination ports
   for the transport protocols.  The Stack-Proposal and Stack-
   Configuration-Data objects carried in the exchange carry capability
   information about what messaging association protocols can be used,
   and the processing of these objects is described in more detail in
   Section 5.7.  With the protocol options currently defined, setup of
   the messaging association always starts from the Querying node,
   although more flexible configurations are possible within the overall
   GIST design.  If the messaging association includes a channel
   security protocol, each GIST node MUST verify the authenticated
   identity of the peer against its authorised peer database, and if
   there is no match the messaging association MUST be torn down.  The
   database and authorisation check are described in more detail in
   Section 4.4.2 below.  Note that the verification can depend on what
   the MA is to be used for (e.g., for which MRI or session), so this
   step may not be possible immediately after authentication has
   completed but some time later.

   Finally, after any necessary messaging association setup has
   completed, a Confirm MUST be sent if the Response requested it.  Once
   the Confirm has been sent, the Querying node assumes that routing
   state has been installed at the responder, and can send normal Data
   messages for the flow in question; recovery from a lost Confirm is
   discussed in Section 5.3.3.  If a messaging association is being
   used, the Confirm MUST be sent over it before any other messages for
   the same flow, and it echoes the Responder-Cookie and Stack-Proposal
   from the Response.  The former is used to allow the receiver to
   validate the contents of the message (see Section 8.5), and the
   latter is to prevent certain bidding-down attacks on messaging
   association security (see Section 8.6).  This first Confirm on a new
Top   ToC   RFC5971 - Page 37
   association MUST also contain a Stack-Configuration-Data object
   carrying an MA-Hold-Time value, which supersedes the value given in
   the original Query.  The association can be used in the upstream
   direction for the MRI and NSLPID carried in the Confirm, after the
   Confirm has been received.

   The Querying node MUST install the responder address, derived from
   the R-Node Network Layer info, as routing state information after
   verifying the Query-Cookie in the Response.  The Responding node MAY
   install the querying address as peer state information at two points
   in time:

   Case 1:  after the receipt of the initial Query, or

   Case 2:  after a Confirm containing the Responder-Cookie.

   The Responding node SHOULD derive the peer address from the Q-Node
   Network Layer Info if this was decoded successfully.  Otherwise, it
   MAY be derived from the IP source address of the message if the
   common header flags this as being the signalling source address.  The
   precise constraints on when state information is installed are a
   matter of security policy considerations on prevention of denial-of-
   service attacks and state poisoning attacks, which are discussed
   further in Section 8.  Because the Responding node MAY choose to
   delay state installation as in case (2), the Confirm must contain
   sufficient information to allow it to be processed in the same way as
   the original Query.  This places some special requirements on NAT
   traversal and cookie functionality, which are discussed in
   Section 7.2 and Section 8 respectively.

4.4.2. GIST Peer Authorisation

When two GIST nodes authenticate using a messaging association, both ends have to decide whether to accept the creation of the MA and whether to trust the information sent over it. This can be seen as an authorisation decision: o Authorised peers are trusted to install correct routing state about themselves and not, for example, to claim that they are on- path for a flow when they are not. o Authorised peers are trusted to obey transport- and application- level flow control rules, and not to attempt to create overload situations. o Authorised peers are trusted not to send erroneous or malicious error messages, for example, asserting that routing state has been lost when it has not.
Top   ToC   RFC5971 - Page 38
   This specification models the decision as verification by the
   authorising node of the peer's identity against a local list of
   peers, the authorised peer database (APD).  The APD is an abstract
   construct, similar to the security policy database of IPsec [36].
   Implementations MAY provide the associated functionality in any way
   they choose.  This section defines only the requirements for APD
   administration and the consequences of successfully validating a
   peer's identity against it.

   The APD consists of a list of entries.  Each entry includes an
   identity, the namespace from which the identity comes (e.g., DNS
   domains), the scope within which the entry is applicable, and whether
   authorisation is allowed or denied.  The following are example

   Peer Address Ownership:  The scope is the IP address at which the
      peer for this MRI should be; the APD entry denotes the identity as
      the owner of address.  If the authorising node can determine this
      address from local information (such as its own routing tables),
      matching this entry shows that the peer is the correct on-path
      node and so should be authorised.  The determination is simple if
      the peer is one IP hop downstream, since the IP address can be
      derived from the router's forwarding tables.  If the peer is more
      than one hop away or is upstream, the determination is harder but
      may still be possible in some circumstances.  The authorising node
      may be able to determine a (small) set of possible peer addresses,
      and accept that any of these could be the correct peer.

   End-System Subnet:  The scope is an address range within which the
      MRI source or destination lies; the APD entry denotes the identity
      as potentially being on-path between the authorising node and that
      address range.  There may be different source and destination
      scopes, to account for asymmetric routing.

   The same identity may appear in multiple entries, and the order of
   entries in the APD is significant.  When a messaging association is
   authenticated and associated with an MRI, the authorising node scans
   the APD to find the first entry where the identity matches that
   presented by the peer, and where the scope information matches the
   circumstances for which the MA is being set up.  The identity
   matching process itself depends on the messaging association protocol
   that carries out the authentication, and details for TLS are given in
   Section 5.7.3.  Whenever the full set of possible peers for a
   specific scope is known, deny entries SHOULD be added for the
   wildcard identity to reject signalling associations from unknown
   nodes.  The ability of the authorising node to reject inappropriate
   MAs depends directly on the granularity of the APD and the precision
   of the scope matching process.
Top   ToC   RFC5971 - Page 39
   If authorisation is allowed, the MA can be used as normal; otherwise,
   it MUST be torn down without further GIST exchanges, and any routing
   state associated with the MA MUST also be deleted.  An error
   condition MAY be logged locally.  When an APD entry is modified or
   deleted, the node MUST re-validate existing MAs and the routing state
   table against the revised contents of the APD.  This may result in
   MAs being torn down or routing state entries being deleted.  These
   changes SHOULD be indicated to local signalling applications via the
   NetworkNotification API call (Appendix B.4).

   This specification does not define how the APD is populated.  As a
   minimum, an implementation MUST provide an administrative interface
   through which entries can be added, modified, or deleted.  More
   sophisticated mechanisms are possible in some scenarios.  For
   example, the fact that a node is legitimately associated with a
   specific IP address could be established by direct embedding of the
   IP address as a particular identity type in a certificate, or by a
   mapping that address to another identifier type via an additional
   database lookup (such as relating IP addresses in to
   domain names).  An enterprise network operator could generate a list
   of all the identities of its border nodes as authorised to be on the
   signalling path to external destinations, and this could be
   distributed to all hosts inside the network.  Regardless of the
   technique, it MUST be ensured that the source data justify the
   authorisation decisions listed at the start of this section, and that
   the security of the chain of operations on which the APD entry
   depends cannot be compromised.

4.4.3. Messaging Association Multiplexing

It is a design goal of GIST that, as far as possible, a single messaging association should be used for multiple flows and sessions between two peers, rather than setting up a new MA for each. This re-use of existing MAs is referred to as messaging association multiplexing. Multiplexing ensures that the MA cost scales only with the number of peers, and avoids the latency of new MA setup where possible. However, multiplexing requires the identification of an existing MA that matches the same routing state and desired properties that would be the result of a normal handshake in D-mode, and this identification must be done as reliably and securely as continuing with a normal D-mode handshake. Note that this requirement is complicated by the fact that NATs may remap the node addresses in D-mode messages, and also interacts with the fact that some nodes may peer over multiple interfaces (and thus with different addresses).
Top   ToC   RFC5971 - Page 40
   MA multiplexing is controlled by the Network Layer Information (NLI)
   object, which is carried in Query, Response, and Confirm messages.
   The NLI object includes (among other elements):

   Peer-Identity:  For a given node, this is an interface-independent
      value with opaque syntax.  It MUST be chosen so as to have a high
      probability of uniqueness across the set of all potential peers,
      and SHOULD be stable at least until the next node restart.  Note
      that there is no cryptographic protection of this identity;
      attempting to provide this would essentially duplicate the
      functionality in the messaging association security protocols.
      For routers, the Router-ID [2], which is one of the router's IP
      addresses, MAY be used as one possible value for the Peer-
      Identity.  In scenarios with nested NATs, the Router-ID alone may
      not satisfy the uniqueness requirements, in which case it MAY be
      extended with additional tokens, either chosen randomly or
      administratively coordinated.

   Interface-Address:  This is an IP address through which the
      signalling node can be reached.  There may be several choices
      available for the Interface-Address, and further discussion of
      this is contained in Section 5.2.2.

   A messaging association is associated with the NLI object that was
   provided by the peer in the Query/Response/Confirm at the time the
   association was first set up.  There may be more than one MA for a
   given NLI object, for example, with different security or transport

   MA multiplexing is achieved by matching these two elements from the
   NLI provided in a new GIST message with one associated with an
   existing MA.  The message can be either a Query or Response, although
   the former is more likely:

   o  If there is a perfect match to an existing association, that
      association SHOULD be re-used, provided it meets the criteria on
      security and transport properties given at the end of
      Section 5.7.1.  This is indicated by sending the remaining
      messages in the handshake over that association.  This will lead
      to multiplexing on an association to the wrong node if signalling
      nodes have colliding Peer-Identities and one is reachable at the
      same Interface-Address as another.  This could be caused by an on-
      path attacker; on-path attacks are discussed further in
      Section 8.7.  When multiplexing is done, and the original MA
      authorisation was MRI-dependent, the verification steps of
      Section 4.4.2 MUST be repeated for the new flow.
Top   ToC   RFC5971 - Page 41
   o  In all other cases, the handshake MUST be executed in D-mode as
      usual.  There are in fact four possibilities:

      1.  Nothing matches: this is clearly a new peer.

      2.  Only the Peer-Identity matches: this may be either a new
          interface on an existing peer or a changed address mapping
          behind a NAT.  These should be rare events, so the expense of
          a new association setup is acceptable.  Another possibility is
          one node using another node's Peer-Identity, for example, as
          some kind of attack.  Because the Peer-Identity is used only
          for this multiplexing process, the only consequence this has
          is to require a new association setup, and this is considered
          in Section 8.4.

      3.  Only the Interface-Address matches: this is probably a new
          peer behind the same NAT as an existing one.  A new
          association setup is required.

      4.  Both elements of the NLI object match: this is a degenerate
          case, where one node recognises an existing peer, but wishes
          to allow the option to set up a new association in any case,
          for example, to create an association with different

4.4.4. Routing State Maintenance

Each item of routing state expires after a lifetime that is negotiated during the Query/Response/Confirm handshake. The Network Layer Information (NLI) object in the Query contains a proposal for the lifetime value, and the NLI in the Response contains the value the Responding node requires. A default timer value of 30 seconds is RECOMMENDED. Nodes that can exploit alternative, more powerful, route change detection methods such as those described in Section 7.1.2 MAY choose to use much longer times. Nodes MAY use shorter times to provide more rapid change detection. If the number of active routing state items corresponds to a rate of Queries that will stress the rate limits applied to D-mode traffic (Section 5.3.3), nodes MUST increase the timer for new items and on the refresh of existing ones. A suitable value is 2 * (number of routing states) / (rate limit in packets/second) which leaves a factor of two headroom for new routing state creation and Query retransmissions.
Top   ToC   RFC5971 - Page 42
   The Querying node MUST ensure that a Query is received before this
   timer expires, if it believes that the signalling session is still
   active; otherwise, the Responding node MAY delete the state.  Receipt
   of the message at the Responding node will refresh peer addressing
   state for one direction, and receipt of a Response at the Querying
   node will refresh it for the other.  There is no mechanism at the
   GIST level for explicit teardown of routing state.  However, GIST
   MUST NOT refresh routing state if a signalling session is known to be
   inactive, either because upstream state has expired or because the
   signalling application has indicated via the GIST API (Appendix B.5)
   that the state is no longer required, because this would prevent
   correct state repair in the case of network rerouting at the IP

   This specification defines precisely only the time at which routing
   state expires; it does not define when refresh handshakes should be
   initiated.  Implementations MUST select timer settings that take at
   least the following into account:

   o  the transmission latency between source and destination;

   o  the need for retransmissions of Query messages;

   o  the need to avoid network synchronisation of control traffic (cf.

   In most cases, a reasonable policy is to initiate the routing state
   refresh when between 1/2 and 3/4 of the validity time has elapsed
   since the last successful refresh.  The actual moment MUST be chosen
   randomly within this interval to avoid synchronisation effects.

4.4.5. Messaging Association Maintenance

Unneeded MAs are torn down by GIST, using the teardown mechanisms of the underlying transport or security protocols if available, for example, by simply closing a TCP connection. The teardown can be initiated by either end. Whether an MA is needed is a combination of two factors: o local policy, which could take into account the cost of keeping the messaging association open, the level of past activity on the association, and the likelihood of future activity, e.g., if there is routing state still in place that might generate messages to use it. o whether the peer still wants the MA to remain in place. During MA setup, as part of the Stack-Configuration-Data, each node advertises its own MA-Hold-Time, i.e., the time for which it will
Top   ToC   RFC5971 - Page 43
      retain an MA that is not carrying signalling traffic.  A node MUST
      NOT tear down an MA if it has received traffic from its peer over
      that period.  A peer that has generated no traffic but still wants
      the MA retained can use a special null message (MA-Hello) to
      indicate the fact.  A default value for MA-Hold-Time of 30 seconds
      is RECOMMENDED.  Nodes MAY use shorter times to achieve more rapid
      peer failure detection, but need to take into account the load on
      the network created by the MA-Hello messages.  Nodes MAY use
      longer times, but need to take into account the cost of retaining
      idle MAs for extended periods.  Nodes MAY take signalling
      application behaviour (e.g., NSLP refresh times) into account in
      choosing an appropriate value.

      Because the Responding node can choose not to create state until a
      Confirm, an abbreviated Stack-Configuration-Data object containing
      just this information from the initial Query MUST be repeated by
      the Querying node in the first Confirm sent on a new MA.  If the
      object is missing in the Confirm, an "Object Type Error" message
      (Appendix A.4.4.9) with subcode 2 ("Missing Object") MUST be

   Messaging associations can always be set up on demand, and messaging
   association status is not made directly visible outside the GIST
   layer.  Therefore, even if GIST tears down and later re-establishes a
   messaging association, signalling applications cannot distinguish
   this from the case where the MA is kept permanently open.  To
   maintain the transport semantics described in Section 4.1, GIST MUST
   close transport connections carrying reliable messages gracefully or
   report an error condition, and MUST NOT open a new association to be
   used for given session and peer while messages on a previous
   association could still be outstanding.  GIST MAY use an MA-Hello
   request/reply exchange on an existing association to verify that
   messages sent on it have reached the peer.  GIST MAY use the same
   technique to test the liveness of the underlying MA protocols
   themselves at arbitrary times.

   This specification defines precisely only the time at which messaging
   associations expire; it does not define when keepalives should be
   initiated.  Implementations MUST select timer settings that take at
   least the following into account:

   o  the transmission latency between source and destination;

   o  the need for retransmissions within the messaging association

   o  the need to avoid network synchronisation of control traffic (cf.
Top   ToC   RFC5971 - Page 44
   In most cases, a reasonable policy is to initiate the MA refresh when
   between 1/2 and 3/4 of the validity time has elapsed since the last
   successful refresh.  The actual moment MUST be chosen randomly within
   this interval to avoid synchronisation effects.

4.4.6. Routing State Failures

A GIST node can receive a message from a GIST peer that can only be correctly processed in the context of some routing state, but where no corresponding routing state exists. Cases where this can arise include: o Where the message is random traffic from an attacker, or backscatter (replies to such traffic). o Where routing state has been correctly installed but the peer has since lost it, for example, because of aggressive timeout settings at the peer or because the node has crashed and restarted. o Where the routing state was not correctly installed in the first place, but the sending node does not know this. This can happen if the Confirm message of the handshake is lost. It is important for GIST to recover from such situations promptly where they represent genuine errors (node restarts, or lost messages that would not otherwise be retransmitted). Note that only Response, Confirm, Data, and Error messages ever require routing state to exist, and these are considered in turn: Response: A Response can be received at a node that never sent (or has forgotten) the corresponding Query. If the node wants routing state to exist, it will initiate it itself; a diagnostic error would not allow the sender of the Response to take any corrective action, and the diagnostic could itself be a form of backscatter. Therefore, an error message MUST NOT be generated, but the condition MAY be logged locally. Confirm: For a Responding node that implements delayed state installation, this is normal behaviour, and routing state will be created provided the Confirm is validated. Otherwise, this is a case of a non-existent or forgotten Response, and the node may not have sufficient information in the Confirm to create the correct state. The requirement is to notify the Querying node so that it can recover the routing state.
Top   ToC   RFC5971 - Page 45
   Data:  This arises when a node receives Data where routing state is
      required, but either it does not exist at all or it has not been
      finalised (no Confirm message).  To avoid Data being black-holed,
      a notification must be sent to the peer.

   Error:  Some error messages can only be interpreted in the context of
      routing state.  However, the only error messages that require a
      reply within the protocol are routing state error messages
      themselves.  Therefore, this case should be treated the same as a
      Response: an error message MUST NOT be generated, but the
      condition MAY be logged locally.

   For the case of Confirm or Data messages, if the state is required
   but does not exist, the node MUST reject the incoming message with a
   "No Routing State" error message (Appendix A.4.4.5).  There are then
   three cases at the receiver of the error message:

   No routing state:  The condition MAY be logged but a reply MUST NOT
      be sent (see above).

   Querying node:  The node MUST restart the GIST handshake from the
      beginning, with a new Query.

   Responding node:  The node MUST delete its own routing state and
      SHOULD report an error condition to the local signalling

   The rules at the Querying or Responding node make GIST open to
   disruption by randomly injected error messages, similar to blind
   reset attacks on TCP (cf. [46]), although because routing state
   matching includes the SID this is mainly limited to on-path
   attackers.  If a GIST node detects a significant rate of such
   attacks, it MAY adopt a policy of using secured messaging
   associations to communicate for the affected MRIs, and only accepting
   "No Routing State" error messages over such associations.

(page 45 continued on part 3)

Next Section