RFC 5971
GIST: General Internet Signalling Transport
Pages: 154
Experimental
Experimental
Part 2 of 6 – Pages 20 to 45
4. GIST Processing Overview
This section defines the basic structure and operation of GIST. Section 4.1 describes the way in which GIST interacts with local signalling applications in the form of an abstract service interface. Section 4.2 describes the per-flow and per-peer state that GIST maintains for the purpose of transferring messages. Section 4.3 describes how messages are processed in the case where any necessary messaging associations and routing state already exist; this includes
the simple scenario of pure D-mode operation, where no messaging associations are necessary. Finally, Section 4.4 describes how routing state and messaging associations are created and managed.4.1. GIST Service Interface
This section describes the interaction between GIST and signalling applications in terms of an abstract service interface, including a definition of the attributes of the message transfer that GIST can offer. The service interface presented here is non-normative and does not constrain actual implementations of any interface between GIST and signalling applications; the interface is provided to aid understanding of how GIST can be used. However, requirements on SID selection and internal GIST behaviour to support message transfer semantics (such as in-order delivery) are stated normatively here. The same service interface is presented at every GIST node; however, applications may invoke it differently at different nodes, depending for example on local policy. In addition, the service interface is defined independently of any specific transport protocol, or even the distinction between D-mode and C-mode. The initial version of this specification defines how to support the service interface using a C-mode based on TCP; if additional protocol support is added, this will support the same interface and so the change will be invisible to applications, except as a possible performance improvement. A more detailed description of this service interface is given in Appendix B.4.1.1. Message Handling
Fundamentally, GIST provides a simple message-by-message transfer service for use by signalling applications: individual messages are sent, and individual messages are received. At the service interface, the NSLP payload, which is opaque to GIST, is accompanied by control information expressing the application's requirements about how the message should be routed (the MRI), and the application also provides the session identifier (SID); see Section 4.1.3. Additional message transfer attributes control the specific transport and security properties that the signalling application desires. The distinction between GIST D- and C-mode is not visible at the service interface. In addition, the functionality to handle fragmentation and reassembly, bundling together of small messages for efficiency, and congestion control are not visible at the service interface; GIST will take whatever action is necessary based on the properties of the messages and local node state.
A signalling application is free to choose the rate at which it processes inbound messages; an implementation MAY allow the application to block accepting messages from GIST. In these circumstances, GIST MAY discard unreliably delivered messages, but for reliable messages MUST propagate flow-control condition back to the sender. Therefore, applications must be aware that they may in turn be blocked from sending outbound messages themselves.4.1.2. Message Transfer Attributes
Message transfer attributes are used by NSLPs to define minimum required levels of message processing. The attributes available are as follows: Reliability: This attribute may be 'true' or 'false'. When 'true', the following rules apply: * messages MUST be delivered to the signalling application in the peer exactly once or not at all; * for messages with the same SID, the delivery MUST be in order; * if there is a chance that the message was not delivered (e.g., in the case of a transport layer error), an error MUST be indicated to the local signalling application identifying the routing information for the message in question. GIST implements reliability by using an appropriate transport protocol within a messaging association, so mechanisms for the detection of message loss depend on the protocol in question; for the current specification, the case of TCP is considered in Section 5.7.2. When 'false', a message may be delivered, once, several times, or not at all, with no error indications in any of these cases. Security: This attribute defines the set of security properties that the signalling application requires for the message, including the type of protection required, and what authenticated identities should be used for the signalling source and destination. This information maps onto the corresponding properties of the security associations established between the peers in C-mode. Keying material for the security associations is established by the authentication mechanisms within the messaging association protocols themselves; see Section 8.2. The attribute can be specified explicitly by the signalling application, or reported by GIST to the signalling application. The latter can take place
either on receiving a message, or just before sending a message
but after configuring or selecting the messaging association to be
used for it.
This attribute can also be used to convey information about any
address validation carried out by GIST, such as whether a return
routability check has been carried out. Further details are
discussed in Appendix B.
Local Processing: An NSLP may provide hints to GIST to enable more
efficient or appropriate processing. For example, the NSLP may
select a priority from a range of locally defined values to
influence the sequence in which messages leave a node. Any
priority mechanism MUST respect the ordering requirements for
reliable messages within a session, and priority values are not
carried in the protocol or available at the signalling peer or
intermediate nodes. An NSLP may also indicate that upstream path
routing state will not be needed for this flow, to inhibit the
node requesting its downstream peer to create it; conversely, even
if routing state exists, the NSLP may request that it is not used,
which will lead to GIST Data messages being sent Q-mode
encapsulated instead.
A GIST implementation MAY deliver messages with stronger attribute
values than those explicitly requested by the application.
4.1.3. SID Selection
The fact that SIDs index routing state (see Section 4.2.1 below)
means that there are requirements for how they are selected.
Specifically, signalling applications MUST choose SIDs so that they
are cryptographically random, and SHOULD NOT use several SIDs for the
same flow, to avoid additional load from routing state maintenance.
Guidance on secure randomness generation can be found in [31].
4.2. GIST State
4.2.1. Message Routing State
For each flow, the GIST layer can maintain message routing state to
manage the processing of outgoing messages. This state is
conceptually organised into a table with the following structure.
Each row in the table corresponds to a unique combination of the
following three items:
Message Routing Information (MRI): This defines the method to be
used to route the message, the direction in which to send the
message, and any associated addressing information; see
Section 3.3.
Session Identifier (SID): The signalling session with which this
message should be associated; see Section 3.7.
NSLP Identifier (NSLPID): This is an IANA-assigned identifier
associated with the NSLP that is generating messages for this
flow; see Section 3.8. The inclusion of this identifier allows
the routing state to be different for different NSLPs.
The information associated with a given MRI/SID/NSLPID combination
consists of the routing state to reach the peer in the direction
given by the MRI. For any flow, there will usually be two entries in
the table, one each for the upstream and downstream MRI. The routing
state includes information about the peer identity (see
Section 4.4.3), and a UDP port number for D-mode, or a reference to
one or more MAs for C-mode. Entries in the routing state table are
created by the GIST handshake, which is described in more detail in
Section 4.4.
It is also possible for the state information for either direction to
be empty. There are several possible cases:
o The signalling application has indicated that no messages will
actually be sent in that direction.
o The node is the endpoint of the signalling path, for example,
because it is acting as a proxy, or because it has determined that
there are no further signalling nodes in that direction.
o The node is using other techniques to route the message. For
example, it can send it in Q-mode and rely on the peer to
intercept it.
In particular, if the node is a flow endpoint, GIST will refuse to
create routing state for the direction beyond the end of the flow
(see Section 4.3.3). Each entry in the routing state table has an
associated validity timer indicating for how long it can be
considered accurate. When this timer expires, the entry MUST be
purged if it has not been refreshed. Installation and maintenance of
routing state are described in more detail in Section 4.4.
4.2.2. Peer-Peer Messaging Association State
The per-flow message routing state is not the only state stored by GIST. There is also the state required to manage the MAs. Since these are not per-flow, they are stored separately from the routing state, including the following per-MA information: o a queue of any messages that require the use of an MA, pending transmission while the MA is being established; o the time since the peer re-stated its desire to keep the MA open (see Section 4.4.5). In addition, per-MA state, such as TCP port numbers or timer information, is held in the messaging association protocols themselves. However, the details of this state are not directly visible to GIST, and they do not affect the rest of the protocol description.4.3. Basic GIST Message Processing
This section describes how signalling application messages are processed in the case where any necessary messaging associations and routing state are already in place. The description is divided into several parts. First, message reception, local processing, and message transmission are described for the case where the node hosts the NSLPID identified in the message. Second, in Section 4.3.4, the case where the message is handled directly in the IP or GIST layer (because there is no matching signalling application on the node) is given. An overview is given in Figure 4. This section concentrates on the GIST-level processing, with full details of IP and transport layer encapsulation in Section 5.3 and Section 5.4.
+---------------------------------------------------------+ | >> Signalling Application Processing >> | | | +--------^---------------------------------------V--------+ ^ NSLP NSLP V ^ Payloads Payloads V +--------^---------------------------------------V--------+ | >> GIST >> | | ^ ^ ^ Processing V V V | +--x-----------N--Q---------------------Q--N-----------x--+ x N Q Q N x x N Q>>>>>>>>>>>>>>>>>>>>>Q N x x N Q Bypass at Q N x +--x-----+ +--N--Q--+ GIST level +--Q--N--+ +-----x--+ | C-mode | | D-mode | | D-mode | | C-mode | |Handling| |Handling| |Handling| |Handling| +--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+ x N Q Q N x x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x x N Q Bypass at Q N x +--x--N--+ +-----Q--+ IP (router +--Q-----+ +--N--x--+ |IP Host | | Q-mode | alert) level | Q-mode | |IP Host | |Handling| |Handling| |Handling| |Handling| +--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+ x N Q Q N x +--x--N-----------Q--+ +--Q-----------N--x--+ | IP Layer | | IP Layer | | (Receive Side) | | (Transmit Side) | +--x--N-----------Q--+ +--Q-----------N--x--+ x N Q Q N x x N Q Q N x NNNNNNNNNNNNNN = Normal D-mode messages QQQQQQQQQQQQQQ = D-mode messages that are Q-mode encapsulated xxxxxxxxxxxxxx = C-mode messages RAO = Router Alert Option Figure 4: Message Paths through a GIST Node4.3.1. Message Reception
Messages can be received in C-mode or D-mode. Reception in C-mode is simple: incoming packets undergo the security and transport treatment associated with the MA, and the MA provides complete messages to the GIST layer for further processing. Reception in D-mode depends on the message type.
Normal encapsulation: Normal messages arrive UDP-encapsulated and
addressed directly to the receiving signalling node, at an address
and port learned previously. Each datagram contains a single
message, which is passed to the GIST layer for further processing,
just as in the C-mode case.
Q-mode encapsulation: Where GIST is sending messages to be
intercepted by the appropriate peer rather than directly addressed
to it (in particular, Query messages), these are UDP encapsulated,
and MAY include an IP Router Alert Option (RAO) if required by the
MRM. Each GIST node can therefore see every such message, but
unless the message exactly matches the Q-mode encapsulation rules
(Section 5.3.2) it MUST be forwarded transparently at the IP
level. If it does match, GIST MUST check the NSLPID in the common
header. The case where the NSLPID does not match a local
signalling application at all is considered below in
Section 4.3.4; otherwise, the message MUST be passed up to the
GIST layer for further processing.
Several different RAO values may be used by the NSIS protocol suite.
GIST itself does not allocate any RAO values (for either IPv4 or
IPv6); an assignment is made for each NSLP using MRMs that use the
RAO in the Q-mode encapsulation. The assignment rationale is
discussed in a separate document [12]. The RAO value assigned for an
NSLPID may be different for IPv4 and IPv6. Note the different
significance between the RAO and the NSLPID values: the meaning of a
message (which signalling application it refers to, whether it should
be processed at a node) is determined only from the NSLPID; the role
of the RAO value is simply to allow nodes to pre-filter which IP
datagrams are analysed to see if they might be Q-mode GIST messages.
For all assignments associated with NSIS, the RAO-specific processing
is the same and is as defined by this specification, here and in
Section 4.3.4 and Section 5.3.2.
Immediately after reception, the GIST hop count is checked. Any
message with a GIST hop count of zero MUST be rejected with a "Hop
Limit Exceeded" error message (Appendix A.4.4.2); note that a correct
GIST implementation will never send a message with a GIST hop count
of zero. Otherwise, the GIST hop count MUST be decremented by one
before the next stage.
4.3.2. Local Processing and Validation
Once a message has been received, it is processed locally within the
GIST layer. Further processing depends on the message type and
payloads carried; most of the GIST payloads are associated with
internal state maintenance, and details are covered in Section 4.4.
This section concentrates on the interaction with the signalling
application, in particular, the decision to peer and how data is
delivered to the NSLP.
In the case of a Query, there is an interaction with the signalling
application to determine which of two courses to follow. The first
option (peering) MUST be chosen if the node is the final destination
of the Query message.
1. The receiving signalling application wishes to become a
signalling peer with the Querying node. GIST MUST continue with
the handshake process to set up message routing state, as
described in Section 4.4.1. The application MAY provide an NSLP
payload for the same NSLPID, which GIST will transfer in the
Response.
2. The signalling application does not wish to set up state with the
Querying node and become its peer. This includes the case where
a node wishes to avoid taking part in the signalling for overload
protection reasons. GIST MUST propagate the Query, similar to
the case described in Section 4.3.4. No message is sent back to
the Querying node. The application MAY provide an updated NSLP
payload for the same NSLPID, which will be used in the Query
forwarded by GIST. Note that if the node that finally processes
the Query returns an Error message, this will be sent directly
back to the originating node, bypassing any forwarders. For
these diagnostics to be meaningful, any GIST node forwarding a
Query, or relaying it with modified NSLP payload, MUST NOT modify
it except in the GIST hop count; in particular, it MUST NOT
modify any other GIST payloads or their order. An implementation
MAY choose to achieve this by retaining the original message,
rather than reconstructing it from some parsed internal
representation.
This interaction with the signalling application, including the
generation or update of an NSLP payload, SHOULD take place
synchronously as part of the Query processing. In terms of the GIST
service interface, this can be implemented by providing appropriate
return values for the primitive that is triggered when such a message
is received; see Appendix B.2 for further discussion.
For all GIST message types other than Queries, if the message
includes an NSLP payload, this MUST be delivered locally to the
signalling application identified by the NSLPID. The format of the
payload is not constrained by GIST, and the content is not
interpreted. Delivery is subject to the following validation checks,
which MUST be applied in the sequence given:
1. if the message was explicitly routed (see Section 7.1.5) or is a Data message delivered without routing state (see Section 5.3.2), the payload is delivered but flagged to the receiving NSLP to indicate that routing state was not validated; 2. else, if the message arrived on an association that is not associated with the MRI/NSLPID/SID combination given in the message, the message MUST be rejected with an "Incorrectly Delivered Message" error message (Appendix A.4.4.4); 3. else, if there is no routing state for this MRI/SID/NSLPID combination, the message MUST either be dropped or be rejected with an error message (see Section 4.4.6 for further details); 4. else, the payload is delivered as normal.4.3.3. Message Transmission
Signalling applications can generate their messages for transmission, either asynchronously or in reply to an input message delivered by GIST, and GIST can also generate messages autonomously. GIST MUST verify that it is not the direct destination of an outgoing message, and MUST reject such messages with an error indication to the signalling application. When the message is generated by a signalling application, it may be carried in a Query if local policy and the message transfer attributes allow it; otherwise, this may trigger setup of an MA over which the NSLP payload is sent in a Data message. Signalling applications may specify a value to be used for the GIST hop count; otherwise, GIST selects a value itself. GIST MUST reject messages for which the signalling application has specified a value of zero. Although the GIST hop count is only intended to control message looping at the GIST level, the GIST API (Appendix B) provides the incoming hop count to the NSLPs, which can preserve it on outgoing messages as they are forwarded further along the path. This provides a lightweight loop-control mechanism for NSLPs that do not define anything more sophisticated. Note that the count will be decremented on forwarding through every GIST-aware node. Initial values for the GIST hop count are an implementation matter; one suitable approach is to use the same algorithm as for IP TTL setting [1]. When a message is available for transmission, GIST uses internal policy and the stored routing state to determine how to handle it. The following processing applies equally to locally generated messages and messages forwarded from within the GIST or signalling
application levels. However, see Section 5.6 for special rules applying to the transmission of Error messages by GIST. The main decision is whether the message must be sent in C-mode or D-mode. Reasons for using C-mode are: o message transfer attributes: for example, the signalling application has specified security attributes that require channel-secured delivery, or reliable delivery. o message size: a message whose size (including the GIST header, GIST objects and any NSLP payload, and an allowance for the IP and transport layer encapsulation required by D-mode) exceeds a fragmentation-related threshold MUST be sent over C-mode, using a messaging association that supports fragmentation and reassembly internally. The allowance for IP and transport layer encapsulation is 64 bytes. The message size MUST NOT exceed the Path MTU to the next peer, if this is known. If this is not known, the message size MUST NOT exceed the least of the first-hop MTU, and 576 bytes. The same limit applies to IPv4 and IPv6. o congestion control: D-mode SHOULD NOT be used for signalling where it is possible to set up routing state and use C-mode, unless the network can be engineered to guarantee capacity for D-mode traffic within the rate control limits imposed by GIST (see Section 5.3.3). In principle, as well as determining that some messaging association must be used, GIST MAY select between a set of alternatives, e.g., for load sharing or because different messaging associations provide different transport or security attributes. For the case of reliable delivery, GIST MUST NOT distribute messages for the same session over multiple messaging associations in parallel, but MUST use a single association at any given time. The case of moving over to a new association is covered in Section 4.4.5. If the use of a messaging association (i.e., C-mode) is selected, the message is queued on the association found from the routing state table, and further output processing is carried out according to the details of the protocol stacks used. If no appropriate association exists, the message is queued while one is created (see Section 4.4.1), which will trigger the exchange of additional GIST messages. If no association can be created, this is an error condition, and should be indicated back to the local signalling application.
If a messaging association is not appropriate, the message is sent in
D-mode. The processing in this case depends on the message type,
local policy, and whether or not routing state exists.
o If the message is not a Query, and local policy does not request
the use of Q-mode for this message, and routing state exists, it
is sent with the normal D-mode encapsulation directly to the
address from the routing state table.
o If the message is a Query, or the message is Data and local policy
as given by the message transfer attributes requests the use of
Q-mode, then it is sent in Q-mode as defined in Section 5.3.2; the
details depend on the message routing method.
o If no routing state exists, GIST can attempt to use Q-mode as in
the Query case: either sending a Data message with the Q-mode
encapsulation or using the event as a trigger for routing state
setup (see Section 4.4). If this is not possible, e.g., because
the encapsulation for the MRM is only defined for one message
direction, then this is an error condition that is reported back
to the local signalling application.
4.3.4. Nodes not Hosting the NSLP
A node may receive messages where it has no signalling application
corresponding to the message NSLPID. There are several possible
cases depending mainly on the encapsulation:
1. A message contains an RAO value that is relevant to NSIS, but it
does not exactly match the Q-mode encapsulation rules of
Section 5.3.2. The message MUST be transparently forwarded at
the IP layer. See Section 3.6.
2. A Q-mode encapsulated message contains an RAO value that has been
assigned to some NSIS signalling application but that is not used
on this specific node, but the IP layer is unable to distinguish
whether it needs to be passed to GIST for further processing or
whether the packet should be forwarded just like a normal IP
datagram.
3. A Q-mode encapsulated message contains an RAO value that has been
assigned to an NSIS signalling application that is used on this
node, but the signalling application does not process the NSLPID
in the message. (This covers the case where a signalling
application uses a set of NSLPIDs.)
4. A directly addressed message (in D-mode or C-mode) is delivered
to a node for which there is no corresponding signalling
application. With the current specification, this should not
happen in normal operation. While future versions might find a
use for such a feature, currently this MUST cause an "Unknown
NSLPID" error message (Appendix A.4.4.6).
5. A Q-mode encapsulated message arrives at the end-system that does
not handle the signalling application. This is possible in
normal operation, and MUST be indicated to the sender with an
"Endpoint Found" informational message (Appendix A.4.4.7). The
end-system includes the MRI and SID from the original message in
the error message without interpreting them.
6. The node is a GIST-aware NAT. See Section 7.2.
In case (2) and (3), the role of GIST is to forward the message
essentially as though it were a normal IP datagram, and it will not
become a peer to the node sending the message. Forwarding with
modified NSLP payloads is covered above in Section 4.3.2. However, a
GIST implementation MUST ensure that the IP-layer TTL field and GIST
hop count are managed correctly to prevent message looping, and this
should be done consistently independently of where in the packet
processing path the decision is made. The rules are that in cases
(2) and (3), the IP-layer TTL MUST be decremented just as if the
message was a normal IP forwarded packet. In case (3), the GIST hop
count MUST be decremented as in the case of normal input processing,
which also applies to cases (4) and (5).
A GIST node processing Q-mode encapsulated messages in this way
SHOULD make the routing decision based on the full contents of the
MRI and not only the IP destination address. It MAY also apply a
restricted set of sanity checks and under certain conditions return
an error message rather than forward the message. These conditions
are:
1. The message is so large that it would be fragmented on downstream
links, for example, because the downstream MTU is abnormally
small (less than 576 bytes). The error "Message Too Large"
(Appendix A.4.4.8) SHOULD be returned to the sender, which SHOULD
begin messaging association setup.
2. The GIST hop count has reached zero. The error "Hop Limit
Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender,
which MAY retry with a larger initial hop count.
3. The MRI represents a flow definition that is too general to be
forwarded along a unique path (e.g., the destination address
prefix is too short). The error "MRI Validation Failure"
(Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be
returned to the sender, which MAY retry with restricted MRIs,
possibly starting additional signalling sessions to do so. If
the GIST node does not understand the MRM in question, it MUST
NOT apply this check, instead forwarding the message
transparently.
In the first two cases, only the common header of the GIST message is
examined; in the third case, the MRI is also examined. The rest of
the message MUST NOT be inspected in any case. Similar to the case
of Section 4.3.2, the GIST payloads MUST NOT be modified or re-
ordered; an implementation MAY choose to achieve this by retaining
the original message, rather than reconstructing it from some parsed
internal representation.
4.4. Routing State and Messaging Association Maintenance
The main responsibility of GIST is to manage the routing state and
messaging associations that are used in the message processing
described above. Routing state is installed and refreshed by GIST
handshake messages. Messaging associations are set up by the normal
procedures of the transport and security protocols that comprise
them, using peer IP addresses from the routing state. Once a
messaging association has been created, its refresh and expiration
can be managed independently from the routing state.
There are two different cases for state installation and refresh:
1. Where routing state is being discovered or a new association is
to be established; and
2. Where a suitable association already exists, including the case
where routing state for the flow is being refreshed.
These cases are now considered in turn, followed by the case of
background general management procedures.
4.4.1. Routing State and Messaging Association Creation
The message sequence for GIST state setup between peers is shown in
Figure 5 and described in detail below. The figure informally
summarises the contents of each message, including optional elements
in square brackets. An example is given in Appendix D.
The first message in any routing state maintenance operation is a Query, sent from the Querying node and intercepted at the responding node. This message has addressing and other identifiers appropriate for the flow and signalling application that state maintenance is being done for, addressing information about the node that generated the Query itself, and MAY contain an NSLP payload. It also includes a Query-Cookie, and optionally capability information about messaging association protocol stacks. The role of the cookies in this and later messages is to protect against certain denial-of-service attacks and to correlate the events in the message sequence (see Section 8.5 for further details).
+----------+ +----------+ | Querying | |Responding| | Node(Q-N)| | Node(R-N)| +----------+ +----------+ Query ............. ----------------------> . . Router Alert Option . Routing . MRI/SID/NSLPID . state . Q-N Network Layer Info . installed . Query-Cookie . at . [Q-N Stack-Proposal . Responding. Q-N Stack-Config-Data] . node . [NSLP Payload] . (case 1) . ............. ...................................... . The responder can use an existing . . messaging association if available . . from here onwards to short-circuit . . messaging association setup . ...................................... Response ............. <---------------------- . Routing . MRI/SID/NSLPID . state . R-N Network Layer Info . installed . Query-Cookie . at . [Responder-Cookie . Querying . [R-N Stack-Proposal . node . R-N Stack-Config-Data]] ............. [NSLP Payload] .................................... . If a messaging association needs . . to be created, it is set up here . . and the Confirm uses it . .................................... Confirm ............. ----------------------> . Routing . MRI/SID/NSLPID . state . Q-N Network Layer Info . installed . [Responder-Cookie . at . [R-N Stack-Proposal . Responding. [Q-N Stack-Config-Data]]] . node . [NSLP Payload] . (case 2) . ............. Figure 5: Message Sequence at State Setup
Provided that the signalling application has indicated that message routing state should be set up (see Section 4.3.2), reception of a Query MUST elicit a Response. This is a normally encapsulated D-mode message with additional GIST payloads. It contains network layer information about the Responding node, echoes the Query-Cookie, and MAY contain an NSLP payload, possibly a reply to the NSLP payload in the initial message. In case a messaging association was requested, it MUST also contain a Responder-Cookie and its own capability information about messaging association protocol stacks. Even if a messaging association is not requested, the Response MAY still include a Responder-Cookie if the node's routing state setup policy requires it (see below). Setup of a new messaging association begins when peer addressing information is available and a new messaging association is actually needed. Any setup MUST take place immediately after the specific Query/Response exchange, because the addressing information used may have a limited lifetime, either because it depends on limited lifetime NAT bindings or because it refers to agile destination ports for the transport protocols. The Stack-Proposal and Stack- Configuration-Data objects carried in the exchange carry capability information about what messaging association protocols can be used, and the processing of these objects is described in more detail in Section 5.7. With the protocol options currently defined, setup of the messaging association always starts from the Querying node, although more flexible configurations are possible within the overall GIST design. If the messaging association includes a channel security protocol, each GIST node MUST verify the authenticated identity of the peer against its authorised peer database, and if there is no match the messaging association MUST be torn down. The database and authorisation check are described in more detail in Section 4.4.2 below. Note that the verification can depend on what the MA is to be used for (e.g., for which MRI or session), so this step may not be possible immediately after authentication has completed but some time later. Finally, after any necessary messaging association setup has completed, a Confirm MUST be sent if the Response requested it. Once the Confirm has been sent, the Querying node assumes that routing state has been installed at the responder, and can send normal Data messages for the flow in question; recovery from a lost Confirm is discussed in Section 5.3.3. If a messaging association is being used, the Confirm MUST be sent over it before any other messages for the same flow, and it echoes the Responder-Cookie and Stack-Proposal from the Response. The former is used to allow the receiver to validate the contents of the message (see Section 8.5), and the latter is to prevent certain bidding-down attacks on messaging association security (see Section 8.6). This first Confirm on a new
association MUST also contain a Stack-Configuration-Data object carrying an MA-Hold-Time value, which supersedes the value given in the original Query. The association can be used in the upstream direction for the MRI and NSLPID carried in the Confirm, after the Confirm has been received. The Querying node MUST install the responder address, derived from the R-Node Network Layer info, as routing state information after verifying the Query-Cookie in the Response. The Responding node MAY install the querying address as peer state information at two points in time: Case 1: after the receipt of the initial Query, or Case 2: after a Confirm containing the Responder-Cookie. The Responding node SHOULD derive the peer address from the Q-Node Network Layer Info if this was decoded successfully. Otherwise, it MAY be derived from the IP source address of the message if the common header flags this as being the signalling source address. The precise constraints on when state information is installed are a matter of security policy considerations on prevention of denial-of- service attacks and state poisoning attacks, which are discussed further in Section 8. Because the Responding node MAY choose to delay state installation as in case (2), the Confirm must contain sufficient information to allow it to be processed in the same way as the original Query. This places some special requirements on NAT traversal and cookie functionality, which are discussed in Section 7.2 and Section 8 respectively.4.4.2. GIST Peer Authorisation
When two GIST nodes authenticate using a messaging association, both ends have to decide whether to accept the creation of the MA and whether to trust the information sent over it. This can be seen as an authorisation decision: o Authorised peers are trusted to install correct routing state about themselves and not, for example, to claim that they are on- path for a flow when they are not. o Authorised peers are trusted to obey transport- and application- level flow control rules, and not to attempt to create overload situations. o Authorised peers are trusted not to send erroneous or malicious error messages, for example, asserting that routing state has been lost when it has not.
This specification models the decision as verification by the authorising node of the peer's identity against a local list of peers, the authorised peer database (APD). The APD is an abstract construct, similar to the security policy database of IPsec [36]. Implementations MAY provide the associated functionality in any way they choose. This section defines only the requirements for APD administration and the consequences of successfully validating a peer's identity against it. The APD consists of a list of entries. Each entry includes an identity, the namespace from which the identity comes (e.g., DNS domains), the scope within which the entry is applicable, and whether authorisation is allowed or denied. The following are example scopes: Peer Address Ownership: The scope is the IP address at which the peer for this MRI should be; the APD entry denotes the identity as the owner of address. If the authorising node can determine this address from local information (such as its own routing tables), matching this entry shows that the peer is the correct on-path node and so should be authorised. The determination is simple if the peer is one IP hop downstream, since the IP address can be derived from the router's forwarding tables. If the peer is more than one hop away or is upstream, the determination is harder but may still be possible in some circumstances. The authorising node may be able to determine a (small) set of possible peer addresses, and accept that any of these could be the correct peer. End-System Subnet: The scope is an address range within which the MRI source or destination lies; the APD entry denotes the identity as potentially being on-path between the authorising node and that address range. There may be different source and destination scopes, to account for asymmetric routing. The same identity may appear in multiple entries, and the order of entries in the APD is significant. When a messaging association is authenticated and associated with an MRI, the authorising node scans the APD to find the first entry where the identity matches that presented by the peer, and where the scope information matches the circumstances for which the MA is being set up. The identity matching process itself depends on the messaging association protocol that carries out the authentication, and details for TLS are given in Section 5.7.3. Whenever the full set of possible peers for a specific scope is known, deny entries SHOULD be added for the wildcard identity to reject signalling associations from unknown nodes. The ability of the authorising node to reject inappropriate MAs depends directly on the granularity of the APD and the precision of the scope matching process.
If authorisation is allowed, the MA can be used as normal; otherwise, it MUST be torn down without further GIST exchanges, and any routing state associated with the MA MUST also be deleted. An error condition MAY be logged locally. When an APD entry is modified or deleted, the node MUST re-validate existing MAs and the routing state table against the revised contents of the APD. This may result in MAs being torn down or routing state entries being deleted. These changes SHOULD be indicated to local signalling applications via the NetworkNotification API call (Appendix B.4). This specification does not define how the APD is populated. As a minimum, an implementation MUST provide an administrative interface through which entries can be added, modified, or deleted. More sophisticated mechanisms are possible in some scenarios. For example, the fact that a node is legitimately associated with a specific IP address could be established by direct embedding of the IP address as a particular identity type in a certificate, or by a mapping that address to another identifier type via an additional database lookup (such as relating IP addresses in in-addr.arpa to domain names). An enterprise network operator could generate a list of all the identities of its border nodes as authorised to be on the signalling path to external destinations, and this could be distributed to all hosts inside the network. Regardless of the technique, it MUST be ensured that the source data justify the authorisation decisions listed at the start of this section, and that the security of the chain of operations on which the APD entry depends cannot be compromised.4.4.3. Messaging Association Multiplexing
It is a design goal of GIST that, as far as possible, a single messaging association should be used for multiple flows and sessions between two peers, rather than setting up a new MA for each. This re-use of existing MAs is referred to as messaging association multiplexing. Multiplexing ensures that the MA cost scales only with the number of peers, and avoids the latency of new MA setup where possible. However, multiplexing requires the identification of an existing MA that matches the same routing state and desired properties that would be the result of a normal handshake in D-mode, and this identification must be done as reliably and securely as continuing with a normal D-mode handshake. Note that this requirement is complicated by the fact that NATs may remap the node addresses in D-mode messages, and also interacts with the fact that some nodes may peer over multiple interfaces (and thus with different addresses).
MA multiplexing is controlled by the Network Layer Information (NLI)
object, which is carried in Query, Response, and Confirm messages.
The NLI object includes (among other elements):
Peer-Identity: For a given node, this is an interface-independent
value with opaque syntax. It MUST be chosen so as to have a high
probability of uniqueness across the set of all potential peers,
and SHOULD be stable at least until the next node restart. Note
that there is no cryptographic protection of this identity;
attempting to provide this would essentially duplicate the
functionality in the messaging association security protocols.
For routers, the Router-ID [2], which is one of the router's IP
addresses, MAY be used as one possible value for the Peer-
Identity. In scenarios with nested NATs, the Router-ID alone may
not satisfy the uniqueness requirements, in which case it MAY be
extended with additional tokens, either chosen randomly or
administratively coordinated.
Interface-Address: This is an IP address through which the
signalling node can be reached. There may be several choices
available for the Interface-Address, and further discussion of
this is contained in Section 5.2.2.
A messaging association is associated with the NLI object that was
provided by the peer in the Query/Response/Confirm at the time the
association was first set up. There may be more than one MA for a
given NLI object, for example, with different security or transport
properties.
MA multiplexing is achieved by matching these two elements from the
NLI provided in a new GIST message with one associated with an
existing MA. The message can be either a Query or Response, although
the former is more likely:
o If there is a perfect match to an existing association, that
association SHOULD be re-used, provided it meets the criteria on
security and transport properties given at the end of
Section 5.7.1. This is indicated by sending the remaining
messages in the handshake over that association. This will lead
to multiplexing on an association to the wrong node if signalling
nodes have colliding Peer-Identities and one is reachable at the
same Interface-Address as another. This could be caused by an on-
path attacker; on-path attacks are discussed further in
Section 8.7. When multiplexing is done, and the original MA
authorisation was MRI-dependent, the verification steps of
Section 4.4.2 MUST be repeated for the new flow.
o In all other cases, the handshake MUST be executed in D-mode as
usual. There are in fact four possibilities:
1. Nothing matches: this is clearly a new peer.
2. Only the Peer-Identity matches: this may be either a new
interface on an existing peer or a changed address mapping
behind a NAT. These should be rare events, so the expense of
a new association setup is acceptable. Another possibility is
one node using another node's Peer-Identity, for example, as
some kind of attack. Because the Peer-Identity is used only
for this multiplexing process, the only consequence this has
is to require a new association setup, and this is considered
in Section 8.4.
3. Only the Interface-Address matches: this is probably a new
peer behind the same NAT as an existing one. A new
association setup is required.
4. Both elements of the NLI object match: this is a degenerate
case, where one node recognises an existing peer, but wishes
to allow the option to set up a new association in any case,
for example, to create an association with different
properties.
4.4.4. Routing State Maintenance
Each item of routing state expires after a lifetime that is
negotiated during the Query/Response/Confirm handshake. The Network
Layer Information (NLI) object in the Query contains a proposal for
the lifetime value, and the NLI in the Response contains the value
the Responding node requires. A default timer value of 30 seconds is
RECOMMENDED. Nodes that can exploit alternative, more powerful,
route change detection methods such as those described in
Section 7.1.2 MAY choose to use much longer times. Nodes MAY use
shorter times to provide more rapid change detection. If the number
of active routing state items corresponds to a rate of Queries that
will stress the rate limits applied to D-mode traffic
(Section 5.3.3), nodes MUST increase the timer for new items and on
the refresh of existing ones. A suitable value is
2 * (number of routing states) / (rate limit in packets/second)
which leaves a factor of two headroom for new routing state creation
and Query retransmissions.
The Querying node MUST ensure that a Query is received before this timer expires, if it believes that the signalling session is still active; otherwise, the Responding node MAY delete the state. Receipt of the message at the Responding node will refresh peer addressing state for one direction, and receipt of a Response at the Querying node will refresh it for the other. There is no mechanism at the GIST level for explicit teardown of routing state. However, GIST MUST NOT refresh routing state if a signalling session is known to be inactive, either because upstream state has expired or because the signalling application has indicated via the GIST API (Appendix B.5) that the state is no longer required, because this would prevent correct state repair in the case of network rerouting at the IP layer. This specification defines precisely only the time at which routing state expires; it does not define when refresh handshakes should be initiated. Implementations MUST select timer settings that take at least the following into account: o the transmission latency between source and destination; o the need for retransmissions of Query messages; o the need to avoid network synchronisation of control traffic (cf. [42]). In most cases, a reasonable policy is to initiate the routing state refresh when between 1/2 and 3/4 of the validity time has elapsed since the last successful refresh. The actual moment MUST be chosen randomly within this interval to avoid synchronisation effects.4.4.5. Messaging Association Maintenance
Unneeded MAs are torn down by GIST, using the teardown mechanisms of the underlying transport or security protocols if available, for example, by simply closing a TCP connection. The teardown can be initiated by either end. Whether an MA is needed is a combination of two factors: o local policy, which could take into account the cost of keeping the messaging association open, the level of past activity on the association, and the likelihood of future activity, e.g., if there is routing state still in place that might generate messages to use it. o whether the peer still wants the MA to remain in place. During MA setup, as part of the Stack-Configuration-Data, each node advertises its own MA-Hold-Time, i.e., the time for which it will
retain an MA that is not carrying signalling traffic. A node MUST
NOT tear down an MA if it has received traffic from its peer over
that period. A peer that has generated no traffic but still wants
the MA retained can use a special null message (MA-Hello) to
indicate the fact. A default value for MA-Hold-Time of 30 seconds
is RECOMMENDED. Nodes MAY use shorter times to achieve more rapid
peer failure detection, but need to take into account the load on
the network created by the MA-Hello messages. Nodes MAY use
longer times, but need to take into account the cost of retaining
idle MAs for extended periods. Nodes MAY take signalling
application behaviour (e.g., NSLP refresh times) into account in
choosing an appropriate value.
Because the Responding node can choose not to create state until a
Confirm, an abbreviated Stack-Configuration-Data object containing
just this information from the initial Query MUST be repeated by
the Querying node in the first Confirm sent on a new MA. If the
object is missing in the Confirm, an "Object Type Error" message
(Appendix A.4.4.9) with subcode 2 ("Missing Object") MUST be
returned.
Messaging associations can always be set up on demand, and messaging
association status is not made directly visible outside the GIST
layer. Therefore, even if GIST tears down and later re-establishes a
messaging association, signalling applications cannot distinguish
this from the case where the MA is kept permanently open. To
maintain the transport semantics described in Section 4.1, GIST MUST
close transport connections carrying reliable messages gracefully or
report an error condition, and MUST NOT open a new association to be
used for given session and peer while messages on a previous
association could still be outstanding. GIST MAY use an MA-Hello
request/reply exchange on an existing association to verify that
messages sent on it have reached the peer. GIST MAY use the same
technique to test the liveness of the underlying MA protocols
themselves at arbitrary times.
This specification defines precisely only the time at which messaging
associations expire; it does not define when keepalives should be
initiated. Implementations MUST select timer settings that take at
least the following into account:
o the transmission latency between source and destination;
o the need for retransmissions within the messaging association
protocols;
o the need to avoid network synchronisation of control traffic (cf.
[42]).
In most cases, a reasonable policy is to initiate the MA refresh when between 1/2 and 3/4 of the validity time has elapsed since the last successful refresh. The actual moment MUST be chosen randomly within this interval to avoid synchronisation effects.4.4.6. Routing State Failures
A GIST node can receive a message from a GIST peer that can only be correctly processed in the context of some routing state, but where no corresponding routing state exists. Cases where this can arise include: o Where the message is random traffic from an attacker, or backscatter (replies to such traffic). o Where routing state has been correctly installed but the peer has since lost it, for example, because of aggressive timeout settings at the peer or because the node has crashed and restarted. o Where the routing state was not correctly installed in the first place, but the sending node does not know this. This can happen if the Confirm message of the handshake is lost. It is important for GIST to recover from such situations promptly where they represent genuine errors (node restarts, or lost messages that would not otherwise be retransmitted). Note that only Response, Confirm, Data, and Error messages ever require routing state to exist, and these are considered in turn: Response: A Response can be received at a node that never sent (or has forgotten) the corresponding Query. If the node wants routing state to exist, it will initiate it itself; a diagnostic error would not allow the sender of the Response to take any corrective action, and the diagnostic could itself be a form of backscatter. Therefore, an error message MUST NOT be generated, but the condition MAY be logged locally. Confirm: For a Responding node that implements delayed state installation, this is normal behaviour, and routing state will be created provided the Confirm is validated. Otherwise, this is a case of a non-existent or forgotten Response, and the node may not have sufficient information in the Confirm to create the correct state. The requirement is to notify the Querying node so that it can recover the routing state.
Data: This arises when a node receives Data where routing state is
required, but either it does not exist at all or it has not been
finalised (no Confirm message). To avoid Data being black-holed,
a notification must be sent to the peer.
Error: Some error messages can only be interpreted in the context of
routing state. However, the only error messages that require a
reply within the protocol are routing state error messages
themselves. Therefore, this case should be treated the same as a
Response: an error message MUST NOT be generated, but the
condition MAY be logged locally.
For the case of Confirm or Data messages, if the state is required
but does not exist, the node MUST reject the incoming message with a
"No Routing State" error message (Appendix A.4.4.5). There are then
three cases at the receiver of the error message:
No routing state: The condition MAY be logged but a reply MUST NOT
be sent (see above).
Querying node: The node MUST restart the GIST handshake from the
beginning, with a new Query.
Responding node: The node MUST delete its own routing state and
SHOULD report an error condition to the local signalling
application.
The rules at the Querying or Responding node make GIST open to
disruption by randomly injected error messages, similar to blind
reset attacks on TCP (cf. [46]), although because routing state
matching includes the SID this is mainly limited to on-path
attackers. If a GIST node detects a significant rate of such
attacks, it MAY adopt a policy of using secured messaging
associations to communicate for the affected MRIs, and only accepting
"No Routing State" error messages over such associations.
(page 45 continued on part 3)