RFC 5971
GIST: General Internet Signalling Transport
Pages: 154
Experimental
Experimental
Part 3 of 6 – Pages 45 to 70
5. Message Formats and Transport
5.1. GIST Messages
All GIST messages begin with a common header, followed by a sequence of type-length-value (TLV) objects. This subsection describes the various GIST messages and their contents at a high level in ABNF [11]; a more detailed description of the header and each object is given in Section 5.2 and bit formats in Appendix A. Note that the NAT traversal mechanism for GIST involves the insertion of an additional NAT-Traversal-Object in Query, Response, and some Data and Error messages; the rules for this are given in Section 7.2.
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 ]
Message-Routing-Information
Session-Identifier
Network-Layer-Information
Query-Cookie
[ 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 Section 3.3). Response = Common-Header [ NAT-Traversal-Object ] Message-Routing-Information Session-Identifier Network-Layer-Information Query-Cookie [ Responder-Cookie [ Stack-Proposal Stack-Configuration-Data ] ] [ NSLP-Data ] Confirm: A Confirm MUST be sent in C-mode if a messaging association is being used for this routing state, and MUST be sent before other messages for this routing state if an association is being set up. If no messaging association is being used, the Confirm MUST be sent in D-mode. The Confirm MUST include the MRI (with inverted direction) and SID, and echo the Responder-Cookie if the Response carried one. In C-mode, the Confirm MUST also echo the Stack- Proposal from the Response (if present) so it can be verified that this has not been tampered with. The first Confirm on a new association MUST also repeat the Stack-Configuration-Data from the original Query in an abbreviated form, just containing the MA-Hold- Time. Confirm = Common-Header Message-Routing-Information Session-Identifier Network-Layer-Information [ Responder-Cookie [ Stack-Proposal [ Stack-Configuration-Data ] ] ] [ NSLP-Data ] Data: The Data message is used to transport NSLP data without modifying GIST state. It contains no control objects, but only the MRI and SID associated with the NSLP data being transferred. Network-Layer-Information (NLI) MUST be carried in the D-mode case, but MUST NOT be included otherwise. Data = Common-Header [ NAT-Traversal-Object ] Message-Routing-Information Session-Identifier [ Network-Layer-Information ] NSLP-Data
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
object.
Error = Common-Header
[ NAT-Traversal-Object ]
[ Network-Layer-Information ]
GIST-Error-Data
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
Hello-ID
5.2. Information Elements
This section describes the content of the various objects that can be
present in each GIST message, both the common header and the
individual TLVs. The bit formats are provided in Appendix A.
5.2.1. The Common Header
Each message begins with a fixed format common header, which contains
the following information:
Version: The version number of the GIST protocol. This
specification defines GIST version 1.
GIST hop count: A hop count to prevent a message from looping
indefinitely.
Length: The number of 32-bit words in the message following the
common header.
Upper layer identifier (NSLPID): This gives the specific NSLP for
which this message is used.
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
processing.
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
message.
Explicit routing: A flag that if set (E=1) indicates that the
message was explicitly routed (see Section 7.1.5).
Note that in D-mode, Section 5.3, there is a 32-bit magic number
before the header. However, this is regarded as part of the
encapsulation rather than part of the message itself.
5.2.2. TLV Objects
All data following the common header is encoded as a sequence of
type-length-value objects. Currently, each object can occur at most
once; the set of required and permitted objects is determined by the
message type and encapsulation (D-mode or C-mode).
Message-Routing-Information (MRI): Information sufficient to define
how the signalling message should be routed through the network.
Message-Routing-Information = message-routing-method
method-specific-information
The format of the method-specific-information depends on the
message-routing-method requested by the signalling application. Note
that it always includes a flag defining the direction as either
'upstream' or 'downstream' (see Section 3.3). It is provided by the
NSLP in the message sender and used by GIST to select the message
routing.
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
interface-address
RS-validity-time
IP-TTL
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
ignored.
* 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
question.
Stack-Proposal: This field contains information about which
combinations of transport and security protocols are available for
use in messaging associations, and is also discussed further in
Section 5.7.
Stack-Proposal = 1*stack-profile
stack-profile = protocol-count 1*protocol-layer
;; padded on the right with 0 to 32-bit boundary
protocol-count = %x01-FF
;; number of the following <protocol-layer>,
;; represented as one byte. This doesn't include
;; padding.
protocol-layer = %x01-FF
Each protocol-layer field identifies a protocol with a unique tag;
any additional data, such as higher-layer addressing or other options
data associated with the protocol, will be carried in an
MA-protocol-options field in the Stack-Configuration-Data TLV (see
below).
Stack-Configuration-Data (SCD): This object carries information
about the overall configuration of a messaging association.
Stack-Configuration-Data = MA-Hold-Time
0*MA-protocol-options
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 common-error-header [ Message-Routing-Information-content ] [ Session-Identification-content ] 0*additional-information [ 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.5.3.2.1. Encapsulation and Interception in IPv4
In general, the IP addresses are derived from information in the MRI; the exact rules depend on the MRM. For the case of messages with source addressing mode flag S=1, the receiver MUST check the IP source address against the interface-address given in the NLI as part of legacy NAT detection; see Section 7.2.1. Current MRMs define the use of a Router Alert Option [13] to assist the peer in intercepting the message depending on the NSLPID. If the MRM defines the use of RAO, the sender MUST include it unless it has been specifically configured not to (see below). A node MAY make the initial interception decision based purely on IP-Protocol number transport header analysis. Implementations MAY provide an option to disable the setting of RAO on Q-mode packets on a per-destination prefix basis; however, the option MUST be disabled by default and MUST only be enabled when it has been separately verified that the next GIST node along the path to the destination is capable of intercepting packets without RAO. The purpose of this option is to allow operation across networks that do not properly support RAO; further details are discussed in Appendix C.
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.5.3.2.2. Encapsulation and Interception in IPv6
As for IPv4, the IP addresses are derived from information in the MRI; the exact rules depend on the MRM. For the case of messages with source addressing mode flag S=1, the receiver MUST check the IP source address with the interface-address given in the NLI as part of legacy NAT detection; see Section 7.2.1. For all current MRMs, the IP header is given a Router Alert Option [8] to assist the peer in intercepting the message depending on the NSLPID. If the MRM defines the use of RAO, the sender MUST include it without exception. It is RECOMMENDED that a node bases its initial interception decision purely on the presence of a hop-by-hop option header containing the RAO, which will be at the start of the header chain. The upper layer protocol MUST be UDP without intervening encapsulation layers. Following any hop-by-hop option header, the IP header MUST NOT include any extension headers other than routing or destination options [5], and for the last extension header MUST have a next-header field of UDP.5.3.2.3. Upper Layer Encapsulation and Overall Interception Requirements
For both IP versions, the above rules require that the upper layer protocol identified by the IP header MUST be UDP. Other packets MUST NOT be identified as GIST Q-mode packets; this includes IP-in-IP tunnelled packets, other tunnelled packets (tunnel mode AH/ESP), or packets that have undergone some additional transport layer processing (transport mode AH/ESP). If IP output processing at the originating node or an intermediate router causes such additional encapsulations to be added to a GIST Q-mode packet, this packet will not be identified as GIST until the encapsulation is terminated. If the node wishes to signal for data over the network region where the
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.5.3.2.4. IP Option Processing
For both IPv4 and IPv6, for Q-mode packets with IP options allowed by the above requirements, IP options processing is intended to be carried out independently of GIST processing. Note that for the options allowed by the above rules, the option semantics are independent of the payload: UDP payload modifications are not prevented by the options and do not affect the option content, and conversely the presence of the options does not affect the UDP payload.
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 [33] be used. The token bucket MUST be sized to ensure that a node cannot saturate the network with D-mode traffic, for example, when re-probing the network for multiple flows after a route change. A suitable approach is to restrict the token bucket parameters so that the mean output rate is a small fraction of the node's lowest-speed interface. It is RECOMMENDED that this fraction is no more than 5%. Note that according to the rules of Section 4.3.3, in general, D-mode SHOULD only be used for Queries and Responses rather than normal signalling traffic unless capacity for normal signalling traffic can be engineered.5.4. C-mode Transport
It is a requirement of the NTLP defined in [29] that it should be able to support bundling of small messages, fragmentation of large messages, and message boundary delineation. TCP provides both bundling and fragmentation, but not message boundaries. However, the
length information in the GIST common header allows the message
boundary to be discovered during parsing. The bundling together of
small messages either can be done within the transport protocol or
can be carried out by GIST during message construction. Either way,
two approaches can be distinguished:
1. As messages arrive for transmission, they are gathered into a
bundle until a size limit is reached or a timeout expires (cf.
the Nagle algorithm of TCP). This provides maximal efficiency at
the cost of some latency.
2. Messages awaiting transmission are gathered together while the
node is not allowed to send them, for example, because it is
congestion controlled.
The second type of bundling is always appropriate. For GIST, the
first type MUST NOT be used for trigger messages (i.e., messages that
update GIST or signalling application state), but may be appropriate
for refresh messages (i.e., messages that just extend timers). These
distinctions are known only to the signalling applications, but MAY
be indicated (as an implementation issue) by setting the priority
transfer attribute (Section 4.1.2).
It can be seen that all of these transport protocol options can be
supported by the basic GIST message format already presented. The
GIST message, consisting of common header and TLVs, is carried
directly in the transport protocol, possibly incorporating transport
layer security protection. Further messages can be carried in a
continuous stream. This specification defines only the use of TCP,
but other possibilities could be included without additional work on
message formatting.
5.5. Message Type/Encapsulation Relationships
GIST has four primary message types (Query, Response, Confirm, and
Data) and three possible encapsulation methods (normal D-mode,
Q-mode, and C-mode). The combinations of message type and
encapsulation that are allowed for message transmission are given in
the table below. In some cases, there are several possible choices,
depending on the existence of routing state or messaging
associations. The rules governing GIST policy, including whether or
not to create such state to handle a message, are described
normatively in the other sections of this specification. If a
message that can only be sent in Q-mode or D-mode arrives in C-mode
or vice versa, this MUST be rejected with an "Incorrect
Encapsulation" error message (Appendix A.4.4.3). However, it should
be noted that the processing of the message at the receiver is not
otherwise affected by the encapsulation method used, except that the
decapsulation process may provide additional information, such as translated addresses or IP hop count to be used in the subsequent message processing. +----------+--------------+---------------------------+-------------+ | Message | Normal | Query D-mode (Q-mode) | C-mode | | | D-mode | | | +----------+--------------+---------------------------+-------------+ | Query | Never | Always, with C-flag=1 | Never | | | | | | | Response | Unless a | Never | If a | | | messaging | | messaging | | | association | | association | | | is being | | is being | | | re-used | | re-used | | | | | | | Confirm | Only if no | Never | If a | | | messaging | | messaging | | | association | | association | | | has been set | | has been | | | up or is | | set up or | | | being | | is being | | | re-used | | re-used | | | | | | | Data | If routing | If the MRI can be used to | If a | | | state exists | derive the Q-mode | messaging | | | for the flow | encapsulation, and either | association | | | but no | no routing state exists | exists | | | messaging | or local policy requires | | | | association | Q-mode; MUST have | | | | | C-flag=1 | | +----------+--------------+---------------------------+-------------+5.6. Error Message Processing
Special rules apply to the encapsulation and transmission of Error messages. GIST only generates Error messages in reaction to incoming messages. Error messages MUST NOT be generated in reaction to incoming Error messages. The routing and encapsulation of the Error message are derived from that of the message that caused the error; in particular, local routing state is not consulted. Routing state and messaging association state MUST NOT be created to handle the error, and Error messages MUST NOT be retransmitted explicitly by GIST, although they are subject to the same rate control as other messages.
o If the incoming message was received in D-mode, the error MUST be
sent in D-mode using the normal encapsulation, using the
addressing information from the NLI object in the incoming
message. If the NLI could not be determined, the error MUST be
sent to the IP source of the incoming message if the S-flag was
set in it. The NLI object in the Error message reports
information about the originator of the error.
o If the incoming message was received over a messaging association,
the error MUST be sent back over the same messaging association.
The NSLPID in the common header of the Error message has the value
zero. If for any reason the message cannot be sent (for example,
because it is too large to send in D-mode, or because the MA over
which the original message arrived has since been closed), an error
SHOULD be logged locally. The receiver of the Error message can
infer the NSLPID for the message that caused the error from the
Common Header that is embedded in the Error Object.
5.7. Messaging Association Setup
5.7.1. Overview
A key attribute of GIST is that it is flexible in its ability to use
existing transport and security protocols. Different transport
protocols may have performance attributes appropriate to different
environments; different security protocols may fit appropriately with
different authentication infrastructures. Even given an initial
default mandatory protocol set for GIST, the need to support new
protocols in the future cannot be ruled out, and secure feature
negotiation cannot be added to an existing protocol in a backwards-
compatible way. Therefore, some sort of capability discovery is
required.
Capability discovery is carried out in Query and Response messages,
using Stack-Proposal and Stack-Configuration-Data (SCD) objects. If
a new messaging association is required, it is then set up, followed
by a Confirm. Messaging association multiplexing is achieved by
short-circuiting this exchange by sending the Response or Confirm
messages on an existing association (Section 4.4.3); whether to do
this is a matter of local policy. The end result of this process is
a messaging association that is a stack of protocols. If multiple
associations exist, it is a matter of local policy how to distribute
messages over them, subject to respecting the transfer attributes
requested for each message.
Every possible protocol for a messaging association has the following attributes: 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 dropped. 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
RECOMMENDED.
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 Section 4.1.2.5.7.3. Protocol Definition: Transport Layer Security
This MA-Protocol-ID denotes a basic use of transport layer channel security, initially in conjunction with TCP. Support for this protocol in conjunction with TCP is REQUIRED; associations using it can carry messages with transfer attributes requesting confidentiality or integrity protection. The specific TLS version will be negotiated within the TLS layer itself, but implementations MUST NOT negotiate to protocol versions prior to TLS1.0 [15] and MUST use the highest protocol version supported by both peers. Implementation of TLS1.2 [10] is RECOMMENDED. GIST nodes supporting TLS1.0 or TLS1.1 MUST be able to negotiate the TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD be able to negotiate the TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. They MAY negotiate any mutually acceptable ciphersuite that provides authentication, integrity, and confidentiality. The default mode of TLS authentication, which applies in particular to the above ciphersuites, uses a client/server X.509 certificate exchange. The Querying node acts as a TLS client, and the Responding node acts as a TLS server. Where one of the above ciphersuites is negotiated, the GIST node acting as a server MUST provide a
certificate, and MUST request one from the GIST node acting as a TLS client. This allows either server-only or mutual authentication, depending on the certificates available to the client and the policy applied at the server. GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the negotiation of alternative ciphersuites is used to trigger alternative authentication procedures, such as the use of pre-shared keys [32]. The use of other authentication procedures may require additional specification work to define how they can be used as part of TLS within the GIST framework, and may or may not require the definition of additional MA-Protocol-IDs. No MA-protocol-options field is required for this TLS protocol definition. The configuration information for the transport protocol over which TLS is running (e.g., TCP port number) is provided by the MA-protocol-options for that protocol.5.7.3.1. 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 [8] 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
5.8.1.1. Message Routing Information
For the path-coupled MRM, the message routing information (MRI) is conceptually the Flow Identifier as in the NSIS framework [29]. Minimally, this could just be the flow destination address; however, to account for policy-based forwarding and other issues a more complete set of header fields SHOULD be specified if possible (see Section 4.3.4 and Section 7.2 for further discussion). MRI = network-layer-version source-address prefix-length destination-address prefix-length IP-protocol diffserv-codepoint [ flow-label ] [ ipsec-SPI / L4-ports] Additional control information defines whether the flow-label, IPsec Security Parameters Index (SPI), and port information are present, and whether the IP-protocol and diffserv-codepoint fields should be interpreted as significant. The source and destination addresses MUST be real node addresses, but prefix lengths other than 32 or 128 (for IPv4 and IPv6, respectively) MAY be used to implement address wildcarding, allowing the MRI to refer to traffic to or from a wider address range. An additional flag defines the message direction relative to the MRI (upstream vs. downstream).
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.5.8.1.2. 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.
5.8.1.3. Upstream Q-mode Encapsulation
In some deployment scenarios, it is desirable to set up routing state
in the upstream direction (i.e., from flow receiver towards the
sender). This could be used to support firewall signalling to
control traffic from an uncooperative sender, or signalling in
general where the flow sender was not NSIS-capable. This capability
is incorporated into GIST by defining an encapsulation and processing
rules for sending Query messages upstream.
In general, it is not possible to determine the hop-by-hop route
upstream because of asymmetric IP routing. However, in particular
cases, the upstream peer can be discovered with a high degree of
confidence, for example:
o The upstream GIST peer is one IP hop away, and can be reached by
tracing back through the interface on which the flow arrives.
o The upstream peer is a border router of a single-homed (stub)
network.
This section defines an upstream Q-mode encapsulation and validation
checks for when it can be used. The functionality to generate
upstream Queries is OPTIONAL, but if received they MUST be processed
in the normal way with some additional IP TTL checks. No special
functionality is needed for this.
It is possible for routing state at a given node, for a specific MRI
and NSLPID, to be created by both an upstream Query exchange
(initiated by the node itself) and a downstream Query exchange (where
the node is the responder). If the SIDs are different, these items
of routing state MUST be considered as independent; if the SIDs
match, the routing state installed by the downstream exchange MUST
take precedence, provided that the downstream Query passed ingress
filtering checks. The rationale for this is that the downstream
Query is in general a more reliable way to install state, since it
directly probes the IP routing infrastructure along the flow path,
whereas use of the upstream Query depends on the correctness of the
Querying node's understanding of the topology.
The details of the encapsulation are as follows:
o The destination address SHOULD be the flow source address as given
in the MRI of the message payload. An implementation with more
detailed knowledge of local IP routing MAY use an alternative
destination address (e.g., the address of its default router).
o The source address SHOULD be the signalling node address, so in
the common header S=1.
o A Router Alert Option is included as in the downstream case.
o The Diffserv codepoint and (for IPv6) flow label MAY be set to
match the values from the MRI as in the downstream case, and the
UDP port selection is also the same.
o The IP layer TTL of the message MUST be set to 255.
The sending GIST implementation SHOULD attempt to send the Query via
the same interface and to the same link layer neighbour from which
the data packets of the flow are arriving.
The receiving GIST node MAY apply validation checks to the message
and MRI, to reject Query messages that have reached a node at which
they can no longer be trusted. In particular, a node SHOULD reject a
message that has been propagated more than one IP hop, with an
"Invalid IP layer TTL" error message (Appendix A.4.4.11). This can
be determined by examining the received IP layer TTL, similar to the
generalised IP TTL security mechanism described in [41].
Alternatively, receipt of an upstream Query at the flow source MAY be used to trigger setup of GIST state in the downstream direction. These restrictions may be relaxed in a future version.5.8.2. The Loose-End MRM
The Loose-End MRM is used to discover GIST nodes with particular properties in the direction of a given address, for example, to discover a NAT along the upstream data path as in [34].5.8.2.1. Message Routing Information
For the loose-end MRM, only a simplified version of the Flow Identifier is needed. MRI = network-layer-version source-address destination-address The source address is the address of the node initiating the discovery process, for example, the node that will be the data receiver in the NAT discovery case. The destination address is the address of a node that is expected to be the other side of the node to be discovered. Additional control information defines the direction of the message relative to this flow as in the path-coupled case.5.8.2.2. Downstream Q-mode Encapsulation
Only one encapsulation is defined for the loose-end MRM; by convention, this is referred to as the downstream encapsulation, and is defined as follows: o The IP destination address MUST be the destination address as given in the MRI of the message payload. o By default, the IP source address is the source address from the MRI (S=0). However, the use of the signalling source address (S=1) is allowed as in the case of the path-coupled MRM. A Router Alert Option is included in the IP header. The option value depends on the NSLP being signalled for. There are no special requirements on the setting of the Diffserv codepoint, IP layer TTL, or (for IPv6) the flow label. Nor are any special validation checks applied.
(next page on part 4)