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
; 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.
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
direction of this MRI will be inverted compared to that in the Query,
that is, an upstream MRI becomes downstream and vice versa (see
Response = Common-Header
[ NAT-Traversal-Object ]
[ 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
[ 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 ]
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
Length: The number of 32-bit words in the message following the
Upper layer identifier (NSLPID): This gives the specific NSLP for
which this message is used.
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
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
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.
* 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
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
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
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.
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
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.
126.96.36.199. 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  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.
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.
188.8.131.52. 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
 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
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 , and for the last extension header MUST have
a next-header field of UDP.
184.108.40.206. Upper Layer Encapsulation and Overall Interception
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
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.
220.127.116.11. 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
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.
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  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  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
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
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
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
decapsulation process may provide additional information, such as
translated addresses or IP hop count to be used in the subsequent
| 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
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.
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
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
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.
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.
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.
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
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  and MUST
use the highest protocol version supported by both peers.
Implementation of TLS1.2  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
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 . 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.
18.104.22.168. 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, *.example.com in the APD would match certificates for
a.example.com, foo.example.com, *.example.com, etc., but would not
match example.com. Similarly, a certificate for *.example.com would
be valid for APD identities of a.example.com, foo.example.com,
*.example.com, etc., but not example.com.
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  for
general certificate validation, but MAY supplement that algorithm
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
22.214.171.124. Message Routing Information
For the path-coupled MRM, the message routing information (MRI) is
conceptually the Flow Identifier as in the NSIS framework .
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
[ 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).
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.
126.96.36.199. 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,
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.
188.8.131.52. 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)
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 .
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 .
184.108.40.206. Message Routing Information
For the loose-end MRM, only a simplified version of the Flow
Identifier is needed.
MRI = network-layer-version
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
220.127.116.11. 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