Next Steps in Signaling H. Schulzrinne
Internet-Draft Columbia U.
Intended status: Standards Track R. Hancock
Expires: August 31, 2007 Siemens/RMR
February 27, 2007
GIST: General Internet Signalling Transport
draft-ietf-nsis-ntlp-12
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 31, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Schulzrinne & Hancock Expires August 31, 2007 [Page 1]
Internet-Draft GIST February 2007
Abstract
This document specifies protocol stacks for the routing and transport
of per-flow signalling messages along the path taken by that flow
through the network. The design uses existing transport and security
protocols under a common messaging layer, the General Internet
Signalling Transport (GIST), which provides a common service for
diverse signalling applications. GIST does not handle signalling
application state itself, but manages its own internal state and the
configuration of the underlying transport and security protocols to
enable the transfer of messages in both directions along the flow
path. The combination of GIST and the lower layer transport and
security protocols provides a solution for the base protocol
component of the "Next Steps in Signalling" framework.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation and Terminology . . . . . . . . . . . . 6
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 9
3.2. Modes and Messaging Associations . . . . . . . . . . . . 10
3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 12
3.4. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 14
3.5. GIST Peering Relationships . . . . . . . . . . . . . . . 14
3.6. Effect on Internet Transparency . . . . . . . . . . . . . 15
3.7. Signalling Sessions . . . . . . . . . . . . . . . . . . . 16
3.8. Signalling Applications and NSLPIDs . . . . . . . . . . . 17
3.9. GIST Security Services . . . . . . . . . . . . . . . . . 17
3.10. Example of Operation . . . . . . . . . . . . . . . . . . 18
4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 21
4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 21
4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 23
4.3. Basic GIST Message Processing . . . . . . . . . . . . . . 25
4.4. Routing State and Messaging Association Maintenance . . . 32
5. Message Formats and Transport . . . . . . . . . . . . . . . . 45
5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 45
5.2. Information Elements . . . . . . . . . . . . . . . . . . 47
5.3. D-mode Transport . . . . . . . . . . . . . . . . . . . . 51
5.4. C-mode Transport . . . . . . . . . . . . . . . . . . . . 56
5.5. Message Type/Encapsulation Relationships . . . . . . . . 57
5.6. Error Message Processing . . . . . . . . . . . . . . . . 58
5.7. Messaging Association Setup . . . . . . . . . . . . . . . 59
5.8. Specific Message Routing Methods . . . . . . . . . . . . 63
6. Formal Protocol Specification . . . . . . . . . . . . . . . . 69
6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 71
6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 72
Schulzrinne & Hancock Expires August 31, 2007 [Page 2]
Internet-Draft GIST February 2007
6.3. Responder Node Processing . . . . . . . . . . . . . . . . 75
6.4. Messaging Association Processing . . . . . . . . . . . . 78
7. Additional Protocol Features . . . . . . . . . . . . . . . . 82
7.1. Route Changes and Local Repair . . . . . . . . . . . . . 82
7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 89
7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 94
7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 95
8. Security Considerations . . . . . . . . . . . . . . . . . . . 97
8.1. Message Confidentiality and Integrity . . . . . . . . . . 97
8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 98
8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 98
8.4. Denial of Service Prevention and Overload Protection . . 100
8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 102
8.6. Security Protocol Selection Policy . . . . . . . . . . . 103
8.7. Residual Threats . . . . . . . . . . . . . . . . . . . . 104
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 111
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 112
11.1. Normative References . . . . . . . . . . . . . . . . . . 112
11.2. Informative References . . . . . . . . . . . . . . . . . 113
Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 116
A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 116
A.2. General Object Format . . . . . . . . . . . . . . . . . . 117
A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 118
A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 127
Appendix B. API between GIST and Signalling Applications . . . . 136
B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 136
B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 138
B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 139
B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 140
B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 141
B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 141
Appendix C. Deployment Issues with Router Alert Options . . . . 142
Appendix D. Example Routing State Table and Handshake . . . . . 145
Appendix E. Change History . . . . . . . . . . . . . . . . . . . 147
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 172
Intellectual Property and Copyright Statements . . . . . . . . . 173
Schulzrinne & Hancock Expires August 31, 2007 [Page 3]
Internet-Draft GIST February 2007
1. Introduction
Signalling involves the manipulation of state held in network
elements. 'Manipulation' could mean setting up, modifying and
tearing down state; or it could simply mean the monitoring of state
which is managed by other mechanisms.
This specification concentrates mainly on path-coupled signalling,
controlling resources on network elements which are located on the
path taken by a particular data flow, possibly including but not
limited to the flow endpoints. Indeed, there are almost always more
than two participants in a path-coupled signalling session, although
there is no need for every node on the path to participate. Path-
coupled signalling thus excludes end-to-end higher-layer application
signalling. In the context of path-coupled signalling, examples of
state management include network resource reservation, firewall
configuration, and state used in active networking; examples of state
monitoring are the discovery of instantaneous path properties, such
as available bandwidth or cumulative queuing delay. Each of these
different uses of signalling is referred to as a signalling
application. GIST path-coupled signalling does not directly support
multicast flows but could be extended to do so, especially in
environments where the multicast replication points can be made GIST-
capable. GIST can also be extended to cover other types of
signalling pattern, not related to any end-to-end flow in the
network, in which case the distinction between GIST and end-to-end
higher-layer signalling will be drawn differently or not at all.
Every signalling application requires a set of state management
rules, as well as protocol support to exchange messages along the
data path. Several aspects of this protocol support are common to
all or a large number of signalling applications, and hence can be
developed as a common protocol. The NSIS framework given in [31]
provides a rationale for a function split between the common and
application specific protocols, and gives outline requirements for
the former, the 'NSIS Transport Layer Protocol' (NTLP). The
application specific protocols are referred to as 'NSIS Signalling
Layer Protocols' (NSLPs), and are defined in separate documents. The
NSIS framework, and the accompanying threats document [32], provide
important background information to this specification, including
information on how GIST is expected to be used in various network
types and what role it is expected to perform.
This specification provides a concrete solution for the NTLP. It is
based on the use of existing transport and security protocols under a
common messaging layer, the General Internet Signalling Transport
(GIST). GIST does not handle signalling application state itself; in
that crucial respect, it differs from application signalling
Schulzrinne & Hancock Expires August 31, 2007 [Page 4]
Internet-Draft GIST February 2007
protocols such as SIP, RTSP, and the control component of FTP.
Instead, GIST manages its own internal state and the configuration of
the underlying transport and security protocols to ensure the
transfer of signalling messages on behalf of signalling applications
in both directions along the flow path.
The structure of this specification is as follows. Section 2 defines
terminology, and Section 3 gives an informal overview of the protocol
design principles and operation. The normative specification is
contained mainly in Section 4 to Section 8. Section 4 describes the
message sequences and Section 5 their format and contents. Note that
the detailed bit formats are given in Appendix A. The protocol
operation is captured in the form of state machine language in
Section 6. Section 7 describes some more advanced protocol features
and security considerations are contained in Section 8. In addition,
Appendix B describes an abstract API for the service which GIST
provides to signalling applications, and Appendix D provides an
example message flow. Parts of the GIST design depend on the use of
packets with IP options to probe the network, which leads to
migration issues in networks with non-GIST nodes, especially in the
case of IPv4, and these are discussed in Appendix C.
Because of the layered structure of the NSIS protocol suite, protocol
extensions to cover a new signalling requirement could be carried out
either within GIST, or within the signalling application layer, or
both. General guidelines on how to extend different layers of the
protocol suite, and in particular when and how it is appropriate to
extend GIST, are contained in a separate document, [15]. In this
document, Section 9 gives the formal IANA considerations for the
registries already defined by the GIST specification.
Schulzrinne & Hancock Expires August 31, 2007 [Page 5]
Internet-Draft GIST February 2007
2. Requirements Notation and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4]. In
addition, the security specifications in Section 5.7.3 use the
terminology MUST- and SHOULD+ from [5].
The terminology used in this specification is defined in this
section. The basic entities relevant at the GIST level are shown in
Figure 1. In particular, this diagram distinguishes the different
address types as being associated with a flow (end-to-end addresses)
or signalling (addresses of adjacent signalling peers).
Source GIST (adjacent) peer nodes Destination
IP address IP addresses = Signalling IP address
= Flow Source/Destination Addresses = Flow
Source (depending on signalling direction) Destination
Address | | Address
V V
+--------+ +------+ Data Flow +------+ +--------+
| Flow |-----------|------|-------------|------|-------->| Flow |
| Sender | | | | | |Receiver|
+--------+ | GIST |============>| GIST | +--------+
| Node |<============| Node |
+------+ Signalling +------+
GN1 Flow GN2
>>>>>>>>>>>>>>>>> = Downstream direction
<<<<<<<<<<<<<<<<< = Upstream direction
Figure 1: Basic Terminology
[Data] Flow: A set of packets identified by some fixed combination
of header fields. Flows are unidirectional; a bidirectional
communication is considered a pair of unidirectional flows.
Session: A single application layer flow of information for which
some state information is to be manipulated or monitored. See
Section 3.7 for further detailed discussion.
Session Identifier (SID): An identifier for a session; the syntax is
a 128 bit opaque value.
Schulzrinne & Hancock Expires August 31, 2007 [Page 6]
Internet-Draft GIST February 2007
[Flow] Sender: The node in the network which is the source of the
packets in a flow. A sender could be a host, or a router if for
example the flow is actually an aggregate.
[Flow] Receiver: The node in the network which is the sink for the
packets in a flow.
Downstream: In the same direction as the data flow.
Upstream: In the opposite direction to the data flow.
GIST Node: Any node along the data path supporting GIST, regardless
of what signalling applications it supports.
[Adjacent] Peer: The next node along the signalling path, in the
upstream or downstream direction, with which a GIST node
explicitly interacts.
Datagram Mode (D-mode): A mode of sending GIST messages between
nodes without using any transport layer state or security
protection. Datagram mode uses UDP encapsulation, with source and
destination IP addresses derived either from the flow definition
or previously discovered adjacency information.
Connection Mode (C-mode): A mode of sending GIST messages directly
between nodes using point-to-point messaging associations (see
below). Connection mode allows the re-use of existing transport
and security protocols where such functionality is required.
Messaging Association (MA): A single connection between two
explicitly identified GIST adjacent peers, i.e. between a given
signalling source and destination address. A messaging
association may use a specific transport protocol and known ports.
If security protection is required, it may use a specific network
layer security association, or use a transport layer security
association internally. A messaging association is bidirectional;
signalling messages can be sent over it in either direction, and
can refer to flows of either direction.
[Message] Routing: Message routing describes the process of
determining which is the next GIST peer along the signalling path.
For signalling along a flow path, the message routing carried out
by GIST is built on top of normal IP routing. In this document,
the term 'routing' generally refers to GIST message routing unless
otherwise qualified.
Schulzrinne & Hancock Expires August 31, 2007 [Page 7]
Internet-Draft GIST February 2007
Message Routing Method (MRM): There can be different algorithms for
discovering the route that signalling messages should take. These
are referred to as message routing methods, and GIST supports
alternatives within a common protocol framework. See Section 3.3.
Message Routing Information (MRI): The set of data item values which
is used to route a signalling message according to a particular
MRM; for example, for routing along a flow path, the MRI includes
flow source and destination addresses, protocol and port numbers.
See Section 3.3.
Transfer Attributes: A description of the requirements which a
signalling application has for the delivery of a particular
message; for example, whether the message should be delivered
reliably. See Section 4.1.2.
Router Alert Option (RAO): An option that can be included in IP v4
and v6 headers to assist in the packet interception process; see
[3] and [8].
Schulzrinne & Hancock Expires August 31, 2007 [Page 8]
Internet-Draft GIST February 2007
3. Design Overview
3.1. Overall Design Approach
The generic requirements identified in the NSIS framework [31] for
transport of signalling messages are essentially two-fold:
Routing: Determine how to reach the adjacent signalling node along
each direction of the data path (the GIST peer), and if necessary
explicitly establish addressing and identity information about
that peer;
Transport: Deliver the signalling information to that peer.
To meet the routing requirement, one possibility is for the node to
use local routing state information to determine the identity of the
GIST peer explicitly. GIST defines a three-way handshake which
probes the network to set up the necessary routing state between
adjacent peers, during which signalling applications can also
exchange data. Once the routing decision has been made, the node has
to select a mechanism for transport of the message to the peer. GIST
divides the transport problems into two categories, the easy and the
difficult. It handles the easy cases internally, and uses well-
understood transport protocols for the harder cases. Here, with
details discussed later, "easy" messages are those that are sized
well below the lowest maximum transmission unit (MTU) along a path,
are infrequent enough not to cause concerns about congestion and flow
control, and do not need security protection or guaranteed delivery.
In [31] all of these routing and transport requirements are assigned
to a single notional protocol, the NSIS Transport Layer Protocol
(NTLP). The strategy of splitting the transport problem leads to a
layered structure for the NTLP, of a specialised GIST messaging layer
running over standard transport and security protocols. The basic
concept is shown in Figure 2. Note that not every combination of
transport and security protocols implied by the figure is actually
possible for use in GIST; the actual combinations allowed by this
specification are defined in Section 5.7. The figure also shows GIST
offering its services to upper layers at an abstract interface, the
GIST API, further discussed in Section 4.1.
Schulzrinne & Hancock Expires August 31, 2007 [Page 9]
Internet-Draft GIST February 2007
^^ +-------------+
|| | Signalling |
NSIS +------------|Application 2|
Signalling | Signalling +-------------+
Application |Application 1| |
Level +-------------+ |
|| | |
VV | |
========|===================|===== <-- GIST API
| |
^^ +------------------------------------------------+
|| |+-----------------------+ +--------------+ |
|| || GIST | | GIST State | |
|| || Encapsulation |<<<>>>| Maintenance | |
|| |+-----------------------+ +--------------+ |
|| | GIST: Messaging Layer |
|| +------------------------------------------------+
NSIS | | | |
Transport ..........................................
Level . Transport Layer Security (TLS or DTLS) .
(NTLP) ..........................................
|| | | | |
|| +----+ +----+ +----+ +----+
|| |UDP | |TCP | |SCTP| |DCCP| ... other
|| +----+ +----+ +----+ +----+ protocols
|| | | | |
|| .............................
|| . IP Layer Security .
|| .............................
VV | | | |
===========================|=======|=======|=======|============
| | | |
+----------------------------------------------+
| IP |
+----------------------------------------------+
Figure 2: Protocol Stack Architecture for Signalling Transport
3.2. Modes and Messaging Associations
Internally, GIST has two modes of operation:
Datagram mode (D-mode): used for small, infrequent messages with
modest delay constraints and no security requirements. A special
case of D-mode called Query-mode (Q-mode) is used when no routing
state exists.
Schulzrinne & Hancock Expires August 31, 2007 [Page 10]
Internet-Draft GIST February 2007
Connection mode (C-mode): used for larger messages or where fast
state setup in the face of packet loss is desirable, or where
channel security is required.
D-mode uses UDP, as a suitable NAT-friendly encapsulation which does
not require per-message shared state to be maintained between the
peers. It is currently an assumption that long-term evolution of
GIST will preserve the simplicity of the current D-mode design.
Extensions to the security or transport capabilities of D-mode can be
provided equivalently by selecting a different protocol stack under
the GIST messaging layer, which would then become another option
within the overall C-mode framework. This includes both the case of
using existing protocols, and specific development of a message
exchange and payload encapsulation to support GIST requirements.
Alternatively, if any necessary parameters (e.g. a shared secret for
use in integrity or confidentiality protection) can be negotiated
out-of-band, then the additional functions can be added directly to
D-mode by adding an optional object to the message (see
Appendix A.2.1). Note that downgrade attacks on such approach would
need to be prevented by policy at the destination node, similar to
the situation discussed in Section 8.6.
C-mode can in principle use any stream or message-oriented transport
protocol; this specification defines TCP as the initial choice. It
can in principle employ specific network layer security associations,
or an internal transport layer security association; this
specification defines TLS as the initial choice. When GIST messages
are carried in C-mode, they are treated just like any other traffic
by intermediate routers between the GIST peers. Indeed, it would be
impossible for intermediate routers to carry out any processing on
the messages without terminating the transport and security protocols
used.
It is possible to mix these two modes along a path. This allows, for
example, the use of D-mode at the edges of the network and C-mode in
the core of the network. Such combinations may make operation more
efficient for mobile endpoints, while allowing multiplexing of
signalling messages across shared security associations and transport
connections between core routers. The setup for these protocols
imposes an initialisation cost for the use of C-mode, but in the long
term this cost can be shared over all signalling sessions between
peers; once the transport layer state exists, retransmission
algorithms can operate much more aggressively than would be possible
in a pure D-mode design.
It must be understood that the routing and transport decisions made
by GIST are not independent. If the message transfer has
requirements that require C-mode, for example if the message is so
Schulzrinne & Hancock Expires August 31, 2007 [Page 11]
Internet-Draft GIST February 2007
large that fragmentation is required, this can only be used between
explicitly identified nodes. In such cases, GIST carries out the
three-way handshake initially in D-mode to identify the peer and then
sets up the necessary connections if they do not already exist. It
must also be understood that the signalling application does not make
the D-mode/C-mode selection directly; rather, this decision is made
by GIST on the basis of the message characteristics and the transfer
attributes stated by the application. The distinction is not visible
at the GIST service interface.
In general, the state associated with C-mode messaging to a
particular peer (signalling destination address, protocol and port
numbers, internal protocol configuration and state information) is
referred to as a messaging association (MA). MAs are totally
internal to GIST (they are not visible to signalling applications).
Although GIST may be using an MA to deliver messages about a
particular flow, there is no direct correspondence between them: the
GIST message routing algorithms consider each message in turn and
select an appropriate MA to transport it. There may be any number of
MAs between two GIST peers although the usual case is zero or one,
and they are set up and torn down by management actions within GIST
itself.
3.3. Message Routing Methods
The baseline message routing functionality in GIST is that signalling
messages follow a route defined by an existing flow in the network,
visiting a subset of the nodes through which it passes. This is the
appropriate behaviour for application scenarios where the purpose of
the signalling is to manipulate resources for that flow. However,
there are scenarios for which other behaviours are applicable. Two
examples are:
Predictive Routing: Here, the intent is to signal along a path that
the data flow may follow in the future. Possible cases are pre-
installation of state on the backup path that would be used in the
event of a link failure, and predictive installation of state on
the path that will be used after a mobile node handover.
NAT Address Reservations: This applies to the case where a node
behind a NAT wishes to reserve an address at which it can be
reached by a sender on the other side. This requires a message to
be sent outbound from what will be the flow receiver although no
reverse routing state for the flow yet exists.
Most of the details of GIST operation are independent of which is
being used. Therefore, the GIST design encapsulates the routing-
dependent details as a message routing method (MRM), and allows
Schulzrinne & Hancock Expires August 31, 2007 [Page 12]
Internet-Draft GIST February 2007
multiple MRMs to be defined. The default is the path-coupled MRM,
which corresponds to the baseline functionality described above; a
second MRM for the NAT Address Reservation case is also defined.
The content of a MRM definition is as follows, using the path-coupled
MRM as an example:
o The format of the information that describes the path that the
signalling should take, the Message Routing Information (MRI).
For the path-coupled MRM, this is just the Flow Identifier (see
Section 5.8.1.1) and some additional control information.
Specifically, the MRI always includes a flag to distinguish
between the two directions that signalling messages can take,
denoted 'upstream' and 'downstream'.
o A specification of the IP-level encapsulation of the messages
which probe the network to discover the adjacent peers. A
downstream encapsulation must be defined; an upstream
encapsulation is optional. For the path-coupled MRM, this
information is given in Section 5.8.1.2 and Section 5.8.1.3.
Current MRMs rely on the interception of probe messages in the
data plane, but other mechanisms are also possible within the
overall GIST design and would be appropriate for other types of
signalling pattern.
o A specification of what validation checks GIST should apply to the
probe messages, for example to protect against IP address spoofing
attacks. The checks may be dependent on the direction (upstream
or downstream) of the message. For the path-coupled MRM, the
downstream validity check is basically a form of ingress
filtering, also discussed in Section 5.8.1.2.
o The mechanism(s) available for route change detection, i.e. any
change in the neighbour relationships that the MRM discovers. The
default case for any MRM is soft-state refresh, but additional
supporting techniques may be possible; see Section 7.1.2.
In addition, it should be noted that NAT traversal may require
translation of fields in the MRI object carried in GIST messages (see
Section 7.2.2). The generic MRI format includes a flag that must be
given as part of the MRM definition, to indicate if some kind of
translation is necessary. Development of a new MRM therefore
includes updates to the GIST specification, and may include updates
to specifications of NAT behaviour. These updates may be done in
separate documents as is the case for NAT traversal for the MRMs of
the base GIST specification, as described in Section 7.2.3 and [43].
The MRI is passed explicitly between signalling applications and
Schulzrinne & Hancock Expires August 31, 2007 [Page 13]
Internet-Draft GIST February 2007
GIST; therefore, signalling application specifications must define
which MRMs they require. Signalling applications may use fields in
the MRI in their packet classifiers; if they use additional
information for packet classification, this would be carried at the
NSLP level and so would be invisible to GIST. Any node hosting a
particular signalling application needs to use a GIST implementation
that supports the corresponding MRMs. The GIST processing rules
allow nodes not hosting the signalling application to ignore messages
for it at the GIST level, so it does not matter if these nodes
support the MRM or not.
3.4. GIST Messages
GIST has six message types: Query, Response, Confirm, Data, Error,
and MA-Hello. Apart from the invocation of the messaging association
protocols, all GIST communication consists of these messages. In
addition, all signalling application data is carried as additional
payloads in these messages, alongside the GIST information.
The first three messages implement the handshake that GIST uses to
set up routing state and messaging associations. The handshake is
initiated from the Querying node towards the Responding node. The
first message is the Query, which is encapsulated in a special way
depending on the message routing method, in order to probe the
network infrastructure so that the correct peer will intercept it and
become the Responding node. A Query always triggers a Response in
the reverse direction as the second message of the handshake. As
part of the defence against denial of service attacks, the Responding
node can delay state installation until a return routability check,
and require the Querying node to complete the handshake with the
Confirm. All of these three messages can optionally carry signalling
application data. The handshake is fully described in Section 4.4.1.
The Data message is used purely to encapsulate and deliver signalling
application data. Usually it is sent using pre-established routing
state. However, if there are no security or transport requirements
and no need for persistent reverse routing state, it can also be sent
in the same way as the Query. Finally, Error messages are used to
indicate error conditions at the GIST level, and the MA-Hello message
can be used as a diagnostic and keepalive for the messaging
association protocols.
3.5. GIST Peering Relationships
Peering is the process whereby two GIST nodes create message routing
state which point to each other.
A peering relationship can only be created by a GIST handshake.
Schulzrinne & Hancock Expires August 31, 2007 [Page 14]
Internet-Draft GIST February 2007
Nodes become peers when one issues a Query and gets a Response from
another. Issuing the initial Query is a result of an NSLP request on
that node, and the Query itself is formatted according to the rules
of the message routing method. For current MRMs, the identity of the
Responding node is not known explicitly at the time the Query is
sent; instead, the message is examined by nodes along the path until
one decides to send a Response, thereby becoming the peer. If the
node hosts the NSLP, local GIST and signalling application policy
determine whether to peer; the details are given in Section 4.3.2.
Nodes not hosting the NSLP forward the Query transparently
(Section 4.3.4).
An exisiting peering relationship can only be changed by a new GIST
handshake; in other words, it can only change when routing state is
refreshed. On a refresh, if any of the factors in the original
peering process have changed, the peering relationship can also
change. As well as network level rerouting, changes could include
modifications in NSIS signalling functions deployed at a node, or
alterations to signalling application policy. A change could cause
an existing node to drop out of the signalling path, or a new node to
become part of it. All these possibilities are handled as rerouting
events by GIST; further details of the process are described in
Section 7.1.
3.6. Effect on Internet Transparency
GIST relies on routers inside the network to intercept and process
packets which would normally be transmitted end-to-end. This
processing may be non-transparent: messages may be forwarded with
modifications, or not forwarded at all. This interception applies
only to the encapsulation used for messages which initially probe the
network, for example along a flow path; all other GIST messages are
handled only by the nodes to which they are directly addressed, i.e.
as normal Internet traffic.
Because this interception potentially breaks Internet transparency
for packets which are nothing to do with GIST, the encapsulation used
by GIST in this case (called Query-mode or Q-mode) has several
features to avoid accidental collisions with other traffic:
o Q-mode messages are always sent as UDP traffic, and to a specific
well-known port allocated by IANA.
o The first 32-bit word of the UDP datagram payload contains a magic
number.
Even if a node intercepts a packet as potentially a GIST message,
unless it passes both these checks it will be ignored at the GIST
Schulzrinne & Hancock Expires August 31, 2007 [Page 15]
Internet-Draft GIST February 2007
level and forward transparently. Further discussion of the reception
process is in Section 4.3.1 and the encapsulation in Section 5.3.2.
3.7. Signalling Sessions
GIST requires signalling applications to associate each of their
messages with a signalling session. Informally, given an application
layer exchange of information for which some network control state
information is to be manipulated or monitored, the corresponding
signalling messages should be associated with the same session.
Signalling applications provide the session identifier (SID) whenever
they wish to send a message, and GIST reports the SID when a message
is received; on messages forwarded at the GIST level, the SID is
preserved unchanged. Usually, NSLPs will preserve the SID value
along the entire signalling path, but this is not enforced by or even
visible to GIST, which only sees the scope of the SID as the single
hop between adjacent NSLP peers.
Most GIST processing and state information is related to the flow
(defined by the MRI, see above) and signalling application (given by
the NSLP identifier, see below). There are several possible
relationships between flows and sessions, for example:
o The simplest case is that all messages for the same flow have the
same SID.
o Messages for more than one flow may use the same SID, for example
because one flow is replacing another in a mobility or multihoming
scenario.
o A single flow may have messages for different SIDs, for example
from independently operating signalling applications.
Because of this range of options, GIST does not perform any
validation on how signalling applications map between flows and
sessions, nor does it perform any direct validation on the properties
of the SID itself, such as any enforcement of uniqueness. GIST only
defines the syntax of the SID as an opaque 128-bit identifier.
The SID assignment has the following impact on GIST processing:
o Messages with the same SID that are to be delivered reliably
between the same GIST peers are delivered in order.
o All other messages are handled independently.
o GIST identifies routing state (upstream and downstream peer) by
the triplet (MRI, NSLP, SID).
Schulzrinne & Hancock Expires August 31, 2007 [Page 16]
Internet-Draft GIST February 2007
Strictly, the routing state should not depend on the SID. However,
if the routing state is keyed only by (MRI, NSLP), there is a trivial
denial of service attack (see Section 8.3) where a malicious off-path
node asserts that it is the peer for a particular flow. Such an
attack would not redirect the traffic but would reroute the
signalling. Instead, the routing state is also segregated between
different SIDs, which means that the attacking node can only disrupt
a signalling session if it can guess the corresponding SID.
Normative rules on the selection of SIDs are given in Section 4.1.3.
3.8. Signalling Applications and NSLPIDs
The functionality for signalling applications is supported by NSIS
signalling layer protocols (NSLPs). Each NSLP is identified by a 16
bit NSLP identifier (NSLPID), assigned by IANA (Section 9). A single
signalling application, such as resource reservation, may define a
family of NSLPs to implement its functionality, for example to carry
out signalling operations at different levels in a hierarchy (cf.
[23]). However, the interactions between the different NSLPs (for
example, to relate aggregation levels or aggregation region
boundaries in the resource management case) are handled at the
signalling application level; the NSLPID is the only information
visible to GIST about the signalling application being used.
3.9. GIST Security Services
GIST has two distinct security goals:
o to protect GIST state from corruption, and to protect the nodes on
which it runs from resource exhaustion attacks; and
o to provide secure transport for NSLP messages to the signalling
applications.
The protocol mechanisms to achieve the first goal are mainly internal
to GIST. They include a cookie exchange and return routability check
to protect the handshake which sets up routing state, and a random
SID is also used to prevent off-path session hijacking by SID
guessing. Further details are given in Section 4.1.3 and
Section 4.4.1, and the overall security aspects are discussed in
Section 8.
A second level of protection is provided by the use of a channel
security protocol in messaging associations (i.e. within C-mode).
This mechanism serves two purposes: to protect against on-path
attacks on GIST, and to provide a secure channel for NSLP messages.
For the mechanism to be effective, it must be able to provide the
following functions:
Schulzrinne & Hancock Expires August 31, 2007 [Page 17]
Internet-Draft GIST February 2007
o mutual authentication of the GIST peer nodes;
o ability to verify the authenticated identity against a database of
nodes authorised to take part in GIST signalling;
o confidentiality and integrity protection for NSLP data, and
provision of the authenticated identities used to the signalling
application.
The authorised peer database is described in more detail in
Section 4.4.2, including the types of entries that it can contain and
the authorisation checking algorithm that is used. The only channel
security protocol defined by this specification is a basic use of
TLS, and Section 5.7.3 defines the TLS-specific aspects of how these
functions (for example, authentication and identity comparison) are
integrated with the rest of GIST operation. At a high level, there
are several alternative protocols with similar functionality, and the
handshake (Section 4.4.1) provides a mechanism within GIST to select
between them. However, they differ in their identity schemes and
authentication methods and dependencies on infrastructure support for
the authentication process, and any GIST extension to incorporate
them would need to define the details of the corresponding
interactions with GIST operation.
3.10. Example of Operation
This section presents an example of GIST usage in a relatively simple
(in particular, NAT-free) signalling scenario, to illustrate its main
features.
Consider the case of an RSVP-like signalling application which
allocates resources for a single unicast flow. In general,
signalling can take place along the entire end-to-end path (between
flow source and destination), but the role of GIST is only to
transfer signalling messages over a single segment of the path,
between neighbouring resource-capable nodes. Basic GIST operation is
the same, whether it involves the endpoints or only interior nodes:
in either case, GIST is triggered by a request from a local
signalling application. The example here describes how GIST
transfers messages between two adjacent peers along the path, GN1 and
GN2 (see Figure 1 in Section 2). We take up the story at the point
where a message is being processed above the GIST layer by the
signalling application in GN1.
1. The signalling application in GN1 determines that this message is
a simple description of resources that would be appropriate for
the flow. It determines that it has no special security or
transport requirements for the message, but simply that it should
Schulzrinne & Hancock Expires August 31, 2007 [Page 18]
Internet-Draft GIST February 2007
be transferred to the next downstream signalling application peer
on the path that the flow will take.
2. The message payload is passed to the GIST layer in GN1, along
with a definition of the flow and description of the message
transfer attributes (in this case, requesting no reliable
transmission or channel security protection). GIST determines
that this particular message does not require fragmentation and
that it has no knowledge of the next peer for this flow and
signalling application; however, it also determines that this
application is likely to require secured upstream and downstream
transport of large messages in the future. This determination is
a function of node-local policy interactions between GIST and the
signalling application.
3. GN1 therefore constructs a GIST Query carrying the NSLP payload,
and additional payloads at the GIST level which will be used to
initiate a messaging association. The Query is encapsulated in a
UDP datagram and injected into the network. At the IP level, the
destination address is the flow receiver, and an IP Router Alert
Option (RAO) is also included.
4. The Query passes through the network towards the flow receiver,
and is seen by each router in turn. GIST-unaware routers will
not recognise the RAO value and will forward the message
unchanged; GIST-aware routers which do not support the NSLP in
question will also forward the message basically unchanged,
although they may need to process more of the message to decide
this.
5. The message is intercepted at GN2. The GIST layer identifies the
message as relevant to a local signalling application, and passes
the NSLP payload and flow description upwards to it. This
signalling application in GN2 indicates to GIST that it will peer
with GN1 and so GIST should proceed to set up any routing state.
In addition, the signalling application continues to process the
message as in GN1 (compare step 1), passing the message back down
to GIST so that it is sent further downstream, and this will
eventually result in the message reaching the flow receiver.
GIST itself operates hop-by-hop, and the signalling application
joins these hops together to manage the end-to-end signalling
operations.
6. In parallel, the GIST instance in GN2 now knows that it should
maintain routing state and a messaging association for future
signalling with GN1. This is recognised because the message is a
Query, and because the local signalling application has indicated
that it will peer with GN1. There are two possible cases for
Schulzrinne & Hancock Expires August 31, 2007 [Page 19]
Internet-Draft GIST February 2007
sending back the necessary GIST Response:
6.A - Association Exists: GN1 and GN2 already have an
appropriate MA. GN2 simply records the identity of GN1 as its
upstream peer for that flow and NSLP, and sends a Response
back to GN1 over the MA identifying itself as the peer for
this flow.
6.B - No Association: GN2 sends the Response in D-mode directly
to GN1, identifying itself and agreeing to the association
setup. The protocol exchanges needed to complete this will
proceed in parallel with the following stages.
In each case, the result is that GN1 and GN2 are now in a peering
relationship for the flow.
7. Eventually, another NSLP message works its way upstream from the
receiver to GN2. This message contains a description of the
actual resources requested, along with authorisation and other
security information. The signalling application in GN2 passes
this payload to the GIST level, along with the flow definition
and transfer attributes; in this case, it could request reliable
transmission and use of a secure channel for integrity
protection. (Other combinations of attributes are possible).
8. The GIST layer in GN2 identifies the upstream peer for this flow
and NSLP as GN1, and determines that it has an MA with the
appropriate properties. The message is queued on the MA for
transmission; this may incur some delay if the procedures begun
in step 6.B have not yet completed.
Further messages can be passed in each direction in the same way.
The GIST layer in each node can in parallel carry out maintenance
operations such as route change detection (see Section 7.1).
It should be understood that several of these details of GIST
operations can be varied, either by local policy or according to
signalling application requirements. The authoritative details are
contained in the remainder of this document.
Schulzrinne & Hancock Expires August 31, 2007 [Page 20]
Internet-Draft GIST February 2007
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, and the application also
provides the session identifier (see Section 4.1.3). Additional
message transfer attributes control the specific transport and
security properties that the signalling application desires.
Schulzrinne & Hancock Expires August 31, 2007 [Page 21]
Internet-Draft GIST February 2007
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 to define certain performance
and security-related aspects of message processing. The attributes
available are as follows:
Reliability: This attribute may be 'true' or 'false'. When 'true',
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, 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 case.
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
Schulzrinne & Hancock Expires August 31, 2007 [Page 22]
Internet-Draft GIST February 2007
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 data being sent Q-mode encapsulated instead.
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 [33].
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
information about how the message is to be routed, the session being
signalled for, and the signalling application itself:
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.
Schulzrinne & Hancock Expires August 31, 2007 [Page 23]
Internet-Draft GIST February 2007
Session Identification (SID): The signalling session with which this
message should be associated; see Section 3.7.
NSLP Identification (NSLPID): This is an IANA-assigned identifier
associated with the NSLP which 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} triplet
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 send the message. For
example, it can send it in Q-mode and rely on the peer to
intercept it.
In addition, 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 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 is
described in more detail in Section 4.4.
Note also that the routing state is described as a table of per-flow
entries, but that there is no implied constraint on how the
information is stored. However, in general, and especially if GIST
peers are several IP hops away, there is no way to identify the
correct downstream peer for a flow and signalling application from
the local forwarding table using prefix matching, and the same
applies always to upstream peer state because of the possibility of
asymmetric IP routing: prefix aggregation is not possible, and per-
Schulzrinne & Hancock Expires August 31, 2007 [Page 24]
Internet-Draft GIST February 2007
flow state has to be stored, just as for RSVP [16].
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 messages pending transmission while an MA is being
established;
o a timer for how long since the peer re-stated its desire to keep
the MA open (see Section 4.4.5).
In addition, per-MA state 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. Firstly, message reception, local processing and
message transmission are described for the case where the node hosts
the NSLPID identified in the message. Secondly, 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 3. 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.
Schulzrinne & Hancock Expires August 31, 2007 [Page 25]
Internet-Draft GIST February 2007
+---------------------------------------------------------+
| >> Signalling Application Processing >> |
| |
+--------^---------------------------------------V--------+
^ V
^ NSLP Payloads V
^ 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 | | RAO | alert) level | RAO | |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 which are Q-mode encapsulated
xxxxxxxxxxxxxx = C-mode messages
RAO = Router Alert Option
Figure 3: Message Paths through a GIST Node
4.3.1. Message Reception
Messages can be received in C-mode or D-mode.
Reception in C-mode is simple: incoming packets undergo the security
and transport treatment associated with the MA, and the MA provides
complete messages to the GIST layer for further processing.
Schulzrinne & Hancock Expires August 31, 2007 [Page 26]
Internet-Draft GIST February 2007
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 signalling 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, the 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 [15]. 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), following which the
GIST hop count MUST be decremented by one.
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.
Schulzrinne & Hancock Expires August 31, 2007 [Page 27]
Internet-Draft GIST February 2007
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, or if the GIST hop count has reached zero.
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 which 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 MUST NOT modify it except in the NSLP payload; in
particular, it MUST NOT modify any 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:
Schulzrinne & Hancock Expires August 31, 2007 [Page 28]
Internet-Draft GIST February 2007
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 which 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 the
message MUST either be dropped or be rejected with a 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, 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.
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 which 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:
Schulzrinne & Hancock Expires August 31, 2007 [Page 29]
Internet-Draft GIST February 2007
o message transfer attributes: for example, the signalling
application has requested 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. If the Path MTU to the next peer is
known, the message size MUST NOT exceed that Path MTU; if the Path
MTU is not known, the message size MUST NOT exceed 576 bytes. The
same limit applies to IPv4 and IPv6.
o local policy: for example, a node MAY send messages over a
messaging association solely to benefit from adaptive congestion
control.
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 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 required, the message is sent in
D-mode. The processing in this case depends on the message type and
whether routing state exists or not.
o If the message is not a Query, 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, then it is sent in Q-mode as defined in
(Section 5.3.2); the details depend on the message routing method.
Schulzrinne & Hancock Expires August 31, 2007 [Page 30]
Internet-Draft GIST February 2007
o If no routing state exists, GIST can attempt to use Q-mode as in
the Query case. 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 which 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 which 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.
2. A Q-mode encapsulated message contains an RAO value which is
relevant to NSIS but not to the specific node, but the IP layer
is unable to recognise 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 which is
relevant to the node, but the specific signalling application for
the NSLPID in the message is not processed there.
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 which
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 GIST-aware NAT. See Section 7.2.
In cases (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
Schulzrinne & Hancock Expires August 31, 2007 [Page 31]
Internet-Draft GIST February 2007
hop count are managed correctly to prevent message looping, and this
should be done consistently independently of whether the processing
takes place on the fast path or in GIST-specific code. 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 512 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 which 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 which 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
Schulzrinne & Hancock Expires August 31, 2007 [Page 32]
Internet-Draft GIST February 2007
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. State Setup
The complete sequence of possible messages for GIST state setup
between adjacent peers is shown in Figure 4 and described in detail
in the following text. The figure informally summarises the contents
of each message, including optional elements in square brackets. An
example is given in Appendix D.
The initial 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 it 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 subsequent messages is to protect against certain denial of
service attacks and to correlate the various events in the message
sequence (see Section 8.5 for further details).
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 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).
Schulzrinne & Hancock Expires August 31, 2007 [Page 33]
Internet-Draft GIST February 2007
+----------+ +----------+
| 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 (1) .
[NSLP Payload] .............
......................................
. 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
----------------------> .............
MRI/SID/NSLPID . Routing .
Q-N Network Layer Info . state .
[Responder Cookie . installed .
[R-N Stack-Proposal . at .
[Q-N Stack-Config-Data]]] . Responding.
[NSLP Payload] . node (2) .
.............
Figure 4: Message Sequence at State Setup
Schulzrinne & Hancock Expires August 31, 2007 [Page 34]
Internet-Draft GIST February 2007
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 flow), 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 an abbreviated form of the original
Stack-Configuration-Data to finalise details of the messaging
association configuration. 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:
Schulzrinne & Hancock Expires August 31, 2007 [Page 35]
Internet-Draft GIST February 2007
1. after the receipt of the initial Query, or
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 a abstract
construct, similar to the security policy database of IPsec [39].
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
Schulzrinne & Hancock Expires August 31, 2007 [Page 36]
Internet-Draft GIST February 2007
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 lie; 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).
Schulzrinne & Hancock Expires August 31, 2007 [Page 37]
Internet-Draft GIST February 2007
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,
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
which matches the same routing state and desired properties that
would be the result of a full handshake in D-mode, and this
identification must be done as reliably and securely as continuing
with the full procedure. 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:
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
Schulzrinne & Hancock Expires August 31, 2007 [Page 38]
Internet-Draft GIST February 2007
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 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 the NLI of 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 done 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 full 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
Schulzrinne & Hancock Expires August 31, 2007 [Page 39]
Internet-Draft GIST February 2007
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. The full NLI object matches: 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 which is
negotiated during the Query/Response/Confirm handshake. The Network
Layer Info (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 which 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 twice the number
of items divided by the rate limit in messages per 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 which take at
least the following into account:
Schulzrinne & Hancock Expires August 31, 2007 [Page 40]
Internet-Draft GIST February 2007
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.
[41]).
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 which might generate messages to
use it.
o whether the peer still wants the MA in place. During MA setup,
each node indicates its own MA-Hold-Time as part of the Stack-
Configuration-Data. A node MUST NOT tear down the MA if it has
received traffic from its peer over that period. A peer which has
generated no traffic but still wants the MA retained may 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 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
Schulzrinne & Hancock Expires August 31, 2007 [Page 41]
Internet-Draft GIST February 2007
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 expires; it does not define when keepalives should be
initiated. Implementations MUST select timer settings which 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.
[41]).
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, which 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 has never been correctly installed in the
first place, but the sending node does not know this. This can
Schulzrinne & Hancock Expires August 31, 2007 [Page 42]
Internet-Draft GIST February 2007
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
which would not otherwise be retransmitted). Note that only
Response, Confirm, Error and Data messages ever require routing state
to exist, and these are considered in turn:
Response: A Response can be received at a node which 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 which 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 which 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.
Schulzrinne & Hancock Expires August 31, 2007 [Page 43]
Internet-Draft GIST February 2007
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. [45]), 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.
Schulzrinne & Hancock Expires August 31, 2007 [Page 44]
Internet-Draft GIST February 2007
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
[13]; a more detailed description of the header and each object is
given in Section 5.2. 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 one of the stages in
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).
Query: A Query MUST be sent in D-mode, in fact with 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. 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-Identification
Network-Layer-Information
Query-Cookie
[ Stack-Proposal Stack-Configuration-Data ]
[ NSLP-Data ]
Response: A Response MAY be sent in D-mode, or MAY be sent in C-mode
if an existing messaging association is being re-used. It MUST echo
the MRI SID and Query-Cookie of the Query, and carries its own
Schulzrinne & Hancock Expires August 31, 2007 [Page 45]
Internet-Draft GIST February 2007
Network-Layer-Information. If the message exchange relates to setup
of a new messaging association, which MUST be carried out in D-mode,
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. 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-Identification
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 no messaging association is
being use, the Confirm MUST be sent in D-mode. The Confirm MUST echo
the MRI (with inverted direction), SID, and Responder-Cookie if the
Response carried one. In C-mode, the Confirm MUST also echo the
Stack-Proposal from the Response 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-Identification
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.
Schulzrinne & Hancock Expires August 31, 2007 [Page 46]
Internet-Draft GIST February 2007
Data = Common-Header
[ NAT-Traversal-Object ]
Message-Routing-Information
Session-Identification
[ 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.) The
message includes a Network-Layer-Information object for the
originator of the error message if it is being sent in D-mode; 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 null 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; if 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.
Schulzrinne & Hancock Expires August 31, 2007 [Page 47]
Internet-Draft GIST February 2007
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 that
this message is used for.
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 which 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 which if set (E=1) indicates that the
message was explicitly routed (see Section 7.1.5).
Note that in Q-mode Section 5.3.2, 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
Schulzrinne & Hancock Expires August 31, 2007 [Page 48]
Internet-Draft GIST February 2007
provided by the NSLP in the message sender and used by GIST to
select the message routing.
Session-Identification (SID): The GIST session identifier is a 128
bit, cryptographically random identifier chosen by the node which
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 the 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
multi-homed 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.
Schulzrinne & Hancock Expires August 31, 2007 [Page 49]
Internet-Draft GIST February 2007
* 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 = 1*protocol-layer
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 a
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.
Schulzrinne & Hancock Expires August 31, 2007 [Page 50]
Internet-Draft GIST February 2007
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 all 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-Identification (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
Schulzrinne & Hancock Expires August 31, 2007 [Page 51]
Internet-Draft GIST February 2007
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 complete set of GIST payloads is
concatenated together with the common header, and placed in the data
field of a UDP datagram. UDP checksums MUST be enabled. 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. Normally encapsulated messages MUST be sent with
source addressing mode flag S=1 unless the message is a reply to a
message which 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 encapsulation is similar to
normal encapsulation, with changes in IP address selection, IP
options, a defined method for selecting UDP ports, and a magic number
at the start of the UDP payload.
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 with 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 [3] to assist
the peer in intercepting the message depending on the NSLPID. If the
Schulzrinne & Hancock Expires August 31, 2007 [Page 52]
Internet-Draft GIST February 2007
MRM defines the use of RAO, the sender MUST include it by default.
However, a node MAY make the initial interception decision based
purely on IP-Protocol number transport header analysis (see below).
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 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 which do not properly support RAO; further details are
discussed in Appendix C.
It is possible that fragmented datagrams including an RAO will not be
correctly handled in the network; furthermore, some of 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 all MRMs require S=1 for at least some
retransmissions, so 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 the hop-by-hop option header, the IP
header MUST NOT include any extension headers other than routing
options or destination options, and for the last extension header
MUST have a next-header field of UDP.
Schulzrinne & Hancock Expires August 31, 2007 [Page 53]
Internet-Draft GIST February 2007
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 which 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.
Within the network, there may be packets using the GIST UDP port but
which are not in fact GIST traffic. To avoid misidentification of
such packets, the UDP payload in Q-mode messages MUST always begin
with a 32 bit magic number which is followed immediately by the
normal GIST common header; the value of the magic number is 0x4e04
bda5 in network byte order.
Packets which do not match both the UDP destination port and the
magic number MUST be forwarded transparently at the IP layer,
regardless of any RAO value they contain. Regardless of the IP level
encapsulation, if either the destination port is not the GIST port,
or the payload start does not match the magic number, the packet MUST
NOT be identified as a GIST Q-mode packet and MUST be processed as a
normal IP datagram.
Schulzrinne & Hancock Expires August 31, 2007 [Page 54]
Internet-Draft GIST February 2007
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 options semantics are
independent of the payload: UDP payload modifications are not
prevented by the options and do not affect the options 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 on 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 which 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. Elements 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
Schulzrinne & Hancock Expires August 31, 2007 [Page 55]
Internet-Draft GIST February 2007
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.
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 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) which 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 which are being forwarded.
When the rate limiter is in effect, D-mode messages MUST be queued
until transmission is re-enabled, or an error condition MAY be
indicated back to local signalling applications. The rate limiting
mechanism is implementation-defined, but it is RECOMMENDED that a
token bucket limiter as described in [35] 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, such as 5%, of the node's lowest-speed interface.
5.4. C-mode Transport
It is a requirement of the NTLP defined in [31] 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 can either be done within the transport protocol or
Schulzrinne & Hancock Expires August 31, 2007 [Page 56]
Internet-Draft GIST February 2007
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 possible combinations of message type and
encapsulation 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 arrives with an invalid encapsulation
(e.g. a Query arrives over a messaging association), 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 that the decapsulation process
may provide additional information, such as translated addresses or
IP hop count to be used in the subsequent message processing.
Schulzrinne & Hancock Expires August 31, 2007 [Page 57]
Internet-Draft GIST February 2007
+----------+-----------------+---------------------+----------------+
| Message | Normal D-mode | Query D-mode | C-mode |
| | | (Q-mode) | |
+----------+-----------------+---------------------+----------------+
| Query | Never | Always | Never |
| | | | |
| Response | Unless a | Never | If a messaging |
| | messaging | | association is |
| | association is | | being re-used |
| | being re-used | | |
| | | | |
| Confirm | Only if no | Never | If a messaging |
| | messaging | | association |
| | association has | | has been set |
| | been set up or | | up or is being |
| | is being | | re-used |
| | re-used | | |
| | | | |
| Data | If routing | If no routing state | If a messaging |
| | state exists | exists and the MRI | association |
| | for the flow | can be used to | exists |
| | but no | derive the Q-mode | |
| | messaging | encapsulation | |
| | association | | |
+----------+-----------------+---------------------+----------------+
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 is
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.
Schulzrinne & Hancock Expires August 31, 2007 [Page 58]
Internet-Draft GIST February 2007
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, an error SHOULD be logged
locally.
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 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 which 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 Stack-Configuration-Data object.
The format may differ depending on whether the field is present in
Schulzrinne & Hancock Expires August 31, 2007 [Page 59]
Internet-Draft GIST February 2007
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 a Stack-Configuration-Data object which carries an MA-
protocol-options field for any protocol listed in the Stack-Proposal
which 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
be used to carry different port numbers for TCP depending on whether
it is to be used with or without TLS. An MA-protocol-options field
may also be flagged as not usable; for example, a NAT which 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 Stack-Configuration-Data 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 a Stack-Configuration-Data 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 association setup always contains a Stack-Proposal
and Stack-Configuration-Data object. The Stack-Proposal MUST only
include protocol configurations that are suitable for the transfer
attributes of the messages that the Querying node wishes use the
messaging association for. 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 Stack-
Schulzrinne & Hancock Expires August 31, 2007 [Page 60]
Internet-Draft GIST February 2007
Configuration-Data 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 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. If a difference is detected, the
responding node MUST terminate the messaging association and SHOULD
log an error condition locally. 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 information apart from the field header.
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.
Schulzrinne & Hancock Expires August 31, 2007 [Page 61]
Internet-Draft GIST February 2007
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 [10] and MUST
use the highest protocol version supported by both peers.
Implementation of TLS1.1 [14] 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 [34]. 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 APD entry in turn, as discussed in Section 4.4.2.
This section defines the identity comparison algorithm for a single
Schulzrinne & Hancock Expires August 31, 2007 [Page 62]
Internet-Draft GIST February 2007
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 [11] 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 various possible MRMs.
5.8.1. The Path-Coupled MRM
5.8.1.1. Message Routing Information
For the path-coupled MRM, this is conceptually the Flow Identifier as
in the NSIS Framework [31]. 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).
Schulzrinne & Hancock Expires August 31, 2007 [Page 63]
Internet-Draft GIST February 2007
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/128
(for IPv4/6) MAY be used to implement address wildcarding, allowing
the MRI to refer to traffic to or from a wider address range.
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 which 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
Schulzrinne & Hancock Expires August 31, 2007 [Page 64]
Internet-Draft GIST February 2007
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 should match 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 un-cooperative 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.
Schulzrinne & Hancock Expires August 31, 2007 [Page 65]
Internet-Draft GIST February 2007
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 1 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. 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
Schulzrinne & Hancock Expires August 31, 2007 [Page 66]
Internet-Draft GIST February 2007
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 which have reached a node at which
they can no longer be trusted. In particular, a node SHOULD reject a
message which 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 [29].
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 [36].
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 which 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, again
from the MRI (S=0). However, the use of the signalling source
Schulzrinne & Hancock Expires August 31, 2007 [Page 67]
Internet-Draft GIST February 2007
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.
Schulzrinne & Hancock Expires August 31, 2007 [Page 68]
Internet-Draft GIST February 2007
6. Formal Protocol Specification
This section provides a more formal specification of the operation of
GIST processing, in terms of rules for transitions between states of
a set of communicating state machines within a node. The following
description captures only the basic protocol specification;
additional mechanisms can be used by an implementation to accelerate
route change processing, and these are captured in Section 7.1. A
more detailed description of the GIST protocol operation in state
machine syntax can be found in [44].
Conceptually, GIST processing at a node may be seen in terms of four
types of cooperating state machine:
1. There is a top-level state machine which represents the node
itself (Node-SM). It is responsible for the processing of events
which cannot be directed towards a more specific state machine,
for example, inbound messages for which no routing state
currently exists. This machine exists permanently, and is
responsible for creating per-MRI state machines to manage the
GIST handshake and routing state maintenance procedures.
2. For each flow and signalling direction where the node is
responsible for the creation of routing state, there is an
instance of a Query-Node state machine (Querying-SM). This
machine sends Query and Confirm messages and waits for Responses,
according to the requirements from local API commands or timer
processing, such as message repetition or routing state refresh.
3. For each flow and signalling direction where the node has
accepted the creation of routing state by a peer, there is an
instance of a Responding-Node state machine (Responding-SM).
This machine is responsible for managing the status of the
routing state for that flow. Depending on policy, it MAY be
responsible for [re]transmission of Response messages, or this
MAY be handled by the Node-SM, and a Responding-SM is not even
created for a flow until a properly formatted Confirm has been
accepted.
4. Messaging associations have their own lifecycle, represented by
MA-SM, from when they are first created (in an incomplete state,
listening for an inbound connection or waiting for outbound
connections to complete), to when they are active and available
for use.
Apart from the fact that the various machines can be created and
destroyed by each other, there is almost no interaction between them.
The machines for different flows do not interact; the Querying-SM and
Schulzrinne & Hancock Expires August 31, 2007 [Page 69]
Internet-Draft GIST February 2007
Responding-SM for a single flow and signalling direction do not
interact. That is, the Responding-SM which accepts the creation of
routing state for a flow on one interface has no direct interaction
with the Querying-SM which sets up routing state on the next
interface along the path. This interaction is mediated instead
through the NSLP.
The state machine descriptions use the terminology rx_MMMM, tg_TTTT
and er_EEEE for incoming messages, API/lower layer triggers and error
conditions respectively. The possible events of these types are
given in the table below. In addition, timeout events denoted
to_TTTT may also occur; the various timers are listed independently
for each type of state machine in the following subsections.
+---------------------+---------------------------------------------+
| Name | Meaning |
+---------------------+---------------------------------------------+
| rx_Query | A Query has been received. |
| | |
| rx_Response | A Response has been received. |
| | |
| rx_Confirm | A Confirm has been received. |
| | |
| rx_Data | A Data message has been received. |
| | |
| rx_Message | rx_Query||rx_Response||rx_Confirm||rx_Data. |
| | |
| rx_MA-Hello | A MA-Hello message has been received. |
| | |
| tg_NSLPData | A signalling application has requested data |
| | transfer (via API SendMessage). |
| | |
| tg_Connected | The protocol stack for a messaging |
| | association has completed connecting. |
| | |
| tg_RawData | GIST wishes to transfer data over a |
| | particular messaging association. |
| | |
| tg_MAIdle | GIST decides that it is no longer necessary |
| | to keep an MA open for itself. |
| | |
| er_NoRSM | A "No Routing State" error was received. |
| | |
| er_MAConnect | A messaging association protocol failed to |
| | complete a connection. |
| | |
| er_MAFailure | A messaging association failed. |
+---------------------+---------------------------------------------+
Schulzrinne & Hancock Expires August 31, 2007 [Page 70]
Internet-Draft GIST February 2007
Incoming Events
6.1. Node Processing
The Node level state machine is responsible for processing events for
which no more appropriate messaging association state or routing
state exists. Its structure is trivial: there is a single state
('Idle'); all events cause a transition back to Idle. Some events
cause the creation of other state machines. The only events that are
processed by this state machine are incoming GIST messages (Query/
Response/Confirm/Data) and API requests to send data; no other events
are possible. In addition to this event processing, the Node level
machine is responsible for managing listening endpoints for messaging
associations. Although these relate to Responding node operation,
they cannot be handled by the Responder state machine since they are
not created per flow. The processing rules for each event are as
follows:
Rule 1 (rx_Query):
use the GIST service interface to determine the signalling
application policy relating to this peer
// note that this interaction delivers any NSLP-Data to
// the NSLP as a side effect
if (the signalling application indicates that routing state should
be created) then
if (routing state can be created without a 3-way handshake) then
create Responding-SM and transfer control to it
else
send Response with R=1
else
propagate the Query with any updated NSLP payload provided
Rule 2 (rx_Response):
// a routing state error
discard message
Rule 3 (rx_Confirm):
if (routing state can be created before receiving a Confirm) then
// we should already have Responding-SM for it,
// which would handle this message
discard message
send "No Routing State" error message
else
create Responding-SM and pass message to it
Schulzrinne & Hancock Expires August 31, 2007 [Page 71]
Internet-Draft GIST February 2007
Rule 4 (rx_Data):
if (node policy will only process Data messages with matching
routing state) then
send "No Routing State" error message
else
pass directly to NSLP
Rule 4 (er_NoRSM):
discard the message
Rle 5 (tg_NSLPData):
if Q-mode encapsulation is not possible for this MRI
reject message with an error
else
if (local policy & transfer attributes say routing
state is not needed) then
send message statelessly
else
create Querying-SM and pass message to it
6.2. Query Node Processing
The Querying-Node state machine (Querying-SM) has three states:
o Awaiting Response
o Established
o Awaiting Refresh
The Querying-SM is created by the Node-SM machine as a result of a
request to send a message for a flow in a signalling direction where
the appropriate state does not exist. The Query is generated
immediately and the No_Response timer is started. The NSLP data MAY
be carried in the Query if local policy and the transfer attributes
allow it, otherwise it MUST be queued locally pending MA
establishment. Then the machine transitions to the Awaiting Response
state, in which timeout-based retransmissions are handled. Data
messages (rx_Data events) should not occur in this state; if they do,
this may indicate a lost Response and a node MAY also retransmit a
Query for this reason.
Once a Response has been successfully received and routing state
created, the machine transitions to Established, during which NSLP
data can be sent and received normally. Further Responses received
in this state (which may be the result of a lost Confirm) MUST be
treated the same way. The Awaiting Refresh state can be considered
as a substate of Established, where a new Query has been generated to
Schulzrinne & Hancock Expires August 31, 2007 [Page 72]
Internet-Draft GIST February 2007
refresh the routing state (as in Awaiting Response) but NSLP data can
be handled normally.
The timers relevant to this state machine are as follows:
Refresh_QNode: Indicates when the routing state stored by this state
machine must be refreshed. It is reset whenever a Response is
received indicating that the routing state is still valid.
Implementations MUST set the period of this timer based on the
value in the RS-validity-time field of a Response to ensure that a
Query is generated before the peer's routing state expires.
No_Response: Indicates that a Response has not been received in
answer to a Query. This is started whenever a Query is sent and
stopped when a Response is received.
Inactive_QNode: Indicates that no traffic is currently being handled
by this state machine. This is reset whenever the state machine
handles NSLP data, in either direction. When it expires, the
state machine MAY be deleted. The period of the timer can be set
at any time via the API (SetStateLifetime), and if the period is
reset in this way the timer itself MUST be restarted.
The main events (including all those that cause state transitions)
are shown in the figure below, tagged with the number of the
processing rule that is used to handle the event. These rules are
listed after the diagram. All events not shown or described in the
text above are assumed to be impossible in a correct implementation
and MUST be ignored.
Schulzrinne & Hancock Expires August 31, 2007 [Page 73]
Internet-Draft GIST February 2007
[Initialisation] +-----+
-------------------------|Birth|
| +-----+
| er_NoRSM[3](from all states) rx_Response[4]
| || tg_NSLPData[5]
| tg_NSLPData[1] || rx_Data[7]
| -------- -------
| | V | V
| | V | V
| +----------+ +-----------+
---->>| Awaiting | |Established|
------| Response |---------------------------->> | |
| +----------+ rx_Response[4] +-----------+
| ^ | ^ |
| ^ | ^ |
| -------- | |
| to_No_Response[2] | |
| [!nResp_reached] tg_NSLPData[5] | |
| || rx_Data[7] | |
| -------- | |
| | V | |
| to_No_Response[2] | V | |
| [nResp_reached] +-----------+ rx_Response[4] | |
---------- -----------| Awaiting |----------------- |
| | | Refresh |<<-------------------
| | +-----------+ to_Refresh_QNode[8]
| | ^ |
V V ^ | to_No_Response[2]
V V -------- [!nResp_reached]
+-----+
|Death|<<---------------
+-----+ to_Inactive_QNode[6]
(from all states)
Figure 5: Query Node State Machine
The processing rules are as follows:
Rule 1: Store the message for later transmission
Rule 2:
if number of Queries sent has reached the threshold
// nQuery_isMax is true
indicate No Response error to NSLP
destroy self
else
send Query
start No_Response timer with new value
Schulzrinne & Hancock Expires August 31, 2007 [Page 74]
Internet-Draft GIST February 2007
Rule 3:
// Assume the Confirm was lost in transit or the peer has reset;
// restart the handshake
send Query
start No_Response timer
Rule 4:
if a new MA-SM is needed create one
if the R flag was set send a Confirm
pass any NSLP-Data object to the NSLP
send any stored Data messages
stop No_Response timer
start Refresh_QNode and (re)start Inactive_QNode timers
Rule 5:
send Data message
restart Inactive_QNode timer
Rule 6: Terminate
Rule 7:
pass any data to the NSLP
restart Inactive_QNode timer
Rule 8:
send Query
start No_Response timer
stop Refresh_QNode timer
6.3. Responder Node Processing
The Responding-Node state machine (Responding-SM) has three states:
o Awaiting Confirm
o Established
o Awaiting Refresh
The policy governing the handling of Query messages and the creation
of the Responding-SM has three cases:
1. No Confirm is required for a Query, and the state machine can be
created immediately.
2. A Confirm is required for a Query, but the state machine can
still be created immediately. A timer is used to retransmit
Response messages and the Responding-SM is destroyed if no valid
Schulzrinne & Hancock Expires August 31, 2007 [Page 75]
Internet-Draft GIST February 2007
Confirm is received.
3. A Confirm is required for a Query, and the state machine can only
be created when it is received; the initial Query will have been
handled by the Node level machine.
In case 2 the Responding-SM is created in the Awaiting Confirm state,
and remains there until a Confirm is received, at which point it
transitions to Established. In cases 1 and 3 the Responding-SM is
created directly in the Established state. Note that if the machine
is created on receiving a Query, some of the message processing will
already have been performed in the Node state machine. In principle,
an implementation MAY change its policy on handling a Query message
at any time; however, the state machine descriptions here cover only
the case where the policy is fixed while waiting for a Confirm
message.
In the Established state the NSLP can send and receive data normally,
and any additional rx_Confirm events MUST be silently ignored. The
Awaiting Refresh state can be considered a substate of Established,
where a Query has been received to begin the routing state refresh.
In the Awaiting Refresh state the Responding-SM behaves as in the
Awaiting Confirm state, except that the NSLP can still send and
receive data. In particular, in both states there is timer-based
retransmission of Response messages until a Confirm is received;
additional rx_Query events in these states MUST also generate a reply
and restart the no_Confirm timer.
The timers relevant to the operation of this state machine are as
follows:
Expire_RNode: Indicates when the routing state stored by this state
machine needs to be expired. It is reset whenever a Query or
Confirm (depending on local policy) is received indicating that
the routing state is still valid. Note that state cannot be
refreshed from the R-Node.
No_Confirm: Indicates that a Confirm has not been received in answer
to a Response. This is started/reset whenever a Response is sent
and stopped when a Confirm is received.
The detailed state transitions and processing rules are described
below as in the Query node case.
Schulzrinne & Hancock Expires August 31, 2007 [Page 76]
Internet-Draft GIST February 2007
rx_Query[1] rx_Query[5]
[confirmRequired] +-----+ [!confirmRequired]
-------------------------|Birth|----------------------------
| +-----+ |
| | rx_Confirm[2] |
| ---------------------------- |
| | |
| rx_Query[5] | |
| tg_NSLPData[7] || rx_Confirm[10] | |
| || rx_Query[1] || rx_Data[4] | |
| || rx_Data[6] || tg_NSLPData[3] | |
| -------- -------------- | |
| | V | V V V
| | V | V V V
| +----------+ | +-----------+
---->>| Awaiting | rx_Confirm[8] -----------|Established|
------| Confirm |------------------------------>> | |
| +----------+ +-----------+
| ^ | ^ |
| ^ | tg_NSLPData[3] ^ |
| -------- || rx_Query[1] | |
| to_No_Confirm[9] || rx_Data[4] | |
| [!nConf_reached] -------- | |
| | V | |
| to_No_Confirm[9] | V | |
| [nConf_reached] +-----------+ rx_Confirm[8] | |
---------- ------------| Awaiting |----------------- |
| | | Refresh |<<-------------------
| | +-----------+ rx_Query[1]
| | ^ | [confirmRequired]
| | ^ |
| | --------
V V to_No_Confirm[9]
V V [!nConf_reached]
+-----+
|Death|<<---------------------
+-----+ er_NoRSM[11]
to_Expire_RNode[11]
(from Established/Awaiting Refresh)
Figure 6: Responder Node State Machine
The processing rules are as follows:
Rule 1:
// a Confirm is required
send Response with R=1
(re)start No_Confirm timer
Schulzrinne & Hancock Expires August 31, 2007 [Page 77]
Internet-Draft GIST February 2007
Rule 2:
pass any NSLP-Data object to the NSLP
start Expire_RNode timer
Rule 3: send the Data message
Rule 4: pass data to NSLP
Rule 5:
// no Confirm is required
send Response with R=0
start Expire_RNode timer
Rule 6: send "No Routing State" error message
Rule 7: store Data message
Rule 8:
pass any NSLP-Data object to the NSLP
send any stored Data messages
stop No_Confirm timer
start Expire_RNode timer
Rule 9:
if number of Responses sent has reached threshold
// nResp_isMax is true
destroy self
else
send Response
start No_Response timer
Rule 10:
// can happen e.g. a retransmitted Response causes a duplicate Confirm
silently ignore
Rule 11: destroy self
6.4. Messaging Association Processing
Messaging associations (MAs) are modelled for use within GIST with a
simple three-state process. The Awaiting Connection state indicates
that the MA is waiting for the connection process(es) for every
protocol in the messaging association to complete; this might involve
creating listening endpoints or attempting active connects. Timers
may also be necessary to detect connection failure (e.g. no incoming
connection within a certain period), but these are not modelled
explicitly.
Schulzrinne & Hancock Expires August 31, 2007 [Page 78]
Internet-Draft GIST February 2007
The Connected state indicates that the MA is open and ready to use,
and that the node wishes it to remain open. In this state, the node
operates a timer (SendHello) to ensure that messages are regularly
sent to the peer, to ensure that the peer does not tear the MA down.
The node transitions from Connected to Idle (indicating that it no
longer needs the association) as a matter of local policy; one way to
manage the policy is to use an activity timer but this is not
specified explicitly by the state machine (see also Section 4.4.5).
In the Idle state, the node no longer requires the messaging
association but the peer still requires it and is indicating this by
sending periodic MA-Hello messages. A different timer (NoHello)
operates to purge the MA when these messages stop arriving. If real
data is transferred over the MA, the state machine transitions back
to Connected.
At any time in the Connected or Idle states, a node MAY test the
connectivity to its peer and the liveness of the GIST instance at
that peer by sending a MA-Hello request with R=1. Failure to receive
a reply with a matching Hello-ID within a timeout MAY be taken as a
reason to trigger er_MAFailure. Initiation of such a test and the
timeout setting are left to the discretion of the implementaion.
Note that er_MAFailure may also be signalled by indications from the
underlying messaging association protocols. If a messaging
association fails, this MUST be indicated back to the routing state
machines which use it, and these MAY generate indications to
signalling applications. In particular, if the messaging association
was being used to deliver messages reliably, this MUST be reported as
a NetworkNotification error (Appendix B.4).
Clearly, many internal details of the messaging association protocols
are hidden in this model, especially where the messaging association
uses multiple protocol layers. Note also that although the existence
of messaging associations is not directly visible to signalling
applications, there is some interaction between the two because
security-related information becomes available during the open
process, and this may be indicated to signalling applications if they
have requested it.
The timers relevant to the operation of this state machine are as
follows:
SendHello: Indicates that an MA-Hello message should be sent to the
remote node. The period of this timer is determined by the MA-
Hold-Time sent by the remote node during the Query/Response/
Confirm exchange.
Schulzrinne & Hancock Expires August 31, 2007 [Page 79]
Internet-Draft GIST February 2007
NoHello: Indicates that no MA-Hello has been received from the
remote node for a period of time. The period of this timer is
sent to the remote node as the MA-Hold-Time during the Query/
Response exchange.
The detailed state transitions and processing rules are described
below as in the Query node case.
[Initialisation] +-----+
----------------------------|Birth|
| +-----+ tg_RawData[1]
| || rx_Message[2]
| || rx_MA-Hello[3]
| tg_RawData[5] || to_SendHello[4]
| -------- --------
| | V | V
| | V | V
| +----------+ +-----------+
---->>| Awaiting | tg_Connected[6] | Connected |
------|Connection|----------------------->>| |
| +----------+ +-----------+
| ^ |
| tg_RawData[1] ^ |
| || rx_Message[2] | | tg_MAIdle[7]
| | V
| | V
| er_MAConnect[8] +-----+ to_NoHello[8] +-----------+
---------------->>|Death|<<----------------| Idle |
+-----+ +-----------+
^ ^ |
^ ^ |
--------------- --------
er_MAFailure[8] rx_MA-Hello[9]
(from Connected/Idle)
Figure 7: Messaging Association State Machine
The processing rules are as follows:
Rule 1:
pass message to transport layer
if the NoHello timer was running, stop it
(re)start SendHello
Rule 2:
pass message to Node-SM
if the NoHello timer was running, stop it
Schulzrinne & Hancock Expires August 31, 2007 [Page 80]
Internet-Draft GIST February 2007
Rule 3:
if reply requested
send MA-Hello
restart SendHello timer
Rule 4:
send MA-Hello message
restart SendHello timer
Rule 5: queue message for later transmission
Rule 6:
pass outstanding queued messages to transport layer
stop any timers controlling connection establishment
start SendHello timer
Rule 7:
stop SendHello timer
start NoHello timer
Rule 8:
report failure to routing state machines and signalling applications
destroy self
Rule 9:
if reply requested
send MA-Hello
restart NoHello timer
Schulzrinne & Hancock Expires August 31, 2007 [Page 81]
Internet-Draft GIST February 2007
7. Additional Protocol Features
7.1. Route Changes and Local Repair
7.1.1. Introduction
When IP layer re-routing takes place in the network, GIST and
signalling application state need to be updated for all flows whose
paths have changed. The updates to signalling application state
depend mainly on the signalling application: for example, if the path
characteristics have actually changed, simply moving state from the
old to the new path is not sufficient. Therefore, GIST cannot carry
out the complete path update processing. Its responsibilities are to
detect the route change, update its local routing state consistently,
and inform interested signalling applications at affected nodes.
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
x +--+ +--+ +--+ x Initial
x .|C1|_.....|D1|_.....|E1| x Configuration
x . +--+. .+--+. .+--+\. x
>>xxxxxxxxxxxxx . . . . . . xxxxxx>>
+-+ +-+ . .. .. . +-+
...|A|_......|B|/ .. .. .|F|_....
+-+ +-+ . . . . . . +-+
. . . . . .
. +--+ +--+ +--+ .
.|C2|_.....|D2|_.....|E2|/
+--+ +--+ +--+
+--+ +--+ +--+ Configuration
.|C1|......|D1|......|E1| after failure
. +--+ .+--+ +--+ of E1-F link
. \. . \. ./
+-+ +-+ . .. .. +-+
...|A|_......|B|. .. .. .|F|_....
+-+ +-+\ . . . . . +-+
>>xxxxxxxxxxxxx . . . . . . xxxxxx>>
x . +--+ +--+ +--+ . x
x .|C2|_.....|D2|_.....|E2|/ x
x +--+ +--+ +--+ x
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
........... = physical link topology
>>xxxxxxx>> = flow direction
_.......... = outgoing link for flow xxxxxx given
by local forwarding table
Figure 8: A Re-Routing Event
Schulzrinne & Hancock Expires August 31, 2007 [Page 82]
Internet-Draft GIST February 2007
Route change management is complicated by the distributed nature of
the problem. Consider the re-routing event shown in Figure 8. An
external observer can tell that the main responsibility for
controlling the updates will probably lie with nodes B and F;
however, E1 is best placed to detect the event quickly at the GIST
level, and C1 and D1 could also attempt to initiate the repair.
The NSIS framework [31] makes the assumption that signalling
applications are soft-state based and operate end to end. In this
case, because GIST also periodically updates its picture of routing
state, route changes will eventually be repaired automatically. The
specification as already given includes this functionality. However,
especially if upper layer refresh times are extended to reduce
signalling load, the duration of inconsistent state may be very long
indeed. Therefore, GIST includes logic to exchange prompt
notifications with signalling applications, to allow local repair if
possible. The additional mechanisms to achieve this are described in
the following subsections. To a large extent, these additions can be
seen as implementation issues; the protocol messages and their
significance are not changed, but there are extra interactions
through the API between GIST and signalling applications, and
additional triggers for transitions between the various GIST states.
7.1.2. Route Change Detection Mechanisms
There are two aspects to detecting a route change at a single node:
o Detecting that the outgoing path, in the direction of the Query,
has or may have changed.
o Detecting that the incoming path, in the direction of the
Response, has (or may have) changed, in which case the node may no
longer be on the path at all.
At a single node, these processes are largely independent, although
clearly a change in one direction at a node corresponds to a change
the opposite direction at its peer. Note that there are two possible
forms for a route change: the interface through which a flow leaves
or enters a node may change, and the adjacent peer may change. In
general, a route change can include one or the other or both (or
indeed neither, although such changes are very hard to detect).
The route change detection mechanisms available to a node depend on
the MRM in use and the role the node played in setting up the routing
state in the first place (i.e. as Querying or Responding node). The
following discussion is specific to the case of the path-coupled MRM
using downstream Queries only; other scenarios may require other
methods. However, the repair logic described in the subsequent
Schulzrinne & Hancock Expires August 31, 2007 [Page 83]
Internet-Draft GIST February 2007
subsections is intended to be universal.
There are five mechanisms for a node to detect that a route change
has occurred, which are listed below. They apply differently
depending on whether the change is in the Query or Response
direction, and these differences are summarised in the following
table.
Local Trigger: In local trigger mode, GIST finds out from the local
forwarding table that the next hop has changed. This only works
if the routing change is local, not if it happens a few IP routing
hops away, including the case that it happens at a GIST-unaware
node.
Extended Trigger: Here, GIST checks a link-state topology database
to discover that the path has changed. This makes certain
assumptions on consistency of IP route computation and only works
within a single area for OSPF [17] and similar link-state
protocols. Where available, this offers the most accurate and
rapid indication of route changes, but requires more access to the
routing internals than a typical operating system may provide.
GIST C-mode Monitoring: GIST may find that C-mode packets are
arriving (from either peer) with a different IP layer TTL or on a
different interface. This provides no direct information about
the new flow path, but indicates that routing has changed and that
rediscovery may be required.
Data Plane Monitoring: The signalling application on a node may
detect a change in behaviour of the flow, such as IP layer TTL
change, arrival on a different interface, or loss of the flow
altogether. The signalling application on the node is allowed to
notify this information locally to GIST (Appendix B.6).
GIST Probing: According to the specification, each GIST node MUST
periodically repeat the discovery (Query/Response) operation.
Values for the probe frequency are discussed in Section 4.4.4.
The querying node will discover the route change by a modification
in the Network-Layer-Information in the Response. The period can
be negotiated independently for each GIST hop, so nodes that have
access to the other techniques listed above MAY use long periods
for the probing operation.
Schulzrinne & Hancock Expires August 31, 2007 [Page 84]
Internet-Draft GIST February 2007
+-------------+--------------------------+--------------------------+
| Method | Query direction | Response direction |
+-------------+--------------------------+--------------------------+
| Local | Discovers new interface | Not applicable |
| Trigger | (and peer if local) | |
| | | |
| Extended | Discovers new interface | May determine that route |
| Trigger | and may determine new | from peer will have |
| | peer | changed |
| | | |
| C-mode | Provides hint that | Provides hint that |
| Monitoring | change has occurred | change has occurred |
| | | |
| Data Plane | Not applicable | NSLP informs GIST that a |
| Monitoring | | change may have occurred |
| | | |
| Probing | Discovers changed NLI in | Discovers changed NLI in |
| | Response | Query |
+-------------+--------------------------+--------------------------+
7.1.3. GIST Behaviour Supporting Re-Routing
The basic GIST behaviour necessary to support re-routing can be
modelled using a 3-level classification of the validity of each item
of current routing state. (In addition to current routing state,
NSIS can maintain past routing state, described in Section 7.1.4
below.) This classification applies separately to the Querying and
Responding node for each pair of GIST peers. The levels are:
Bad: The routing state is either missing altogether, or not safe to
use to send data.
Tentative: The routing state may have changed, but it is still
usable for sending NSLP data pending verification.
Good: The routing state has been established and no events affecting
it have since been detected.
These classifications are not identical to the states described in
Section 6, but there are dependencies between them. Specifically,
routing state is considered Bad until the machine first enters the
Established state, at which point it becomes Good. Thereafter, the
status may be invalidated for any of the reasons discussed above; it
is an implementation issue to decide which techniques to implement in
any given node, and how to reclassify routing state (as Bad or
Tentative) for each. The status returns to Good, either when the
state machine re-enters the Established state, or if GIST can
determine from direct examination of the IP routing or forwarding
Schulzrinne & Hancock Expires August 31, 2007 [Page 85]
Internet-Draft GIST February 2007
tables that the peer has not changed. When the status returns to
Good, GIST MUST if necessary update its routing state table so that
the relationships between MRI/SID/NSLPID tuples and messaging
associations are up to date.
When classification of the routing state for the downstream direction
changes to Bad/Tentative because of local IP routing indications,
GIST MAY automatically change the classification in the upstream
direction to Tentative unless local routing indicates that this is
not necessary. This SHOULD NOT be done in the case where the initial
change was indicated by the signalling application. This mechanism
accounts for the fact that a routing change may affect several nodes,
and so can be an indication that upstream routing may also have
changed. In any case, whenever GIST updates the routing status, it
informs the signalling application with the NetworkNotification API
(Appendix B.4), unless the change was caused via the API in the first
place.
The GIST behaviour for state repair is different for the Querying and
Responding node. At the Responding node, there is no additional
behaviour, since the Responding node cannot initiate protocol
transitions autonomously, it can only react to the Querying node.
The Querying node has three options, depending on how the transition
from 'Good' was initially caused:
1. To inspect the IP routing/forwarding table and verifying that the
next peer has not changed. This technique MUST NOT be used if
the transition was caused by a signalling application, but SHOULD
be used otherwise if available.
2. To move to the 'Awaiting Refresh' state. This technique MUST NOT
be used if the current status is 'Bad', since data is being
incorrectly delivered.
3. To move to the 'Awaiting Response' state. This technique may be
used at any time, but has the effect of freezing NSLP
communication while GIST state is being repaired.
The second and third techniques trigger the execution of a GIST
handshake to carry out the repair. It may be desirable to delay the
start of the handshake process, either to wait for the network to
stabilise, to avoid flooding the network with Query traffic for a
large number of affected flows, or to wait for confirmation that the
node is still on the path from the upstream peer. One approach is to
delay the handshake until there is NSLP data to be transmitted.
Implementation of such delays is a matter of local policy; however,
GIST MUST begin the handshake immediately if the status change was
caused by an InvalidateRoutingState API call marked as 'Urgent', and
Schulzrinne & Hancock Expires August 31, 2007 [Page 86]
Internet-Draft GIST February 2007
SHOULD begin it if the upstream routing state is still known to be
Good.
7.1.4. Load Splitting and Route Flapping
The Q-mode encapsulation rules of Section 5.8 try to ensure that the
Query messages discovering the path mimic the flow as accurately as
possible. However, in environments where there is load balancing
over multiple routes, and this is based on header fields differing
between flow and Q-mode packets or done on a round-robin basis, the
path discovered by the Query may vary from one handshake to the next
even though the underlying network is stable. This will appear to
GIST as a route flap; route flapping can also be caused by problems
in the basic network connectivity or routing protocol operation.
This specification does not define mechanisms for GIST to manage
multiple parallel routes or an unstable route. The algorithms
already described always maintain the concept of the current route,
i.e. the latest peer discovered for a particular flow. Instead, GIST
allows the use of prior signalling paths for some period while the
signalling applications still need them. Since NSLP peers are a
single GIST hop apart, the necessary information to represent a path
can be just an entry in the node's routing state table for that flow
(more generally, anything that uniquely identifies the peer, such as
the NLI, could be used). Rather than requiring GIST to maintain
multiple generations of this information, it is provided to the
signalling application in the same node in an opaque form for each
message that is received from the peer. The signalling application
can store it if necessary and provide it back to the GIST layer in
case it needs to be used. Because this is a reference to information
about the source of a prior signalling message, it is denoted 'SII-
Handle' (for Source Identification Information) in the abstract API
of Appendix B.
Note that GIST if possible SHOULD use the same SII-Handle for
multiple sessions to the same peer, since this then allows signalling
applications to aggregate some signalling, such as summary refreshes
or bulk teardowns. Messages sent using the SII-Handle MUST bypass
the routing state tables at the sender, and this MUST be indicated by
setting the E flag in the common header (Appendix A.1). Messages
other than Data messages MUST NOT be sent in this way. At the
receiver, GIST MUST NOT validate the MRI/SID/NSLPID against local
routing state and instead indicates the mode of reception to
signalling applications through the API (Appendix B.2). Signalling
applications should validate the source and effect of the message
themselves, and if appropriate should in particular indicate to GIST
(see Appendix B.5) that routing state is no longer required for this
flow. This is necessary to prevent GIST in nodes on the old path
Schulzrinne & Hancock Expires August 31, 2007 [Page 87]
Internet-Draft GIST February 2007
initiating routing state refresh and thus causing state conflicts at
the crossover router.
GIST notifies signalling applications about route modifications as
two types of event, additions and deletions. An addition is notified
as a change of the current routing state according to the Bad/
Tentative/Good classification above, while deletion is expressed as a
statement that an SII handle no longer lies on the path. Both can be
reported through the NetworkNotification API call (Appendix B.4). A
minimal implementation MAY notify a route change as a single (add,
delete) operation; however, a more sophisticated implementation MAY
delay the delete notification, for example if it knows that the old
route continues to be used in parallel, or that the true route is
flapping between the two. It is then a matter of signalling
application design whether to tear down state on the old path, leave
it unchanged, or modify it in some signalling application specific
way to reflect the fact that multiple paths are operating in
parallel.
7.1.5. Signalling Application Operation
Signalling applications can use these functions as provided by GIST
to carry out rapid local repair following re-routing events. The
signalling application instances carry out the multi-hop aspects of
the procedure, including crossover node detection, and tear-down/
reinstallation of signalling application state; they also trigger
GIST to carry out the local routing state maintenance operations over
each individual hop. The local repair procedures depend heavily on
the fact that stateful NSLP nodes are a single GIST hop apart; this
is enforced by the details of the GIST peer discovery process.
The following outline description of a possible set of NSLP actions
takes the scenario of Figure 8 as an example.
1. The signalling application at node E1 is notified by GIST of
route changes affecting the downstream and upstream directions.
The downstream status was updated to Bad because of a trigger
from the local forwarding tables, and the upstream status changed
automatically to Tentative as a consequence. The signalling
application at E1 MAY begin local repair immediately, or MAY
propagate a notification upstream to D1 that re-routing has
occurred.
2. The signalling application at node D1 is notified of the route
change, either by signalling application notifications or from
the GIST level (e.g. by a trigger from a link-state topology
database). If the information propagates faster within the IP
routing protocol, GIST will change the upstream/downstream
Schulzrinne & Hancock Expires August 31, 2007 [Page 88]
Internet-Draft GIST February 2007
routing state to Tentative/Bad automatically, and this will cause
the signalling application to propagate the notification further
upstream.
3. This process continues until the notification reaches node A.
Here, there is no downstream routing change, so GIST only learns
of the update via the signalling application trigger. Since the
upstream status is still Good, it therefore begins the repair
handshake immediately.
4. The handshake initiated by node A causes its downstream routing
state to be confirmed as Good and unchanged there; it also
confirms the (Tentative) upstream routing state at B as Good.
This is enough to identify B as the crossover router, and the
signalling application and GIST can begin the local repair
process.
An alternative way to reach step (4) is that node B is able to
determine autonomously that there is no likelihood of an upstream
route change. For example, it could be an area border router and the
route change is only intra-area. In this case, the signalling
application and GIST will see that the upstream state is Good and can
begin the local repair directly.
After a route deletion, a signalling application may wish to remove
state at another node which is no longer on the path. However, since
it is no longer on the path, in principle GIST can no longer send
messages to it. In general, provided this state is soft, it will
time out anyway; however, the timeouts involved may have been set to
be very long to reduce signalling load. Instead, signalling
applications MAY use the SII-Handle described above to route explicit
teardown messages.
7.2. NAT Traversal
GIST messages, for example for the path-coupled MRM, must carry
addressing and higher layer information as payload data in order to
define the flow signalled for. (This applies to all GIST messages,
regardless of how they are encapsulated or which direction they are
travelling in.) At an addressing boundary the data flow packets will
have their headers translated; if the signalling payloads are not
translated consistently, the signalling messages will refer to
incorrect (and probably meaningless) flows after passing through the
boundary. In addition, GIST handshake messages carry additional
addressing information about the GIST nodes themselves, and this must
also be processed appropriately when traversing a NAT.
There is a dual problem of whether the GIST peers either side of the
Schulzrinne & Hancock Expires August 31, 2007 [Page 89]
Internet-Draft GIST February 2007
boundary can work out how to address each other, and whether they can
work out what translation to apply to the signalling packet payloads.
Existing generic NAT traversal techniques such as STUN [26] or TURN
[27] can operate only on the two addresses visible in the IP header.
It is therefore intrinsically difficult to use these techniques to
discover a consistent translation of the three or four interdependent
addresses for the flow and signalling source and destination.
For legacy NATs and MRMs that carry addressing information, the base
GIST specification is therefore limited to detecting the situation
and triggering the appropriate error conditions to terminate the
signalling path. (MRMs that do not contain addressing information
could traverse such NATs safely, with some modifications to the GIST
processing rules. Such modifications could be described in the
documents defining such MRMs.) Legacy NAT handling is covered in
Section 7.2.1 below. A more general solution can be constructed
using GIST-awareness in the NATs themselves; this solution is
outlined in Section 7.2.2 with processing rules in Section 7.2.3.
In all cases, GIST interaction with the NAT is determined by the way
the NAT handles the Query/Response messages in the initial GIST
handshake; these messages are UDP datagrams. Best current practice
for NAT treatment of UDP traffic is defined in [28], and the legacy
NAT handling defined in this specification is fully consistent with
that document. The GIST-aware NAT traversal technique is equivalent
to requiring an Application Layer Gateway in the NAT for a specific
class of UDP transactions, namely those where the destination UDP
port for the initial message is the GIST port (see Section 9).
7.2.1. Legacy NAT Handling
Legacy NAT detection during the GIST handshake depends on analysis of
the IP header and S flag in the GIST common header, and the NLI
object included in the handshake messages. The message sequence
proceeds differently depending on whether the Querying node is on the
internal or external side of the NAT.
For the case of the Querying node on the internal side of the NAT, if
the S flag is not set in the Query (S=0), a legacy NAT cannot be
detected. The receiver will generate a normal Response to the
interface-address given in the NLI in the Query, but the interface-
address will not be routable and the Response will not be delivered.
If retransmitted Queries keep S=0, this behaviour will persist until
the Querying node times out. The signalling path will thus terminate
at this point, not traversing the NAT.
The situation changes once S=1 in a Query; note the Q-mode
encapsulation rules recommend that S=1 is used at least for some
Schulzrinne & Hancock Expires August 31, 2007 [Page 90]
Internet-Draft GIST February 2007
retransmissions (see Section 5.8). If S=1, the receiver MUST check
the source address in the IP header against the interface-address in
the NLI, and if these addresses do not match this indicates that a
legacy NAT has been found. For MRMs which contain addressing
information that needs translation, legacy NAT traversal is not
possible. The receiver MUST return an "Object Type Error" message
(Appendix A.4.4.9) with subcode 4 ("Untranslated Object") indicating
the MRI as the object in question. The error message MUST be
addressed to the source address from the IP header of the incoming
message. The Responding node SHOULD use the destination IP address
of the original datagram as the source address for IP header of the
Response; this makes it more likely that the NAT will accept the
incoming message, since it looks like a normal UDP/IP request/reply
exchange. If this message is able to traverse back through the NAT,
the Querying node will terminate the handshake immediately;
otherwise, this reduces to the previous case of a lost Response and
the Querying node will give up on reaching its retransmission limit.
When the Querying node is on the external side of the NAT, the Query
will only traverse the NAT if some static configuration has been
carried out on the NAT to forward GIST Q-mode traffic to a node on
the internal network. Regardless of the S-flag in the Query, the
Responding node cannot directly detect the presence of the NAT. It
MUST send a normal Response with S=1 to an address derived from the
Querying node's NLI which will traverse the NAT as normal UDP
traffic. The Querying node MUST check the source address in the IP
header with the NLI in the Response, and when it finds a mismatch it
MUST terminate the handshake.
Note that in either of the error cases (internal or external Querying
node), an alternative to terminating the handshake could be to invoke
some legacy NAT traversal procedure. This specification does not
define any such procedure, although one possible approach is
described in [42]. Any such traversal procedure MUST be incorporated
into GIST using the existing GIST extensibility capabilities.
7.2.2. GIST-aware NAT Traversal
The most robust solution to the NAT traversal problem is to require
that a NAT is GIST-aware, and to allow it to modify messages based on
the contents of the MRI. This makes the assumption that NATs only
rewrite the header fields included in this payload, and not other
higher layer identifiers. Provided this is done consistently with
the data flow header translation, signalling messages will be valid
each side of the boundary, without requiring the NAT to be signalling
application aware. Note, however, that if the NAT does not
understand the MRI, and the N-flag in the MRI is clear (see
Appendix A.3.1), it should reject the message with an "Object Type
Schulzrinne & Hancock Expires August 31, 2007 [Page 91]
Internet-Draft GIST February 2007
Error" message (Appendix A.4.4.9) with subcode 4 ("Untranslated
Object").
This specification defines an additional object that a NAT inserts
into all Q-mode encapsulated messages and which is echoed back in any
replies, i.e. Response or Error messages. NATs apply GIST-specific
processing only to Q-mode encapsulated messages or replies carrying
the NAT traversal object. All other GIST messages, either in C-mode,
or D-mode messages with no NAT-Traversal object, should be treated as
normal data traffic by the NAT, i.e. with IP and transport layer
header translation but no GIST-specific processing.
The new object, the NAT-Traversal object (Appendix A.3.9), carries
the translation between the MRIs which are appropriate for the
internal and external sides of the NAT. It also carries a list of
which other objects in the message have been translated. This should
always include the NLI, and the Stack-Configuration-Data if present;
if GIST is extended with further objects that carry addressing data,
this list allows a message receiver to know if the new objects were
supported by the NAT. Finally, the NAT-Traversal object MAY be used
to carry data to assist the NAT in back-translating D-mode responses;
this could be the original NLI or SCD, or opaque equivalents in the
case of topology hiding.
A consequence of this approach is that the routing state tables at
the signalling application peers each side of the NAT are no longer
directly compatible. In particular, the values for Message-Routing-
Information are different, which is why the unmodified MRI is
propagated in the NAT-Traversal object to allow subsequent C-mode
messages to be interpreted correctly.
7.2.3. Message Processing Rules
This specification normatively defines the behaviour of a GIST node
receiving a message containing a NAT-Traversal object. However, it
does not define normative behaviour for a NAT translating GIST
messages, since much of this will depend on NAT implementation and
policy about allocating bindings. In addition, it is not necessary
for a GIST implementation itself. Therefore, those aspects of the
following description are informative; full details of NAT behaviour
for handling GIST messages can be found in [43].
A possible set of operations for a NAT to process a Q-mode
encapsulated message is as follows. Note that for a Data message,
only a subset of the operations is applicable.
1. Verify that bindings for any data flow are actually in place.
Schulzrinne & Hancock Expires August 31, 2007 [Page 92]
Internet-Draft GIST February 2007
2. Create a new Message-Routing-Information object with fields
modified according to the data flow bindings.
3. Create bindings for subsequent C-mode signalling based on the
information in the Network-Layer-Information and Stack-
Configuration-Data objects.
4. Create new Network-Layer-Information and if necessary Stack-
Configuration-Data objects with fields to force D-mode response
messages through the NAT, and to allow C-mode exchanges using the
C-mode signalling bindings.
5. Add a NAT-Traversal object, listing the objects which have been
modified and including the unmodified MRI and any other data
needed to interpret the response. If a NAT-Traversal object is
already present, in the case of a sequence of NATs, the list of
modified objects may be updated and further opaque data added,
but the MRI contained in it is left unchanged.
6. Encapsulate the message according to the normal rules of this
specification for the Q-mode encapsulation. If the S-flag was
set in the original message, the same IP source address selection
policy should be applied to the forwarded message.
7. Forward the message with these new payloads.
A GIST node receiving such a message MUST verify that all mandatory
objects containing addressing have been translated correctly, or else
reject the message with an "Object Type Error" message
(Appendix A.4.4.9) with subcode 4 ("Untranslated Object"). The error
message MUST include the NAT-Traversal object as the first TLV after
the common header, and this is also true for any other error message
generated as a reply. Otherwise, the message is processed
essentially as normal. If no state needs to be updated for the
message, the NAT-Traversal object can be effectively ignored. The
other possibility is that a Response must be returned, either because
the message is the beginning of a handshake for a new flow, or it is
a refresh for existing state. In both cases, the GIST node MUST
create the Response in the normal way using the local form of the
MRI, and its own NLI and (if necessary) SCD. It MUST also include
the NAT-Traversal object as the first object in the Response after
the common header.
A NAT will intercept D-mode messages with the normal encapsulation
containing such echoed NAT-Traversal objects. The NAT processing is
a subset of the processing for the Q-mode encapsulated case:
Schulzrinne & Hancock Expires August 31, 2007 [Page 93]
Internet-Draft GIST February 2007
1. Verify the existence of bindings for the data flow.
2. Leave the Message-Routing-Information object unchanged.
3. Modify the NLI and SCD objects for the Responding node if
necessary, and create or update any bindings for C-mode
signalling traffic.
4. Forward the message.
A GIST node receiving such a message MUST use the MRI from the NAT-
Traversal object as the key to index its internal routing state; it
MAY also store the translated MRI for additional (e.g. diagnostic)
information, but this is not used in the GIST processing. The
remainder of GIST processing is unchanged.
Note that Confirm messages are not given GIST-specific processing by
the NAT. Thus, a Responding node which has delayed state
installation until receiving the Confirm, only has available the
untranslated MRI describing the flow, and the untranslated NLI as
peer routing state. This would prevent the correct interpretation of
the signalling messages; also, subsequent Query (refresh) messages
would always be seen as route changes because of the NLI change.
Therefore, a Responding node that wishes to delay state installation
until receiving a Confirm must somehow reconstruct the translations
when the Confirm arrives. How to do this is an implementation issue;
one approach is to carry the translated objects as part of the
Responder cookie which is echoed in the Confirm. Indeed, for one of
the cookie constructions in Section 8.5 this is automatic.
7.3. Interaction with IP Tunnelling
The interaction between GIST and IP tunnelling is very simple. An IP
packet carrying a GIST message is treated exactly the same as any
other packet with the same source and destination addresses: in other
words, it is given the tunnel encapsulation and forwarded with the
other data packets.
Tunnelled packets will not be identifiable as GIST messages until
they leave the tunnel, since any router alert option and the standard
GIST protocol encapsulation (e.g. port numbers) will be hidden within
the standard tunnel encapsulation. If signalling is needed for the
tunnel itself, this has to be initiated as a separate signalling
session by one of the tunnel endpoints - that is, the tunnel counts
as a new flow. Because the relationship between signalling for the
microflow and signalling for the tunnel as a whole will depend on the
signalling application in question, it is a signalling application
responsibility to be aware of the fact that tunnelling is taking
Schulzrinne & Hancock Expires August 31, 2007 [Page 94]
Internet-Draft GIST February 2007
place and to carry out additional signalling if necessary; in other
words, at least one tunnel endpoint must be signalling application
aware.
In some cases, it is the tunnel exit point (i.e. the node where
tunnelled data and downstream signalling packets leave the tunnel)
that will wish to carry out the tunnel signalling, but this node will
not have knowledge or control of how the tunnel entry point is
carrying out the data flow encapsulation. The information about how
the inner MRI/SID relate to the tunnel MRI/SID needs to be carried in
the signalling data from the tunnel entry point; this functionality
is the equivalent to the RSVP SESSION_ASSOC object of [18]. In the
NSIS protocol suite, these bindings are managed by the signalling
applications, either implicitly (e.g. by SID re-use) or explicitly by
carrying objects that bind the inner and outer SIDs as part of the
NSLP payload.
7.4. IPv4-IPv6 Transition and Interworking
GIST itself is essentially IP version neutral: version dependencies
are isolated in the formats of the Message-Routing-Information,
Network-Layer-Information and Stack-Configuration-Data objects, and
GIST also depends on the version independence of the protocols that
support messaging associations. In mixed environments, GIST
operation will be influenced by the IP transition mechanisms in use.
This section provides a high level overview of how GIST is affected,
considering only the currently predominant mechanisms.
Dual Stack: (As described in [38].) In mixed environments, GIST
MUST use the same IP version for Q-mode encapsulated messages as
given by the MRI of the flow it is signalling for, and SHOULD do
so for other signalling also (see Section 5.2.2). Messages with
mismatching versions MUST be rejected with a "MRI Validation
Failure" error message (Appendix A.4.4.12) with subcode 1 ("IP
Version Mismatch"). The IP version used in D-mode is closely tied
to the IP version used by the data flow, so it is intrinsically
impossible for an IPv4-only or IPv6-only GIST node to support
signalling for flows using the other IP version. Hosts which are
dual stack for applications and routers which are dual stack for
forwarding need GIST implementations which can support both IP
versions. Applications with a choice of IP versions might select
a version based on which could be supported in the network by
GIST, which could be established by invoking parallel discovery
procedures.
Schulzrinne & Hancock Expires August 31, 2007 [Page 95]
Internet-Draft GIST February 2007
Packet Translation: (Applicable to SIIT [9] and NAT-PT [19].) Some
transition mechanisms allow IPv4 and IPv6 nodes to communicate by
placing packet translators between them. From the GIST
perspective, this should be treated essentially the same way as
any other NAT operation (e.g. between internal and external
addresses) as described in Section 7.2. The translating node
needs to be GIST-aware; it will have to translate the addressing
payloads between IPv4 and IPv6 formats for flows which cross
between the two. The translation rules for the fields in the MRI
payload (including e.g. DiffServ-codepoint and flow-label) are as
defined in [9].
Tunnelling: (Applicable to 6to4 [21].) Many transition mechanisms
handle the problem of how an end to end IPv6 (or IPv4) flow can be
carried over intermediate IPv4 (or IPv6) regions by tunnelling;
the methods tend to focus on minimising the tunnel administration
overhead.
From the GIST perspective, the treatment should be similar to any
other IP tunnelling mechanism, as described in Section 7.3. In
particular, the end to end flow signalling will pass transparently
through the tunnel, and signalling for the tunnel itself will have
to be managed by the tunnel endpoints. However, additional
considerations may arise because of special features of the tunnel
management procedures. In particular, [22] is based on using an
anycast address as the destination tunnel endpoint. GIST MAY use
anycast destination addresses in the Q-mode encapsulation of
D-mode messages if necessary, but MUST NOT use them in the
Network-Layer-Information addressing field; unicast addresses MUST
be used instead. Note that the addresses from the IP header are
not used by GIST in matching requests and replies, so there is no
requirement to use anycast source addresses.
Schulzrinne & Hancock Expires August 31, 2007 [Page 96]
Internet-Draft GIST February 2007
8. Security Considerations
The security requirement for GIST is to protect the signalling plane
against identified security threats. For the signalling problem as a
whole, these threats have been outlined in [32]; the NSIS framework
[31] assigns a subset of the responsibilities to the NTLP. The main
issues to be handled can be summarised as:
Message Protection: Signalling message content can be protected
against eavesdropping, modification, injection and replay while in
transit. This applies both to GIST payloads, and GIST should also
provide such protection as a service to signalling applications
between adjacent peers.
Routing State Integrity Protection: It is important that signalling
messages are delivered to the correct nodes, and nowhere else.
Here, 'correct' is defined as 'the appropriate nodes for the
signalling given the Message-Routing-Information'. In the case
where the MRI is based on the Flow Identification for path-coupled
signalling, 'appropriate' means 'the same nodes that the
infrastructure will route data flow packets through'. GIST has no
role in deciding whether the data flow itself is being routed
correctly; all it can do is ensure the signalling is routed
consistently with it. GIST uses internal state to decide how to
route signalling messages, and this state needs to be protected
against corruption.
Prevention of Denial of Service Attacks: GIST nodes and the network
have finite resources (state storage, processing power,
bandwidth). The protocol tries to minimise exhaustion attacks
against these resources and not allow GIST nodes to be used to
launch attacks on other network elements.
The main additional issue is handling authorisation for executing
signalling operations (e.g. allocating resources). This is assumed
to be done in each signalling application.
In many cases, GIST relies on the security mechanisms available in
messaging associations to handle these issues, rather than
introducing new security measures. Obviously, this requires the
interaction of these mechanisms with the rest of the GIST protocol to
be understood and verified, and some aspects of this are discussed in
Section 5.7.
8.1. Message Confidentiality and Integrity
GIST can use messaging association functionality, specifically in
this version TLS (Section 5.7.3), to ensure message confidentiality
Schulzrinne & Hancock Expires August 31, 2007 [Page 97]
Internet-Draft GIST February 2007
and integrity. Implementation of this functionality is REQUIRED but
its use for any given flow or signalling application is OPTIONAL. In
some cases, confidentiality of GIST information itself is not likely
to be a prime concern, in particular since messages are often sent to
parties which are unknown ahead of time, although the content visible
even at the GIST level gives significant opportunities for traffic
analysis. Signalling applications may have their own mechanism for
securing content as necessary; however, they may find it convenient
to rely on protection provided by messaging associations, since it
runs unbroken between signalling application peers.
8.2. Peer Node Authentication
Cryptographic protection (of confidentiality or integrity) requires a
security association with session keys. These can be established by
an authentication and key exchange protocol based on shared secrets,
public key techniques or a combination of both. Authentication and
key agreement is possible using the protocols associated with the
messaging association being secured. TLS incorporates this
functionality directly. GIST nodes rely on the messaging association
protocol to authenticate the identity of the next hop, and GIST has
no authentication capability of its own.
With routing state discovery, there are few effective ways to know
what is the legitimate next or previous hop as opposed to an
impostor. In other words, cryptographic authentication here only
provides assurance that a node is 'who' it is (i.e. the legitimate
owner of identity in some namespace), not 'what' it is (i.e. a node
which is genuinely on the flow path and therefore can carry out
signalling for a particular flow). Authentication provides only
limited protection, in that a known peer is unlikely to lie about its
role. Additional methods of protection against this type of attack
are considered in Section 8.3 below.
It is an implementation issue whether peer node authentication should
be made signalling application dependent; for example, whether
successful authentication could be made dependent on presenting
credentials related to a particular signalling role (e.g. signalling
for QoS). The abstract API of Appendix B leaves open such policy and
authentication interactions between GIST and the NSLP it is serving.
However, it does allow applications to inspect the authenticated
identity of the peer to which a message will be sent before
transmission.
8.3. Routing State Integrity
Internal state in a node (see Section 4.2) is used to route messages.
If this state is corrupted, signalling messages may be misdirected.
Schulzrinne & Hancock Expires August 31, 2007 [Page 98]
Internet-Draft GIST February 2007
In the case where the MRM is path-coupled, the messages need to be
routed identically to the data flow described by the MRI, and the
routing state table is the GIST view of how these flows are being
routed through the network in the immediate neighbourhood of the
node. Routes are only weakly secured (e.g. there is no cryptographic
binding of a flow to a route), and there is no authoritative
information about flow routes other than the current state of the
network itself. Therefore, consistency between GIST and network
routing state has to be ensured by directly interacting with the IP
routing mechanisms to ensure that the signalling peers are the
appropriate ones for any given flow. An overview of security issues
and techniques in this context is provided in [40].
In one direction, peer identification is installed and refreshed only
on receiving a Response (compare Figure 4). This MUST echo the
cookie from a previous Query, which will have been sent along the
flow path with the Q-mode encapsulation, i.e. end-to-end addressed.
Hence, only the true next peer or an on-path attacker will be able to
generate such a message, provided freshness of the cookie can be
checked at the querying node.
In the other direction, peer identification MAY be installed directly
on receiving a Query containing addressing information for the
signalling source. However, any node in the network could generate
such a message; indeed, many nodes in the network could be the
genuine upstream peer for a given flow. To protect against this,
four strategies are used:
Filtering: the receiving node MAY reject signalling messages which
claim to be for flows with flow source addresses which could be
ruled out by ingress filtering. An extension of this technique
would be for the receiving node to monitor the data plane and to
check explicitly that the flow packets are arriving over the same
interface and if possible from the same link layer neighbour as
the D-mode signalling packets. If they are not, it is likely that
at least one of the signalling or flow packets is being spoofed.
Return routability checking: the receiving node MAY refuse to
install upstream state until it has completed a Confirm handshake
with the peer. This echoes the Response cookie of the Response,
and discourages nodes from using forged source addresses. This
also plays a role in denial of service prevention, see below.
Authorisation: a stronger approach is to carry out a peer
authorisation check (see Section 4.4.2) as part of messaging
association setup. The ideal situation is that the receiving node
can determine the correct upstream node address from routing table
analysis or knowledge of local topology constraints, and then
Schulzrinne & Hancock Expires August 31, 2007 [Page 99]
Internet-Draft GIST February 2007
verify from the authorised peer database (APD) that the peer has
this IP address. This is only technically feasible in a limited
set of deployment environments. The APD can also be used to list
the subsets of nodes which are feasible peers for particular
source or destination subnets, or to blacklist nodes which have
previously originated attacks or exist in untrustworthy networks,
which provide weaker levels of authorisation checking.
SID segregation: The routing state lookup for a given MRI and NSLPID
MUST also take the SID into account. A malicious node can only
overwrite existing GIST routing state if it can guess the
corresponding SID; it can insert state with random SID values, but
generally this will not be used to route signalling messages for
which state has already been legitimately established.
8.4. Denial of Service Prevention and Overload Protection
GIST is designed so that in general each Query only generates at most
one Response which is at most only slightly larger than the Query, so
that a GIST node cannot become the source of a denial of service
amplification attack. (There is a special case of retransmitted
Response messages, see Section 5.3.3.)
However, GIST can still be subjected to denial-of-service attacks
where an attacker using forged source addresses forces a node to
establish state without return routability, causing a problem similar
to TCP SYN flood attacks. Furthermore, an adversary might use
modified or replayed unprotected signalling messages as part of such
an attack. There are two types of state attacks and one
computational resource attack. In the first state attack, an
attacker floods a node with messages that the node has to store until
it can determine the next hop. If the destination address is chosen
so that there is no GIST-capable next hop, the node would accumulate
messages for several seconds until the discovery retransmission
attempt times out. The second type of state-based attack causes GIST
state to be established by bogus messages. A related computational/
network-resource attack uses unverified messages to cause a node
query an authentication or authorisation infrastructure, or attempt
to cryptographically verify a digital signature.
We use a combination of two defences against these attacks:
1. The responding node need not establish a session or discover its
next hop on receiving the Query, but MAY wait for a Confirm,
possibly on a secure channel. If the channel exists, the
additional delay is one one-way delay and the total is no more
than the minimal theoretically possible delay of a three-way
handshake, i.e., 1.5 node-to-node round-trip times. The delay
Schulzrinne & Hancock Expires August 31, 2007 [Page 100]
Internet-Draft GIST February 2007
gets significantly larger if a new connection needs to be
established first.
2. The Response to the Query contains a cookie, which is repeated in
the Confirm. State is only established for messages that contain
a valid cookie. The setup delay is also 1.5 round-trip times.
This mechanism is similar to that in SCTP [20] and other modern
protocols.
There is a potential overload condition if a node is flooded with
Query or Confirm messages. One option is for the node to bypass
these messages altogether as described in Section 4.3.2, effectively
falling back to being a non-NSIS node. If this is not possible, a
node MAY still choose to limit the rate at which it processes Query
messages and discard the excess, although it SHOULD first adapt its
policy to one of sending Responses statelessly if it is not already
doing so. A conformant GIST node will automatically decrease the
load by retransmitting Queries with an exponential backoff. A non-
conformant node (launching a DoS attack) can generate uncorrelated
Queries at an arbitrary rate, which makes it hard to apply rate-
limiting without also affecting genuine handshake attempts. However,
if Confirm messages are requested, the cookie binds the message to a
Querying node address which has been validated by a return
routability check and rate-limits can be applied per-source.
Once a node has decided to establish routing state, there may still
be transport and security state to be established between peers.
This state setup is also vulnerable to denial of service attacks.
GIST relies on the implementations of the lower layer protocols that
make up messaging associations to mitigate such attacks. In the
current specification, the querying node is always the one wishing to
establish a messaging association, so it is the responding node that
needs to be protected. It is possible for an attacking node to
execute these protocols legally to set up large numbers of
associations that were never used, and responding node
implementations MAY use rate-limiting or other techniques to control
the load in such cases.
Signalling applications can use the services provided by GIST to
defend against certain (e.g. flooding) denial of service attacks. In
particular, they can elect to process only messages from peers that
have passed a return routability check or been authenticated at the
messaging association level (see Appendix B.2). Signalling
applications that accept messages under other circumstances (in
particular, before routing state has been fully established at the
GIST level) need to take this into account when designing their
denial of service prevention mechanisms, for example by not creating
local state as a result of processing such messages. Signalling
Schulzrinne & Hancock Expires August 31, 2007 [Page 101]
Internet-Draft GIST February 2007
applications can also manage overload by invoking flow control, as
described in Section 4.1.1.
8.5. Requirements on Cookie Mechanisms
The requirements on the Query cookie can be summarised as follows:
Liveness: The cookie must be live, that is, it must change from one
handshake to the next. To prevent replay attacks.
Unpredictability: The cookie must not be guessable e.g. from a
sequence or timestamp. To prevent direct forgery based on seeing
a history of captured messages.
Easily validated: It must be efficient for the Q-Node to validate
that a particular cookie matches an in-progress handshake, for a
routing state machine which already exists. To discard responses
which have been randomly generated by an adversary, or to discard
responses to queries which were generated with forged source
addresses or an incorrect address in the included NLI object.
Uniqueness: The cookie must be unique to a given handshake since it
is actually used to match the Response to a handshake anyway, e.g.
because of messaging association multiplexing.
Likewise, the requirements on the Responder cookie can be summarised
as follows:
Liveness: The cookie must be live as above. To prevent replay
attacks.
Creation simplicity: The cookie must be lightweight to generate. To
avoid resource exhaustion at the responding node.
Validation simplicity: It must be simple for the R-node to validate
that an R-cookie was generated by itself and no-one else, without
storing state about the handshake it was generated for.
Binding: The cookie must be bound to the routing state that will be
installed. To prevent use with different routing state e.g. in a
modified Confirm. The routing state here includes the NLI of the
Query, the MRI/NSLPID for the messaging, and the interface on
which the Query was received.
A suitable implementation for the Q-Cookie is a cryptographically
strong random number which is unique for this routing state machine
handshake. A node MUST implement this or an equivalently strong
mechanism. Guidance on random number generation can be found in
Schulzrinne & Hancock Expires August 31, 2007 [Page 102]
Internet-Draft GIST February 2007
[33].
A suitable implementation for the R-Cookie is as follows:
R-Cookie = liveness data + hash (locally known secret,
Q-Node NLI, MRI, NSLPID,
reception interface,
liveness data)
A node MUST implement this or an equivalently strong mechanism.
There are several alternatives for the liveness data. One is to use
a timestamp like SCTP. Another is to give the local secret a (rapid)
rollover, with the liveness data as the generation number of the
secret, like IKEv2. In both cases, the liveness data has to be
carried outside the hash, to allow the hash to be verified at the
Responder. Another approach is to replace the hash with encryption
under a locally known secret, in which case the liveness data does
not need to be carried in the clear. Any symmetric cipher immune to
known plaintext attacks can be used.
To support the validation simplicity requirement, the Responder can
check the liveness data to filter out some blind (flooding) attacks
before beginning any cryptographic cookie verification. To support
this usage, the liveness data must be carried in the clear and not be
easily guessable; this rules out the timestamp approach, and suggests
the use of sequence of secrets with the liveness data identifying the
position in the sequence. The secret strength and rollover frequency
must be high enough that the secret cannot be brute-forced during its
lifetime. Note that any node can use a Query to discover the current
liveness data, so it remains hard to defend against sophisticated
attacks which disguise such probes within a flood of Queries from
forged source addresses. Therefore, it remains important to use an
efficient hashing mechanism or equivalent.
If a node receives a message for which cookie validation fails, it
MAY return an "Object Value Error" message (Appendix A.4.4.10) with
subcode 4 ("Invalid Cookie") to the sender, as well as dropping the
message. However, sending the error in general makes a node a source
of backscatter. Therefore, this MUST only be enabled selectively,
e.g. during initial deployment or debugging.
8.6. Security Protocol Selection Policy
This specification defines a single mandatory-to-implement security
protocol (TLS, Section 5.7.3). However, it is possible to define
additional security protocols in the future, for example to allow re-
use with other types of credentials, or migrate towards protocols
with stronger security properties. In addition, use of any security
Schulzrinne & Hancock Expires August 31, 2007 [Page 103]
Internet-Draft GIST February 2007
protocol for a messaging association is optional. Security protocol
selection is carried out as part of the GIST handshake mechanism
(Section 4.4.1).
The selection process may be vulnerable to downgrade attacks, where a
man in the middle modifies the capabilities offered in the Query or
Response to mislead the peers into accepting a lower level of
protection than is achievable. There is a two part defence against
such attacks (the following is based the same concepts as [25]):
1. The Response does not depend on the Stack-Proposal in the Query
(see Section 5.7.1). Therefore, tampering with the Query has no
effect on the resulting messaging association configuration.
2. The Responding node's Stack-Proposal is echoed in the Confirm.
The Responding node checks this to validate that the proposal it
made in the Response is the same as the one received by the
Querying node. Note that as a consequence of the previous point,
the Responding node does not have to remember the proposal
explicitly, since it is a static function of local policy.
The validity of the second part depends on the strength of the
security protection provided for the Confirm. If the Querying node
is prepared to create messaging associations with null security
properties (e.g. TCP only), the defence is ineffective, since the
man in the middle can re-insert the original Responder's Stack-
Proposal, and the Responding node will assume that the minimal
protection is a consequence of Querying node limitations. However,
if the messaging association provides at least integrity protection
that cannot be broken in real-time, the Confirm cannot be modified in
this way. Therefore, if the Querying node does not apply a security
policy to the messaging association protocols to be created that
ensures at least this minimal level of protection is met, it remains
open to the threat that a downgrade has occurred. Applying such a
policy ensures capability discovery process will result in the setup
of a messaging association with the correct security properties as
appropriate for the two peers involved.
8.7. Residual Threats
Taking the above security mechanisms into account, the main residual
threats against NSIS are three types of on-path attack, as well as
implementation-related weaknesses.
An on-path attacker who can intercept the initial Query can do most
things it wants to the subsequent signalling. It is very hard to
protect against this at the GIST level; the only defence is to use
strong messaging association security to see whether the Responding
Schulzrinne & Hancock Expires August 31, 2007 [Page 104]
Internet-Draft GIST February 2007
node is authorised to take part in NSLP signalling exchanges. To
some extent, this behaviour is logically indistinguishable from
correct operation, so it is easy to see why defence is difficult.
Note that an on-path attacker of this sort can do anything to the
traffic as well as the signalling. Therefore, the additional threat
induced by the signalling weakness seems tolerable.
At the NSLP level, there is a concern about transitivity of trust of
correctness of routing along the signalling chain. The NSLP at the
querying node can have good assurance that it is communicating with
an on-path peer or a node delegated by the on-path node by depending
on the security protection provided by GIST. However, it has no
assurance that the node beyond the responder is also on-path, or that
the MRI (in particular) is not being modified by the responder to
refer to a different flow. Therefore, if it sends signalling
messages with payloads (e.g. authorisation tokens) which are valuable
to nodes beyond the adjacent hop, it is up to the NSLP to ensure that
the appropriate chain of trust exists. This could be achieved using
higher layer security protection such as CMS [30].
There is a further residual attack by a node which is not on the path
of the Query, but is on the path of the Response, or is able to use a
Response from one handshake to interfere with another. The attacker
modifies the Response to cause the Querying node to form an adjacency
with it rather than the true peer. In principle, this attack could
be prevented by including an additional cryptographic object in the
Response which ties the Response to the initial Query and the routing
state and can be verified by the Querying node.
Certain security aspects of GIST operation depend on signalling
application behaviour: a poorly implemented or compromised NSLP could
degrade GIST security. However, the degradation would only affect
GIST handling of the NSLP's own signalling traffic or overall
resource usage at the node where the weakness occurred, and
implementation weakness or compromise could have just as great an
effect within the NSLP itself. GIST depends on NSLPs to choose SIDs
appropriately (Section 4.1.3). If NSLPs choose non-random SIDs this
makes off-path attacks based on SID guessing easier to carry out.
NSLPs can also leak information in structured SIDs, but they could
leak similar information in the NLSP payload data anyway.
Schulzrinne & Hancock Expires August 31, 2007 [Page 105]
Internet-Draft GIST February 2007
9. IANA Considerations
This section defines the registries and initial codepoint assignments
for GIST. It also defines the procedural requirements to be followed
by IANA in allocating new codepoints. Note that the guidelines on
the technical criteria to be followed in evaluating requests for new
codepoint assignments are covered normatively in a separate document
which considers the NSIS protocol suite in a unified way. That
document discusses the general issue of NSIS extensibility, as well
as the technical criteria for particular registries; see [15] for
further details.
The registry definitions that follow leave large blocks of codes
marked "Reserved - not to be allocated". This is to allow a future
revision of this specification or another Standards Track document to
modify the relative space given to different allocation policies
without having to change the initial rules retrospectively if they
turn out to have been inappropriate, e.g. if the space for one
particular policy is exhausted too quickly.
The allocation policies used in this section follow the guidance
given in [6]. In addition, for a number of the GIST registries, this
specification also defines private/experimental ranges as discussed
in [12]. Note that the only environment in which these codepoints
can validly be used is a closed one in which the experimenter knows
all the experiments in progress.
This specification allocates the following codepoints in existing
registries:
Well-known UDP port XXX as the destination port for Q-mode
encapsulated GIST messages (Section 5.3).
This specification creates the following registries with the
structures as defined below:
NSLP Identifiers: Each signalling application requires the
assignment of one of more NSLPIDs. The following NSLPID is
allocated by this specification:
+---------+---------------------------------------------------------+
| NSLPID | Application |
+---------+---------------------------------------------------------+
| 0 | Used for GIST messages not related to any signalling |
| | application. |
+---------+---------------------------------------------------------+
Every other NSLPID that uses an MRM which requires RAO usage MUST
Schulzrinne & Hancock Expires August 31, 2007 [Page 106]
Internet-Draft GIST February 2007
be associated with a specific RAO value; multiple NSLPIDs MAY be
associated with the same value. RAO value assignments require a
specification of the processing associated with messages that
carry the value. NSLP specifications MUST normatively depend on
this document for the processing, specifically Section 4.3.1,
Section 4.3.4 and Section 5.3.2. The NSLPID is a 16 bit integer,
and allocation policies for further values are as follows:
1-32703: IESG Approval
32704-32767: Private/Experimental Use
32768-65536: Reserved - not to be allocated
GIST Message Type: The GIST common header (Appendix A.1) contains a
1 byte message type field. The following values are allocated by
this specification:
+---------+----------+
| MType | Message |
+---------+----------+
| 0 | Query |
| | |
| 1 | Response |
| | |
| 2 | Confirm |
| | |
| 3 | Data |
| | |
| 4 | Error |
| | |
| 5 | MA-Hello |
+---------+----------+
Allocation policies for further values are as follows:
6-63: Standards Action
64-119: Expert Review
120-127: Private/Experimental Use
128-255: Reserved - not to be allocated
Schulzrinne & Hancock Expires August 31, 2007 [Page 107]
Internet-Draft GIST February 2007
Object Types: There is a 12-bit field in the object header
(Appendix A.2). The following values for object type are defined
by this specification:
+---------+-----------------------------+
| OType | Object Type |
+---------+-----------------------------+
| 0 | Message Routing Information |
| | |
| 1 | Session ID |
| | |
| 2 | Network Layer Information |
| | |
| 3 | Stack Proposal |
| | |
| 4 | Stack Configuration Data |
| | |
| 5 | Query Cookie |
| | |
| 6 | Responder Cookie |
| | |
| 7 | NAT Traversal |
| | |
| 8 | NSLP Data |
| | |
| 9 | Error |
| | |
| 10 | Hello ID |
+---------+-----------------------------+
Allocation policies for further values are as follows:
10-1023: Standards Action
1024-1999: Specification Required
2000-2047: Private/Experimental Use
2048-4095: Reserved - not to be allocated
When a new object type is allocated according to one of the first
two policies, the specification MUST provide the object format and
define the setting of the extensibility bits (A/B, see
Appendix A.2.1).
Schulzrinne & Hancock Expires August 31, 2007 [Page 108]
Internet-Draft GIST February 2007
Message Routing Methods: GIST allows multiple message routing
methods (see Section 3.3). The MRM is indicated in the leading
byte of the MRI object (Appendix A.3.1). This specification
defines the following values:
+------------+------------------------+
| MRM-ID | Message Routing Method |
+------------+------------------------+
| 0 | Path Coupled MRM |
| | |
| 1 | Loose End MRM |
+------------+------------------------+
Allocation policies for further values are as follows:
2-63: Standards Action
64-119: Expert Review
120-127: Private/Experimental Use
128-255: Reserved - not to be allocated
When a new MRM is defined according to one of the first two
policies, a specification document will be required. This MUST
provide the information described in Section 3.3.
MA-Protocol-IDs: Each protocol that can be used in a messaging
association is identified by a 1-byte MA-Protocol-ID
(Section 5.7). Note that the MA-Protocol-ID is not an IP Protocol
number; indeed, some of the messaging association protocols - such
as TLS - do not have an IP Protocol number. This is used as a tag
in the Stack-Proposal and Stack-Configuration-Data objects
(Appendix A.3.4 and Appendix A.3.5). The following values are
defined by this specification:
+---------------------+-----------------------------------------+
| MA-Protocol-ID | Protocol |
+---------------------+-----------------------------------------+
| 0 | Reserved - not to be allocated |
| | |
| 1 | TCP opened in the forwards direction |
| | |
| 2 | TLS initiated in the forwards direction |
+---------------------+-----------------------------------------+
Allocation policies for further values are as follows:
Schulzrinne & Hancock Expires August 31, 2007 [Page 109]
Internet-Draft GIST February 2007
3-63: Standards Action
64-119: Expert Review
120-127: Private/Experimental Use
128-255: Reserved - not to be allocated
When a new MA-Protocol-ID is allocated according to one of the
first two policies, a specification document will be required.
This MUST define the format for the MA-protocol-options field (if
any) in the Stack-Configuration-Data object that is needed to
define its configuration. If a protocol is to be used for
reliable message transfer, it MUST be described how delivery
errors are to be detected by GIST. Extensions to include new
channel security protocols MUST include a description of how to
integrate the functionality described in Section 3.9 with the rest
of GIST operation. If the new MA-Protocol-ID can be used in
conjunction with existing ones (for example, a new transport
protocol option which could be used with Transport Layer
Security), the specification MUST define the interaction between
the two.
Error Codes/Subcodes: There is a 2 byte error code and 1 byte
subcode in the Value field of the Error object (Appendix A.4.1).
Error codes 1-12 are defined in Appendix A.4.4 together with
subcodes 0-4 (code 1), 0-5 (code 9), 0-5 (code 10), and 0-2 (code
12). Additional codes and subcodes are allocated on a first-come,
first-served basis. When a new code/subcode combination is
allocated, the following information MUST be provided:
Error case: textual name of error
Error class: from the categories given in Appendix A.4.3
Error code: allocated by IANA, if a new code is required
Error subcode: subcode point, also allocated by IANA
Additional information: what additional information fields it is
mandatory to include in the error message, from Appendix A.4.2
Additional Information Types: An Error object (Appendix A.4.1) may
contain Additional Information fields. Each possible field type
is identified by a 16-bit AI-Type. AI-Types 1-4 are defined in
Appendix A.4.2; additional AI-Types are allocated on a first-come,
first-served basis.
Schulzrinne & Hancock Expires August 31, 2007 [Page 110]
Internet-Draft GIST February 2007
10. Acknowledgements
This document is based on the discussions within the IETF NSIS
working group. It has been informed by prior work and formal and
informal inputs from: Cedric Aoun, Attila Bader, Roland Bless, Bob
Braden, Marcus Brunner, Benoit Campedel, Yoshiko Chong, Luis
Cordeiro, Elwyn Davies, Christian Dickmann, Pasi Eronen, Alan Ford,
Xiaoming Fu, Bo Gao, Ruediger Geib, Eleanor Hepworth, Thomas Herzog,
Cheng Hong, Jia Jia, Cornelia Kappler, Georgios Karagiannis, Ruud
Klaver, Chris Lang, John Loughney, Allison Mankin, Jukka Manner, Pete
McCann, Andrew McDonald, Glenn Morrow, Dave Oran, Andreas Pashalidis,
Henning Peters, Tom Phelan, Akbar Rahman, Takako Sanda, Charles Shen,
Melinda Shore, Martin Stiemerling, Martijn Swanink, Mike Thomas,
Hannes Tschofenig, Sven van den Bosch, Michael Welzl, Lars Westberg,
and Mayi Zoumaro-djayoon. Parts of the TLS usage description
(Section 5.7.3) were derived from the Diameter base protocol
specification, RFC3588. In addition, Hannes Tschofenig provided a
detailed set of review comments on the security section, and Andrew
McDonald provided the formal description for the initial packet
formats and the name matching algorithm for TLS. Chris Lang's
implementation work provided objective feedback on the clarity and
feasibility of the specification, and he also provided the state
machine description and the initial error catalogue and formats.
Magnus Westerlund carried out a detailed AD review which identified a
number of issues and led to significant clarifications, which was
followed by an even more detailed IESG review, with comments from
Ross Callon, Brian Carpenter, Lisa Dusseault, Lars Eggert, Ted
Hardie, Sam Hartman, Russ Housley, Cullen Jennings, and a very
detailed analysis by Adrian Farrel from the Routing Area directorate.
Schulzrinne & Hancock Expires August 31, 2007 [Page 111]
Internet-Draft GIST February 2007
11. References
11.1. Normative References
[1] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[3] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Schiller, J., "Cryptographic Algorithms for Use in the Internet
Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[7] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[8] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[9] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC 2765, February 2000.
[10] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[11] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[12] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[13] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
Schulzrinne & Hancock Expires August 31, 2007 [Page 112]
Internet-Draft GIST February 2007
[15] Loughney, J., "NSIS Extensibility Model",
draft-loughney-nsis-ext-02 (work in progress), March 2006.
11.2. Informative References
[16] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[17] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[18] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
Operation Over IP Tunnels", RFC 2746, January 2000.
[19] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[20] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[21] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.
[22] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[23] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001.
[24] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[25] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
Haukka, "Security Mechanism Agreement for the Session
Initiation Protocol (SIP)", RFC 3329, January 2003.
[26] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[27] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in
progress), October 2006.
[28] Audet, F. and C. Jennings, "NAT Behavioral Requirements for
Schulzrinne & Hancock Expires August 31, 2007 [Page 113]
Internet-Draft GIST February 2007
Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress),
October 2006.
[29] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004.
[30] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004.
[31] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
June 2005.
[32] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
Steps in Signaling (NSIS)", RFC 4081, June 2005.
[33] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[34] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for
Transport Layer Security (TLS)", RFC 4279, December 2005.
[35] Conta, A., Deering, S., and M. Gupta, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 4443, March 2006.
[36] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-13 (work in progress),
October 2006.
[37] Manner, J., "NSLP for Quality-of-Service Signaling",
draft-ietf-nsis-qos-nslp-12 (work in progress), October 2006.
[38] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", RFC 4213, October 2005.
[39] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[40] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005.
[41] Floyd, S. and V. Jacobson, "The Synchronisation of Periodic
Routing Messages", SIGCOMM Symposium on Communications
Architectures and Protocols pp. 33--44, September 1993.
[42] Pashalidis, A. and H. Tschofenig, "GIST Legacy NAT Traversal",
Schulzrinne & Hancock Expires August 31, 2007 [Page 114]
Internet-Draft GIST February 2007
draft-pashalidis-nsis-gist-legacynats-00 (work in progress),
July 2006.
[43] Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal",
draft-pashalidis-nsis-gimps-nattraversal-03 (work in progress),
June 2006.
[44] Tschofenig, H., "GIST State Machine",
draft-ietf-nsis-ntlp-statemachine-02 (work in progress),
June 2006.
[45] Ramaiah, A., "Improving TCP's Robustness to Blind In-Window
Attacks", draft-ietf-tcpm-tcpsecure-07 (work in progress),
February 2007.
Schulzrinne & Hancock Expires August 31, 2007 [Page 115]
Internet-Draft GIST February 2007
Appendix A. Bit-Level Formats and Error Messages
This appendix provides formats for the various component parts of the
GIST messages defined abstractly in Section 5.2. The whole of this
appendix is normative.
Each GIST message consists of a header and a sequence of objects.
The GIST header has a specific format, described in more detail in
Appendix A.1 below. An NSLP message is one object within a GIST
message. Note that GIST itself provides the NSLP message length
information and signalling application identification. General
object formatting guidelines are provided in Appendix A.2 below,
followed in Appendix A.3 by the format for each object. Finally,
Appendix A.4 provides the formats used for error reporting.
In the following object diagrams, '//' is used to indicate a variable
sized field and ':' is used to indicate a field that is optionally
present.
A.1. The GIST Common Header
This header begins all GIST messages. It has a fixed format, as
shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | GIST hops | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSLPID | Type |S|R|E| Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (8 bits): The GIST protocol version number.
GIST hops (8 bits): A hop count for the number of GIST-aware nodes
this message can still be processed by (including the
destination).
Message Length (16 bits): The total number of 32-bit words in the
message after the common header itself.
NSLPID (16 bits): IANA assigned identifier of the signalling
application the message refers to.
Type (8 bits): The GIST message type (Query, Response, etc.).
Schulzrinne & Hancock Expires August 31, 2007 [Page 116]
Internet-Draft GIST February 2007
S flag: S=1 if the IP source address is the same as the signalling
source address, S=0 if it is different.
R flag: R=1 if a reply to this message is explicitly requested.
E flag: E=1 if the message was explicitly routed (Section 7.1.5).
The rules governing the use of the R-flag depend on the GIST message
type. It MUST always be set (R=1) in Query messages, since these
always elicit a Response, and never in Confirm, Data or Error
messages. It MAY be set in an MA-Hello; if set, another MA-Hello
MUST be sent in reply. It MAY be set in a Response, but MUST be set
if the Response contains a Responder cookie; if set, a Confirm MUST
be sent in reply. The E flag MUST NOT be set unless the message type
is a Data message.
Parsing failures may be caused by unknown Version or Type values,
inconsistent R or E flag setting, or a Message Length inconsistent
with the set of objects carried. In all cases the receiver MUST if
possible return a "Common Header Parse Error" message
(Appendix A.4.4.1) with the appropriate subcode, and not process the
message further.
A.2. General Object Format
Each object begins with a fixed header giving the object Type and
object Length. This is followed by the object Value, which is a
whole number of 32-bit words long.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A/B flags: The bits marked 'A' and 'B' are extensibility flags which
are defined in Appendix A.2.1 below; the remaining bits marked 'r'
are reserved.
Type (12 bits): An IANA-assigned identifier for the type of object.
Length (12 bits): Length has the units of 32-bit words, and measures
the length of Value. If there is no Value, Length=0. If the
Length is not consistent with the contents of the object, an
"Object Value Error" message (Appendix A.4.4.10) with subcode 0
"Incorrect Length" MUST be returned and the message dropped.
Schulzrinne & Hancock Expires August 31, 2007 [Page 117]
Internet-Draft GIST February 2007
Value (variable): Value is (therefore) a whole number of 32 bit
words. If there is any padding required, the length and location
are be defined by the object-specific format information; objects
which contain variable length (e.g. string) types may need to
include additional length subfields to do so.
Any part of the object used for padding or defined as reserved
(marked 'Reserved' or 'Rsv' or, in the case of individual bits, 'r'
in the diagrams below) MUST be set to 0 on transmission and MUST be
ignored on reception.
A.2.1. Object Extensibility
The leading two bits of the TLV header are used to signal the desired
treatment for objects whose Type field is unknown at the receiver.
The following three categories of object have been identified, and
are described here.
AB=00 ("Mandatory"): If the object is not understood, the entire
message containing it MUST be rejected with an "Object Type Error"
message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object").
AB=01 ("Ignore"): If the object is not understood, it MUST be
deleted and the rest of the message processed as usual.
AB=10 ("Forward"): If the object is not understood, it MUST be
retained unchanged in any message forwarded as a result of message
processing, but not stored locally.
The combination AB=11 is reserved. If a message is received
containing an object with AB=11, it MUST be rejected with an "Object
Type Error" message (Appendix A.4.4.9) with subcode 5 ("Invalid
Extensibility Flags").
These extensibility rules define only the processing within the GIST
layer. There is no requirement on GIST implementations to support an
extensible service interface to signalling applications, so
unrecognised objects with AB=01 or AB=10 do not need to be indicated
to NSLPs. If a new GIST object is defined which requires such an
interaction, it should be specified with AB=11.
A.3. GIST TLV Objects
A.3.1. Message-Routing-Information
Schulzrinne & Hancock Expires August 31, 2007 [Page 118]
Internet-Draft GIST February 2007
Type: Message-Routing-Information
Length: Variable (depends on MRM)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRM-ID |N| Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
// Method-specific addressing information (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MRM-ID (8 bits): An IANA-assigned identifier for the message routing
method.
N flag: If set (N=1), this means that NATs do not need to translate
this MRM; if clear (N=0) it means that the method-specific
information contains network or transport layer information that a
NAT must process.
The remainder of the object contains method-specific addressing
information, which is described below.
A.3.1.1. Path-Coupled MRM
In the case of basic path-coupled routing, the addressing information
takes the following format. The N-flag N=0 for this MRM.
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-Ver |P|T|F|S|A|B|D|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Source Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Destination Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Prefix | Dest Prefix | Protocol | DS-field |Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Reserved | Flow Label :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SPI :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Source Port : Destination Port :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Schulzrinne & Hancock Expires August 31, 2007 [Page 119]
Internet-Draft GIST February 2007
IP-Ver (4 bits): The IP version number, 4 or 6.
Source/Destination address (variable): The source and destination
addresses are always present and of the same type; their length
depends on the value in the IP-Ver field.
Source/Dest Prefix (each 8 bits): The length of the mask to be
applied to the source and destination addresses for address
wildcarding. In the normal case where the MRI refers only to
traffic between specific host addresses, the Source/Dest Prefix
values would both be 32/128 for IPv4/6 respectively.
P flag: P=1 means that the Protocol field is significant.
Protocol (8 bits): The IP protocol number. This MUST be ignored if
P=0. In the case of IPv6, the Protocol field refers to the true
upper layer protocol carried by the packets, i.e. excluding any IP
option headers. This is therefore not necessarily the same as the
Next Header value from the base IPv6 header.
T flag: T=1 means that DiffServ field (DS-field) is significant.
DS-field (6 bits): The DiffServ field. See [7] and [24].
F flag: F=1 means that flow label is present and is significant. F
MUST NOT be set if IP-Ver is not 6.
Flow Label (20 bits): The flow label; only present if F=1. If F=0,
the entire 32 bit word containing the Flow Label is absent.
S flag: S=1 means that the SPI field is present and is significant.
The S flag MUST be 0 if the P flag is 0.
SPI field (32 bits): The SPI field; see [39]. If S=0, the entire 32
bit word containing the SPI is absent.
A/B flags: These can only be set if P=1. If either is set, the port
fields are also present. If P=0, the A/B flags MUST both be zero
and the word containing the port numbers is absent.
Source/Destination Port (each 16 bits): If either of A (source), B
(destination) is set the word containing the port numbers is
included in the object. However, the contents of each field is
only significant if the corresponding flag is set; otherwise, the
contents of the field is regarded as padding, and the MRI refers
to all ports (i.e. acts as a wildcard). If the flag is set and
Port=0x0000, the MRI will apply to a specific port, whose value is
not yet known. If neither of A or B is set, the word is absent.
Schulzrinne & Hancock Expires August 31, 2007 [Page 120]
Internet-Draft GIST February 2007
D flag: The Direction flag has the following meaning: the value 0
means 'in the same direction as the flow' (i.e. downstream), and
the value 1 means 'in the opposite direction to the flow' (i.e.
upstream).
The MRI format defines a number of constraints on the allowed
combinations of flags and fields in the object. If these constraints
are violated this constitutes a parse error, and an "Object Value
Error" message (Appendix A.4.4.10) with subcode 2 ("Invalid Flag-
Field Combination") MUST be returned.
A.3.1.2. Loose-End MRM
In the case of the loose-end MRM, the addressing information takes
the following format. The N-flag N=0 for this MRM.
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-Ver |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Source Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Destination Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Ver (4 bits): The IP version number, 4 or 6.
Source/Destination address (variable): The source and destination
addresses are always present and of the same type; their length
depends on the value in the IP-Ver field.
D flag: The Direction flag has the following meaning: the value 0
means 'towards the edge of the network', and the value 1 means
'from the edge of the network'. Note that for Q-mode messages,
the only valid value is D=0 (see Section 5.8.2).
A.3.2. Session Identification
Type: Session-Identification
Length: Fixed (4 32-bit words)
Schulzrinne & Hancock Expires August 31, 2007 [Page 121]
Internet-Draft GIST February 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.3.3. Network-Layer-Information
Type: Network-Layer-Information
Length: Variable (depends on length of Peer-Identity and IP version)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PI-Length | IP-TTL |IP-Ver | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing State Validity Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer Identity //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Interface Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PI-Length (8 bits): The byte length of the Peer Identity field.
Peer Identity (variable): The Peer Identity field. Note that the
Peer-Identity field itself is padded to a whole number of words.
IP-TTL (8 bits): Initial or reported IP layer TTL.
IP-Ver (4 bits): The IP version for the Interface Address field.
Interface Address (variable): The IP address allocated to the
interface, matching the IP-Ver field.
Routing State Validity Time (32 bits): The time for which the
routing state for this flow can be considered correct without a
refresh. Given in milliseconds. The value 0 (zero) is reserved
and MUST NOT be used.
Schulzrinne & Hancock Expires August 31, 2007 [Page 122]
Internet-Draft GIST February 2007
A.3.4. Stack Proposal
Type: Stack-Proposal
Length: Variable (depends on number of profiles and size of each
profile)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prof-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile 2 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prof-Count (8 bits): The number of profiles listed. MUST be > 0.
Each profile is itself a sequence of protocol layers, and the profile
is formatted as a list as follows:
o The first byte is a count of the number of layers in the profile.
MUST be > 0.
o This is followed by a sequence of 1-byte MA-Protocol-IDs as
described in Section 5.7.
o The profile is padded to a word boundary with 0, 1, 2 or 3 zero
bytes. These bytes MUST be ignored at the receiver.
If there are no profiles (Prof-Count=0) then an "Object Value Error"
message (Appendix A.4.4.10) with subcode 1 ("Value Not Supported")
MUST be returned; if a particular profile is empty (the leading byte
of the profile is zero), then subcode 3 ("Empty List") MUST be used.
In both cases, the message MUST be dropped.
A.3.5. Stack-Configuration-Data
Type: Stack-Configuration-Data
Length: Variable (depends on number of protocols and size of each
MA-protocol-options field)
Schulzrinne & Hancock Expires August 31, 2007 [Page 123]
Internet-Draft GIST February 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPO-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MA-Hold-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// MA-protocol-options 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// MA-protocol-options N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPO-Count (8 bits): The number of MA-protocol-options fields present
(these contain their own length information). The MPO-Count MAY
be zero, but this will only be the case if none of the MA-
protocols referred to in the Stack-Proposal require option data.
MA-Hold-Time (32 bits): The time for which the messaging association
will be held open without traffic or a hello message. Note that
this value is given in milliseconds, so the default time of 30
seconds (Section 4.4.5) corresponds to a value of 30000. The
value 0 (zero) is reserved and MUST NOT be used.
The MA-protocol-options fields are formatted as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MA-Protocol-ID | Profile | Length |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Options Data //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MA-Protocol-ID (8 bits): Protocol identifier as described in
Section 5.7.
Profile (8 bits): Tag indicating which profile from the accompanying
Stack-Proposal object this applies to. Profiles are numbered from
1 upwards; the special value 0 indicates 'applies to all
profiles'.
Length (8 bits): The byte length of MA-protocol-options field that
follows. This will be zero-padded up to the next word boundary.
Schulzrinne & Hancock Expires August 31, 2007 [Page 124]
Internet-Draft GIST February 2007
D flag: If set (D=1), this protocol MUST NOT be used for a messaging
association.
Options Data (variable): Any options data for this protocol. Note
that the format of the options data might differ depending on
whether the field is in a Query or Response.
A.3.6. Query Cookie
Type: Query-Cookie
Length: Variable (selected by querying node)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Query Cookie //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents are implementation defined. See Section 8.5 for further
discussion.
A.3.7. Responder Cookie
Type: Responder-Cookie
Length: Variable (selected by responding node)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Responder Cookie //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents are implementation defined. See Section 8.5 for further
discussion.
A.3.8. Hello-ID
Type: Hello-ID
Length: Fixed (1 32-bit word)
Schulzrinne & Hancock Expires August 31, 2007 [Page 125]
Internet-Draft GIST February 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hello-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents are implementation defined. See Section 5.2.2 for
further discussion.
A.3.9. NAT Traversal
Type: NAT-Traversal
Length: Variable (depends on length of contained fields)
This object is used to support the NAT traversal mechanisms described
in Section 7.2.2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRI-Length | Type-Count | NAT-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Original Message-Routing-Information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// List of translated objects //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of opaque information | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ //
// Information replaced by NAT #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of opaque information | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ //
// Information replaced by NAT #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MRI-Length (8 bits): The length of the included MRI payload in 32-
bit words.
Original Message-Routing-Information (variable): The MRI data from
when the message was first sent, not including the object header.
Type-Count (8 bits): The number of objects in the 'List of
translated objects' field.
Schulzrinne & Hancock Expires August 31, 2007 [Page 126]
Internet-Draft GIST February 2007
List of translated objects (variable): This field lists the types of
the objects that were translated by every NAT through which the
message has passed. Each element in the list is a 16-bit field
containing the first 16 bits of the object TLV header, including
the AB extensibility flags, two reserved bits, and 12 bit object
type. The list is initialised by the first NAT on the path;
subsequent NATs may delete elements in the list. Padded with 2
null bytes if necessary.
NAT-Count (8 bits): The number of NATs traversed by the message, and
the number of opaque payloads at the end of the object. The
length fields for each opaque payload are byte counts, not
including the 2 bytes of the length field itself. Note that each
opaque information field is zero-padded to the next 32-bit word
boundary if necessary.
A.3.10. NSLP Data
Type: NSLP-Data
Length: Variable (depends on NSLP)
This object is used to deliver data between NSLPs. GIST regards the
data as a number of complete 32-bit words, as given by the length
field in the TLV; any padding to a word boundary must be carried out
within the NSLP itself.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NSLP Data //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.4. Errors
A.4.1. Error Object
Type: Error
Length: Variable (depends on error)
Schulzrinne & Hancock Expires August 31, 2007 [Page 127]
Internet-Draft GIST February 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Class | Error Code | Error Subcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|M|C|D|Q| Reserved | MRI Length | Info Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Common Header +
| (of original message) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Session Id :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Message Routing Information :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Additional Information Fields :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Debugging Comment :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The flags are:
S - S=1 means the Session ID object is present
M - M=1 means MRI object is present
C - C=1 means a debug Comment is present after header.
D - D=1 means the original message was received in D-mode
Q - Q=1 means the original message was received Q-mode encapsulated
(can't be set if D=0).
A GIST Error object contains an 8 bit error-class (see
Appendix A.4.3), a 16 bit error-code, an 8 bit error-subcode, and as
much information about the message which triggered the error as is
available. This information MUST include the Common header of the
original message and MUST also include the Session Id and MRI objects
if these could be decoded correctly. These objects are included in
their entirety, except for their TLV Headers. The MRI Length field
gives the length of the MRI object in 32-bit words.
The Info Count field contains the number of Additional Information
fields in the object, and the possible formats for these fields are
given in Appendix A.4.2. The precise set of fields to include
depends on the error code/subcode. For every error description in
the error catalogue Appendix A.4.4, the line "Additional Info:"
states what fields MUST be included; further fields beyond these MAY
be included by the sender, and the fields may be included in any
order. The Debugging Comment is a null- terminated UTF-8 string,
padded if necessary to a whole number of 32- bit words with more null
characters.
Schulzrinne & Hancock Expires August 31, 2007 [Page 128]
Internet-Draft GIST February 2007
A.4.2. Additional Information Fields
The Common Error Header may be followed by some Additional
Information fields. Each Additional Information field has a simple
TLV format as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AI-Type | AI-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// AI-Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AI-Type is a 16-bit IANA assigned value. The AI-Length gives the
number of 32-bit words in AI-Value; if an AI-Value is not present,
AI-Length=0. The AI-Types and AI-Lengths and AI-Value formats of the
currently defined Additional Information fields are shown below.
Message Length Info:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calculated Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AI-Type: 1
AI-Length: 1
Calculated Length (16 bits): the length of the original message
calculated by adding up all the objects in the message. Measured in
32-bit words.
MTU Info:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link MTU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AI-Type: 2
AI-Length: 1
Link MTU (16 bits): the IP MTU for a link along which a message
could not be sent. Measured in bytes.
Object Type Info:
Schulzrinne & Hancock Expires August 31, 2007 [Page 129]
Internet-Draft GIST February 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AI-Type: 3
AI-Length: 1
Object type (16 bits): This provides information about the type
of object which caused the error.
Object Value Info:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv | Real Object Length | Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Object //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AI-Type: 4
AI-Length: variable (depends on Object length)
This object carries information about a TLV object which was found
to be invalid in the original message. An error message MAY contain
more than one Object Value Info object.
Real Object Length (12 bits) Since the length in the original TLV
header may be inaccurate, this field provides the actual length of
the object (including the TLV Header) included in the error
message. Measured in 32-bit words.
Offset (16 bits): The byte in the object at which the GIST node
found the error. The first byte in the object has offset=0.
Object (variable): The invalid TLV object (including the TLV
Header).
A.4.3. Error Classes
The first byte of the error object, "Error Class", indicates the
severity level. The currently defined severity levels are:
0 (Informational): reply data which should not be thought of as
changing the condition of the protocol state machine.
1 (Success): reply data which indicates that the message being
responded to has been processed successfully in some sense.
Schulzrinne & Hancock Expires August 31, 2007 [Page 130]
Internet-Draft GIST February 2007
2 (Protocol-Error): the message has been rejected because of a
protocol error (e.g. an error in message format).
3 (Transient-Failure): the message has been rejected because of a
particular local node status which may be transient (i.e. it may
be worthwhile to retry after some delay).
4 (Permanent-Failure): the message has been rejected because of
local node status which will not change without additional out of
band (e.g. management) operations.
Additional error class values are reserved.
The allocation of error classes to particular errors is not precise;
the above descriptions are deliberately informal. Actual error
processing SHOULD take into account the specific error in question;
the error class may be useful supporting information (e.g. in network
debugging).
A.4.4. Error Catalogue
This section lists all the possible GIST errors, including when they
are raised and what additional information fields MUST be carried in
the error object.
A.4.4.1. Common Header Parse Error
Class: Protocol-Error
Code: 1
Additional Info: For subcode 3 only, Message Length Info carries
the calculated message length.
This message is sent if a GIST node receives a message where the
common header cannot be parsed correctly, or where an error in the
overall message format is detected. Note that in this case the
original MRI and Session ID MUST NOT be included in the Error Object.
This error code is split into subcodes as follows:
0: Unknown Version: The GIST version is unknown. The (highest)
supported version supported by the node can be inferred from the
Common Header of the Error message itself.
1: Unknown Type: The GIST message type is unknown.
2: Invalid R-flag: The R flag in the header is inconsistent with the
message type.
Schulzrinne & Hancock Expires August 31, 2007 [Page 131]
Internet-Draft GIST February 2007
3: Incorrect Message Length: The overall message length is not
consistent with the set of objects carried.
4: Invalid E-flag: The E flag is set in the header but this is not a
Data message.
A.4.4.2. Hop Limit Exceeded
Class: Permanent-Failure
Code: 2
Additional Info: None
This message is sent if a GIST node receives a message with a GIST
hop count of zero, or a GIST node tries to forward a message after
its GIST hop count has been decremented to zero on reception. This
message indicates either a routing loop or too small an initial hop
count value.
A.4.4.3. Incorrect Encapsulation
Class: Protocol-Error
Code: 3
Additional Info: None
This message is sent if a GIST node receives a message which uses an
incorrect encapsulation method (e.g. a Query arrives over an MA).
A.4.4.4. Incorrectly Delivered Message
Class: Protocol-Error
Code: 4
Additional Info: None
This message is sent if a GIST node receives a message over an MA
which is not associated with the MRI/NSLPID/SID combination in the
message.
A.4.4.5. No Routing State
Class: Protocol-Error
Code: 5
Additional Info: None
This message is sent if a node receives a message for which routing
state should exist, but has not yet been created and thus there is no
appropriate Querying-SM or Responding-SM. This can occur on
receiving a Data or Confirm message at a node whose policy requires
routing state to exist before such messages can be accepted. See
Schulzrinne & Hancock Expires August 31, 2007 [Page 132]
Internet-Draft GIST February 2007
also Section 6.1 and Section 6.3.
A.4.4.6. Unknown NSLPID
Class: Permanent-Failure
Code: 6
Additional Info: None
This message is sent if a router receives a directly addressed
message for an NSLP which it does not support.
A.4.4.7. Endpoint Found
Class: Permanent-Failure
Code: 7
Additional Info: None
This message is sent if a GIST node at a flow endpoint receives a
Query message for an NSLP which it does not support.
A.4.4.8. Message Too Large
Class: Permanent-Failure
Code: 8
Additional Info: MTU Info
A router receives a message which it can't forward because it exceeds
the IP MTU on the next or subsequent hops.
A.4.4.9. Object Type Error
Class: Protocol-Error
Code: 9
Additional Info: Object Type Info
This message is sent if a GIST node receives a message containing a
TLV object with an invalid type. The message indicates the object
type at fault in the additional info field. This error code is split
into subcodes as follows:
0: Duplicate Object: This subcode is used if a GIST node receives a
message containing multiple instances of an object which may only
appear once in a message. In the current specification, this
applies to all objects.
Schulzrinne & Hancock Expires August 31, 2007 [Page 133]
Internet-Draft GIST February 2007
1: Unrecognised Object: This subcode is used if a GIST node receives
a message containing an object which it does not support, and the
extensibility flags AB=00.
2: Missing Object: This subcode is used if a GIST node receives a
message which is missing one or more mandatory objects. This
message is also sent if a Stack-Proposal is sent without a
matching Stack-Configuration-Data object when one was necessary,
or vice versa.
3: Invalid Object Type: This subcode is used if the object type is
known, but it is not valid for this particular GIST message type.
4: Untranslated Object: This subcode is used if the object type is
known and is mandatory to interpret, but it contains addressing
data which has not been translated by an intervening NAT.
5: Invalid Extensibility Flags: This subcode is used if an object is
received with the extensibility flags AB=11.
A.4.4.10. Object Value Error
Class: Protocol-Error
Code: 10
Additional Info: 1 or 2 Object Value Info fields as given below
This message is sent if a node receives a message containing an
object which cannot be properly parsed. The error message contains a
single Object Value Info object, except for subcode 5 as stated
below. This error code is split into subcodes as follows:
0: Incorrect Length: The overall length does not match the object
length calculated from the object contents.
1: Value Not Supported: The value of a field is not supported by the
GIST node.
2: Invalid Flag-Field Combination: An object contains an invalid
combination of flags and/or fields. At the moment this only
relates to the Path-Coupled MRI (Appendix A.3.1.1), but in future
there may be more.
3: Empty List: At the moment this only relates to Stack-Proposals.
The error message is sent if a stack proposal with a length > 0
contains only null bytes (a length of 0 is handled as "Value Not
Supported").
Schulzrinne & Hancock Expires August 31, 2007 [Page 134]
Internet-Draft GIST February 2007
4: Invalid Cookie: The message contains a cookie which could not be
verified by the node.
5: Stack-Proposal - Stack-Configuration-Data Mismatch: This subcode
is used if a GIST node receives a message in which the data in the
Stack-Proposal object is inconsistent with the information in the
Stack Configuration Data object. In this case, both the Stack-
Proposal object and Stack-Configuration-Data object MUST be
included in separate Object Value Info fields in that order.
A.4.4.11. Invalid IP layer TTL
Class: Permanent-Failure
Code: 11
Additional Info: None
This error indicates that a message was received with an IP layer TTL
outside an acceptable range; for example, that an upstream Query was
received with an IP layer TTL of less than 254 (i.e. more than one IP
hop from the sender). The actual IP distance can be derived from the
IP-TTL information in the NLI object carried in the same message.
A.4.4.12. MRI Validation Failure
Class: Permanent-Failure
Code: 12
Additional Info: Object Value Info
This error indicates that a message was received with an MRI that
could not be accepted, e.g. because of too much wildcarding or
failing some validation check (cf. Section 5.8.1.2). The Object
Value Info includes the MRI so the error originator can indicate the
part of the MRI which caused the problem. The error code is divided
into subcodes as follows:
0: MRI Too Wild: The MRI contained too much wildcarding (e.g. too
short a destination address prefix) to be forwarded correctly down
a single path.
1: IP Version Mismatch: The MRI in a path-coupled Query message
refers to an IP version which is not implemented on the interface
used, or is different from the IP version of the Query
encapsulation (see Section 7.4).
2: Ingress Filter Failure: The MRI in a path-coupled Query message
describes a flow which would not pass ingress filtering on the
interface used.
Schulzrinne & Hancock Expires August 31, 2007 [Page 135]
Internet-Draft GIST February 2007
Appendix B. API between GIST and Signalling Applications
This appendix provides an abstract API between GIST and signalling
applications. It should not constrain implementers, but rather help
clarify the interface between the different layers of the NSIS
protocol suite. In addition, although some of the data types carry
the information from GIST information elements, this does not imply
that the format of that data as sent over the API has to be the same.
Conceptually the API has similarities to the sockets API,
particularly that for unconnected UDP sockets. An extension for an
API like that for UDP connected sockets could be considered. In this
case, for example, the only information needed in a SendMessage
primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle
(which can be null). Other information which was persistent for a
group of messages could be configured once for the socket. Such
extensions may make a concrete implementation more efficient but do
not change the API semantics, and so are not considered further here.
B.1. SendMessage
This primitive is passed from a signalling application to GIST. It
is used whenever the signalling application wants to initiate sending
a message.
SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle,
NSLPID, Session-ID, MRI, SII-Handle,
Transfer-Attributes, Timeout, IP-TTL, GIST-Hop-Count )
The following arguments are mandatory.
NSLP-Data: The NSLP message itself.
NSLP-Data-Size: The length of NSLP-Data.
NSLP-Message-Handle: A handle for this message, that can be used by
GIST as a reference in subsequent MessageStatus notifications
(Appendix B.3). Notifications could be about error conditions or
about the security attributes that will be used for the message.
A NULL handle may be supplied if the NSLP is not interested in
such notifications.
NSLPID: An identifier indicating which NSLP this is.
Session-ID: The NSIS session identifier. Note that it is assumed
that the signalling application provides this to GIST rather than
GIST providing a value itself.
Schulzrinne & Hancock Expires August 31, 2007 [Page 136]
Internet-Draft GIST February 2007
MRI: Message routing information for use by GIST in determining the
correct next GIST hop for this message. The MRI implies the
message routing method to be used and the message direction.
The following arguments are optional:
SII-Handle: A handle, previously supplied by GIST, to a data
structure that should be used to route the message explicitly to a
particular GIST next hop.
Transfer-Attributes: Attributes defining how the message should be
handled (see Section 4.1.2). The following attributes can be
considered:
Reliability: Values 'unreliable' or 'reliable'.
Security: This attribute allows the NSLP to specify what level of
security protection is requested for the message (such as
'integrity' or 'confidentiality'), and can also be used to
specify what authenticated signalling source and destination
identities should be used to send the message. The
possibilities can be learned by the signalling application from
prior MessageStatus or RecvMessage notifications. If an NSLP-
Message-Handle is provided, GIST will inform the signalling
application of what values it has actually chosen for this
attribute via a MessageStatus callback. This might take place
either synchronously (where GIST is selecting from available
messaging associations), or asynchronously (when a new
messaging association needs to be created).
Local Processing: This attribute contains hints from the
signalling application about what local policy should be
applied to the message; in particular, its transmission
priority relative to other messages, or whether GIST should
attempt to set up or maintain forward routing state.
Timeout: Length of time GIST should attempt to send this message
before indicating an error.
IP-TTL: The value of the IP layer TTL that should be used when
sending this message (may be overridden by GIST for particular
messages).
GIST-Hop-Count: The value for the hop count when sending the
message.
Schulzrinne & Hancock Expires August 31, 2007 [Page 137]
Internet-Draft GIST February 2007
B.2. RecvMessage
This primitive is passed from GIST to a signalling application. It
is used whenever GIST receives a message from the network, including
the case of null messages (zero length NSLP payload), typically
initial Query messages. For Queries, the results of invoking this
primitive are used by GIST to check whether message routing state
should be created (see the discussion of the 'Routing-State-Check'
argument below).
RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLPID, Session-ID, MRI,
Routing-State-Check, SII-Handle, Transfer-Attributes,
IP-TTL, IP-Distance, GIST-Hop-Count,
Inbound-Interface )
NSLP-Data: The NSLP message itself (may be empty).
NSLP-Data-Size: The length of NSLP-Data (may be zero).
NSLPID: An identifier indicating which NSLP this is message is for.
Session-ID: The NSIS session identifier.
MRI: Message routing information that was used by GIST in forwarding
this message. Implicitly defines the message routing method that
was used and the direction of the message relative to the MRI.
Routing-State-Check: This boolean is True if GIST is checking with
the signalling application to see if routing state should be
created with the peer or the message should be forwarded further
(see Section 4.3.2). If True, the signalling application should
return the following values via the RecvMessage call:
A boolean indicating whether to set up the state.
Optionally, an NSLP-Payload to carry in the generated Response
or forwarded Query respectively.
This mechanism could be extended to enable the signalling
application to indicate to GIST whether state installation should
be immediate or deferred (see Section 5.3.3 and Section 6.3 for
further discussion).
SII-Handle: A handle to a data structure, identifying a peer address
and interface. Can be used to identify route changes and for
explicit routing to a particular GIST next hop.
Schulzrinne & Hancock Expires August 31, 2007 [Page 138]
Internet-Draft GIST February 2007
Transfer-Attributes: The reliability and security attributes that
were associated with the reception of this particular message. As
well as the attributes associated with SendMessage, GIST may
indicate the level of verification of the addresses in the MRI.
Three attributes can be indicated:
* Whether the signalling source address is one of the flow
endpoints (i.e. whether this is the first or last GIST hop);
* Whether the signalling source address has been validated by a
return routability check.
* Whether the message was explicitly routed (and so has not been
validated by GIST as delivered consistently with local routing
state).
IP-TTL: The value of the IP layer TTL this message was received with
(if available).
IP-Distance: The number of IP hops from the peer signalling node
which sent this message along the path, or 0 if this information
is not available.
GIST-Hop-Count: The value of the hop count the message was received
with, after being decremented in the GIST receive-side processing.
Inbound-Interface: Attributes of the interface on which the message
was received, such as whether it lies on the internal or external
side of a NAT. These attributes have only local significance and
are implementation defined.
B.3. MessageStatus
This primitive is passed from GIST to a signalling application. It
is used to notify the signalling application that a message that it
requested to be sent could not be dispatched, or to inform the
signalling application about the transfer attributes that have been
selected for the message (specifically, security attributes). The
signalling application can respond to this message with a return code
to abort the sending of the message if the attributes are not
acceptable.
MessageStatus (NSLP-Message-Handle, Transfer-Attributes, Error-Type)
Schulzrinne & Hancock Expires August 31, 2007 [Page 139]
Internet-Draft GIST February 2007
NSLP-Message-Handle: A handle for the message provided by the
signalling application in SendMessage.
Transfer-Attributes: The reliability and security attributes that
will be used to transmit this particular message.
Error-Type: Indicates the type of error that occurred. For example,
'no next node found'.
B.4. NetworkNotification
This primitive is passed from GIST to a signalling application. It
indicates that a network event of possible interest to the signalling
application occurred.
NetworkNotification ( NSLPID, MRI, Network-Notification-Type )
NSLPID: An identifier indicating which NSLP this is message is for.
MRI: Provides the message routing information to which the network
notification applies.
Network-Notification-Type: Indicates the type of event that caused
the notification and associated additional data. Five events have
been identified:
Last Node: GIST has detected that this is the last NSLP-aware
node in the path. See Section 4.3.4.
Routing Status Change: GIST has installed new routing state, has
detected that existing routing state may no longer be valid, or
has re-established existing routing state. See Section 7.1.3.
The new status is reported; if the status is Good, the SII-
Handle of the peer is also reported, as for RecvMessage.
Route Deletion: GIST has determined that an old route is now
definitely invalid, e.g. that flows are definitely not using it
(see Section 7.1.4). The SII-Handle of the peer is also
reported.
Node Authorisation Change: The authorisation status of a peer has
changed, meaning that routing state is no longer valid or that
a signalling peer is no longer reachable; see Section 4.4.2.
Communication Failure: Communication with the peer has failed;
messages may have been lost.
Schulzrinne & Hancock Expires August 31, 2007 [Page 140]
Internet-Draft GIST February 2007
B.5. SetStateLifetime
This primitive is passed from a signalling application to GIST. It
indicates the duration for which the signalling application would
like GIST to retain its routing state. It can also give a hint that
the signalling application is no longer interested in the state.
SetStateLifetime ( NSLPID, MRI, SID, State-Lifetime )
NSLPID: Provides the NSLPID to which the routing state lifetime
applies.
MRI: Provides the message routing information to which the routing
state lifetime applies; includes the direction (in the D flag).
SID: The session ID which the signalling application will be using
with this routing state. Can be wildcarded.
State-Lifetime: Indicates the lifetime for which the signalling
application wishes GIST to retain its routing state (may be zero,
indicating that the signalling application has no further interest
in the GIST state).
B.6. InvalidateRoutingState
This primitive is passed from a signalling application to GIST. It
indicates that the signalling application has knowledge that the next
signalling hop known to GIST may no longer be valid, either because
of changes in the network routing or the processing capabilities of
signalling application nodes. See Section 7.1.
InvalidateRoutingState ( NSLPID, MRI, Status, Urgent )
NSLPID: The NSLP originating the message. May be null (in which
case the invalidation applies to all signalling applications).
MRI: The flow for which routing state should be invalidated;
includes the direction of the change (in the D flag).
Status: The new status that should be assumed for the routing state,
one of Bad or Tentative (see Section 7.1.3).
Urgent: A hint as to whether rediscovery should take place
immediately, or only with the next signalling message.
Schulzrinne & Hancock Expires August 31, 2007 [Page 141]
Internet-Draft GIST February 2007
Appendix C. Deployment Issues with Router Alert Options
The GIST peer discovery handshake (Section 4.4.1) depends on the
interception of Q-mode encapsulated IP packets (Section 4.3.1 and
Section 5.3.2) by routers. There are two fundamental requirements on
the process:
1. Packets relevant to GIST must be intercepted.
2. Packets not relevant to GIST must be forwarded transparently.
This specification defines the GIST behaviour to ensure that both
requirements are met for a GIST-capable node. However, GIST packets
will also encounter non-GIST nodes, for which requirement (2) still
applies. If non-GIST nodes block Q-mode packets, GIST will not
function. It is always possible for middleboxes to block specific
traffic types; by using a normal encapsulation for Q-mode traffic at
the UDP level, GIST allows NATs at least to pass these messages
(Section 7.2.1), and firewalls can be configured with standard
policies. However, where the Q-mode encapsulation uses a Router
Alert Option (RAO) at the IP level this can lead to additional
problems. The situation is different for IPv4 and IPv6.
The IPv4 RAO is defined by [3], which defines the RAO format with a
2-byte value field; however, only one value (zero) is defined and
there is no IANA registry for further allocations. It states that
unknown values should be ignored (i.e. the packets forwarded as
normal IP traffic); however, it has also been reported that some
existing implementations simply ignore the RAO value completely (i.e.
process any packet with an RAO as though the option value was zero).
Therefore, the use of non-zero RAO values cannot be relied on to make
GIST traffic transparent to existing implementations. (Note that it
may still be valuable to be able to allocate non-zero RAO values for
IPv4: this makes the interception process more efficient for nodes
which do examine the value field, and makes no difference to nodes
which - incorrectly - ignore it. Whether or not non-zero RAO values
are used does not change the GIST protocol operation, but needs to be
decided when new NSLPs are registered.)
The second stage of the analysis is therefore what happens when a
non-GIST node which implements RAO handling sees a Q-mode packet.
The RAO specification simply states that "Routers that recognize this
option shall examine packets carrying it more closely (check the IP
Protocol field, for example) to determine whether or not further
processing is necessary." There are two possible basic behaviours
for GIST traffic:
Schulzrinne & Hancock Expires August 31, 2007 [Page 142]
Internet-Draft GIST February 2007
1. The "closer examination" of the packet is sufficiently
intelligent to realise that the node does not need to process it
and should forward it. This could either be by virtue of the
fact that the node has not been configured to match IP-
Protocol=UDP for RAO packets at all, or that even if UDP traffic
is intercepted the port numbers do not match anything locally
configured.
2. The "closer examination" of the packet identifies it as UDP, and
delivers it to the UDP stack on the node. In this case, it can
no longer be guaranteed to be processed appropriately. Most
likely it will simply be dropped or rejected with an ICMP error
(because there is no GIST process on the destination port to
deliver it to).
Analysis of open-source operating system source code shows the first
type of behaviour, and this has also been seen in direct GIST
experiments with commercial routers, including the case when they
process other uses of the RAO (i.e. RSVP). However, it has also
been reported that other RAO implementations will exhibit the second
type of behaviour. The consequence of this would be that Q-mode
packets are blocked in the network and GIST could not be used. Note
that although this caused by some subtle details in the RAO
processing rules, the end result is the same as if the packet was
simply blocked for other reasons (for example, many IPv4 firewalls
drop packets with options by default).
The GIST specification allows two main options for circumventing
nodes which block Q-mode traffic in IPv4. Whether to use these
options is a matter of implementation and configuration choice.
o A GIST node can be configured to send Q-mode packets without the
RAO at all. This should avoid the above problems, but should only
be done if it is known that nodes on the path to the receiver are
able to intercept such packets. (See Section 5.3.2.1.)
o If a GIST node can identify exactly where the packets are being
blocked (e.g. from ICMP messages), or can discover some point on
the path beyond the blockage (e.g. by use of traceroute or by
routing table analysis), it can send the Q-mode messages to that
point using IP-in-IP tunelling without any RAO. This bypasses the
input side processing on the blocking node, but picks up normal
GIST behaviour beyond it.
If in the light of deployment experience the problem of blocked
Q-mode traffic turns out to be widespread and these techniques turn
out to be insufficient, a further possibility is to define an
alternative Q-mode encapsulation which does not use UDP. This would
Schulzrinne & Hancock Expires August 31, 2007 [Page 143]
Internet-Draft GIST February 2007
require a specification change. Such an option would be restricted
to network-internal use, since operation through NATs and firewalls
would be much harder with it.
The situation with IPv6 is rather different, since in that case the
use of non-zero RAO values is well established in the specification
([8]) and an IANA registry exists. The main problem is that several
implementations are still immature: for example, some treat any RAO-
marked packet as though it was for local processing without further
analysis. Since this prevents any RAO usage at all (including the
existing standardised ones) in such a network, it seems reasonable to
assume that such implementations will be fixed as part of the general
deployment of IPv6.
Schulzrinne & Hancock Expires August 31, 2007 [Page 144]
Internet-Draft GIST February 2007
Appendix D. Example Routing State Table and Handshake
Figure 9 shows a signalling scenario for a single flow being managed
by two signalling applications using the path-coupled message routing
method. The flow sender and receiver and one router support both,
two other routers support one each. The figure also shows the
routing state table at node B.
A B C D E
+------+ +-----+ +-----+ +-----+ +--------+
| Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow |
|Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver|
| | +-+ +-+ |GIST | |GIST | |GIST | | |
+------+ +-----+ +-----+ +-----+ +--------+
Flow Direction ------------------------------>>
+------------------------------------+---------+--------+-----------+
| Message Routing Information | Session | NSLPID | Routing |
| | ID | | State |
+------------------------------------+---------+--------+-----------+
| MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | IP-A |
| {IP-A, IP-E, proto/ports}; D=up | | | |
| | | | |
| MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | (null) |
| {IP-A, IP-E, proto/ports}; D=down | | | |
| | | | |
| MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | IP-A |
| {IP-A, IP-E, proto/ports}; D=up | | | |
| | | | |
| MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | Points to |
| {IP-A, IP-E, proto/ports}; D=down | | | B-D MA |
+------------------------------------+---------+--------+-----------+
Figure 9: A Signalling Scenario
The upstream state is just the same address for each application.
For the downstream direction, NSLP1 only requires D-mode messages and
so no explicit routing state towards C is needed. NSLP2 requires a
messaging association for its messages towards node D, and node C
does not process NSLP2 at all, so the peer state for NSLP2 is a
pointer to a messaging association that runs directly from B to D.
Note that E is not visible in the state table (except implicitly in
the address in the message routing information); routing state is
stored only for adjacent peers. (In addition to the peer
identification, IP hop counts are stored for each peer where the
state itself if not null; this is not shown in the table.)
Figure 10 shows a GIST handshake setting up a messaging association
Schulzrinne & Hancock Expires August 31, 2007 [Page 145]
Internet-Draft GIST February 2007
for B-D signalling, with the exchange of Stack Proposals and MA-
protocol-options in each direction. The Querying node selects TLS/
TCP as the stack configuration and sets up the messaging association
over which it sends the Confirm.
-------------------------- Query ---------------------------->
IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST)
Q-mode magic number (0x4e04 bda5)
GIST(Header(Type=Query; NSLPID=NSLP2; R=1; S=0)
MRI(MRM=Path-Coupled; Flow=F; Direction=down)
SessionID(0x1234) NLI(Peer='string1'; IA=IP#B)
QueryCookie(0x139471239471923526)
StackProposal(#Proposals=3;1=TLS/TCP; 2=TLS/SCTP; 3=TCP)
StackConfigurationData(HoldTime=300; #MPO=2;
TCP(Applicable: all; Data: null)
SCTP(Applicable: all; Data: null)))
<---------------------- Response ----------------------------
IP(Src=IP#D; Dst=IP#B); UDP(Src=GIST; Dst=6789)
GIST(Header(Type=Response; NSLPID=NSLP2; R=1; S=1)
MRI(MRM=Path-Coupled; Flow=F; Direction=up)
SessionID(0x1234) NLI(Peer='stringr2', IA=IP#D)
QueryCookie(0x139471239471923526)
ResponderCookie(0xacdefedcdfaeeeded)
StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)
StackConfigurationData(HoldTime=200; #MPO=3;
TCP(Applicable: 3; Data: port=6123)
TCP(Applicable: 1; Data: port=5438)
SCTP(Applicable: all; Data: port=3333)))
-------------------------TCP SYN----------------------->
<----------------------TCP SYN/ACK----------------------
-------------------------TCP ACK----------------------->
TCP connect(IP Src=IP#B; IP Dst=IP#D; Src Port=9166; Dst Port=6123)
<-----------------------TLS INIT----------------------->
------------------------ Confirm ---------------------------->
[Sent within messaging association]
GIST(Header(Type=Confirm; NSLPID=NSLP2; R=0; S=1)
MRI(MRM=Path-Coupled; Flow=F; Direction=down)
SessionID(0x1234) NLI(Peer='string1'; IA=IP#B)
ResponderCookie(0xacdefedcdfaeeeded)
StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)
StackConfigurationData(HoldTime=300))
Figure 10: GIST Handshake Message Sequence
Schulzrinne & Hancock Expires August 31, 2007 [Page 146]
Internet-Draft GIST February 2007
Appendix E. Change History
Note to the RFC Editor: this appendix to be removed before
publication as an RFC.
E.1. Changes in Version -12
The following changes were made in response to IESG review. The
changes have been classified into three categories: protocol changes
(things which would directly affect, technical clarifications, and
editorial issues. The name of the reviewer is included with each
change.
Protocol changes:
1. Modified the processing rules for the GIST hop count. An
initial check for GHC=0 followed by a decrement is now done on
the receive side (Section 4.3.1); the local processing
description in Section 4.3.2 now forces peering (preventing
bypass) if the GHC has reached zero. A check is added for a
valid NSLP-supplied GHC in Section 4.3.3, and this also includes
the old text from Section 4.3.4 on loop control in NSLPs by
preserving the GHC. Section 4.3.3 also includes guidance on how
to select an initial GHC (referring to IP TTL setting). A note
on not retrying if a loop was known to have been formed has been
removed, and it has been clarified that the mechanism does not
prevent looping per se, just infinite looping. [Adrian Farrel]
2. Changed the class of the "Endpoint Found" error
(Appendix A.4.4.7) to Permanent-Failure, to ensure that the
Querying state machine terminates when it occurs. [Adrian
Farrel]
3. Modified the MA-Hello message (Section 5.1, Section 5.2.2,
Appendix A.3.8) to include a Hello-ID object which allows the
correlation of request/response exchanges, and described the
corresponding processing - that failure to get a response can
trigger er_MAFailure - in Section 6.4. Note that the response
message must have R=0. [Adrian Farrel, Roland Bless]
4. Added a new section on Legacy NAT handling in Section 7.2.1
describing how to detect and respond to such NATs; also re-
arranged some of the text from old section 1.1 into the start of
Section 7.2, and added minor details of S flag processing in
Section 5.2.2, Section 5.3.1, and Section 5.3.2. [Jari Arkko,
Brian Carpenter]
Schulzrinne & Hancock Expires August 31, 2007 [Page 147]
Internet-Draft GIST February 2007
5. Modified the error message format in Appendix A.4 so that the
Additional Information fields are carried in proper TLV objects.
Also created a registry for these objects in Section 9 and
updated other IANA text about error code registration. The
individual error messages now only define the minimum Additional
Information fields to be carried; their order, and whether to
carry others, are left open. [Adrian Farrel]
6. Added a magic number to the Q-mode encapsulation in
Section 5.3.2 to minimise the risk of incorrect interception of
UDP datagrams as GIST packets, also updating the reception rules
in Section 4.3.1 and the example in Appendix D. Also added a
new Section 3.6 in the overview part explaining the
architectural impacts of GIST arising from the way that it can
intercept end to end packets. [Sam Hartman]
7. Extended the analysis of routing state errors to handle cases
including peer node restarts and malicious traffic (blind
attacks). The overall description is now in a dedicated
Section 4.4.6, with the discussion in Section 5.3.3 simplified
and corresponding corrections in Section 4.3.2 and Section 6.
[Adrian Farrel]
8. Added a new Section 4.4.2 on the criteria which should be used
in deciding whether to authorise the creation of a secured MA,
and pointers in Section 4.4.1 and Section 4.4.3 to when during
protocol operation those criteria should be invoked. Also
updated the text in Section 8.3 to indicate how these
authorisation checks prevent the on-path or upstream node
attacks mentioned there. [Sam Hartman, Russ Housley, Cullen
Jennings]
9. Added a new Section 5.7.3.1 to define the algorithm used to
check names against the database of authorised peers, and noted
in Section 9 that definition of future channel security
protocols must provide the same information. [Sam Hartman, Russ
Housley, Cullen Jennings]
10. Extended the text (mainly in Section 4.3.1, also in
Section 4.3.4 and Section 9) to be explicit about how the GIST
specification provides the required message processing rules for
packets carrying the RAO and how this should be called up when
RAO value assignments are requested by NSLPs. Also, made the
prohibition on packet fragmentation in Q-mode absolute in
Section 5.3.2.1. Added an informative Appendix C on deployment
issues with the RAO in IPv4. [Adrian Farrel]
Schulzrinne & Hancock Expires August 31, 2007 [Page 148]
Internet-Draft GIST February 2007
11. Made the NLI present in all Response messages (even those sent
over an MA as a result of multiplexing). The NLI is needed
because it contains the Responding node's value for the routing
state validity time, and also can be monitored by the Querying
node for certain classes of route change (e.g. changes in the
inbound interface at the peer). [Raised during interoperability
testing]
Technical clarifications:
1. Added text in Section 4.3.3 and extended text in Section 4.4.5
to explain the restrictions on MA usage when in-order delivery
(for a single SID) is required. [Lars Eggert]
2. Strengthened the text in Section 4.3.3 to be more precise about
the message size thresholds which cause C mode to be required.
Also, tidied up related text in Section 5.3.2, Section 5.8.1.2,
Section 5.8.1.3, and Section 5.8.2.2. [Lars Eggert]
3. Added text in Section 3.2 to explain why D-mode is not expected
to evolve and how such functionality would actually be
incorporated. Also added a discussion about how a very simple
version of some security functions could be added directly to
D-mode. [Lars Eggert, Sam Hartman]
4. Clarified that the validation checks in Section 4.3.2 must be
applied in sequence, and re-ordered the sequence of checks to
prevent carrying out a routing state inventory over a messaging
association. [Adrian Farrel]
5. Modified Section 4.3.2 to prohibit bypass in the case that the
node is the endpoint of a flow; correspondingly, clarified the
routing state table in Section 4.2.1 to eliminate storing null
state for flow endpoints, and Section 4.3.3 to prevent sending
messages from a flow endpoint to itself. [Adrian Farrel]
6. Added text in Section 4.4.3 to clarify the uniqueness
requirement on Peer-Identity, and to note the possibility of
using the Router-ID as a source for it, with caveats on when
this may not be sufficient. [Adrian Farrel]
7. Clarified the format of the object list in the NAT Traversal
object (Appendix A.3.9) as containing all 16 bits of the start
of the object TLV. [Adrian Farrel]
8. Modified the description of TLS usage in Section 5.7.3 to
clarify that negotiation is performed within TLS, and also using
RFC4307-style terminology to describe the ciphersuites to be
Schulzrinne & Hancock Expires August 31, 2007 [Page 149]
Internet-Draft GIST February 2007
supported. [Russ Housley]
9. Strengthened the text in Section 4.3.2 and Section 4.3.4 to
explain why it is crucial that a node forwarding Query messages
must not modify them, and give some implementation guidance on
how to do so. [Adrian Farrel]
10. Modified the description of MA multiplexing with matching Peer-
Identity and non-matching Interface-Address in Section 4.4.3 to
indicate that while the non-malicious cases should be rare, the
malicious case needs to be considered under the general heading
of denial of service issues, for which the text in Section 8.4
has been slightly extended. [Adrian Farrel]
11. Refined the text in Section 4.4.4 to clarify that the
requirement is to have a Query received within the timeout
period (rather than just to send it), and to provide more
detailed guidance on how to adapt the timer value if rate
limiting is impacting the number of Queries that can be sent.
[Adrian Farrel]
12. Moved the text on SID selection from Section 3.7 to a new
Section 4.1.3 where it is more reasonable for it to be normative
(as a requirement on the API). Also added text on residual
threats in Section 8.7 explaining how GIST depends on the NSLP
to follow the rules here.[Sam Hartman]
13. Totally restructured the description of Q-mode encapsulation in
Section 5.3.2, to provide more detailed rules for IP-level
interception and UDP encapsulation, including a description of
what IP-layer options are allowed (and how they should be
handled) and what additional encapsulation layers are not
allowed. [Sam Hartman]
14. Added discussion of overload protection mechanisms mainly in
Section 8.4, with supporting text in Section 4.1.1 and
Section 4.3.2. [Adrian Farrel]
15. Clarified in Section 6.3 that the policy on whether to require a
Confirm can be changed at a node whenever it likes, but that the
state machine diagram only covers the simple case where the
policy is fixed when one is in a state waiting for a Confirm in
the first place. [Adrian Farrel]
16. Clarified when the R flag should be set in Responses, added a
rule for receiving a Confirm in Established state, and clarified
when to_Expire_RNode can occur in Section 6.3. [Adrian Farrel]
Schulzrinne & Hancock Expires August 31, 2007 [Page 150]
Internet-Draft GIST February 2007
17. Added text in Section 6.4 explaining what other actions should
be taken when a messaging association fails. [Adrian Farrel]
18. Extended the text in Section 4.3.1 to explain the different
significance of the RAO and NSLPID values in a Q-mode message.
[Lisa Dusseault]
19. Modified the route change discussion in Section 7.1, adding a
new Section 7.1.4 covering the possibility that there may be
multiple routes in use in parallel (either because of load
splitting or very rapid route flapping). The new subsection
includes some of the text from the old section 1.1, and also
introduces the SII concept. [Brian Carpenter, Cullen Jennings]
Editorial issues:
1. Merged together the two subsections in Section 5.4 and removed
the old figure. The section apparently caused confusion between
C- and D-mode and was in any case technically incorrect for the
case of TCP. [Lars Eggert]
2. Added a note in Section 3.1 to clarify that the actual set of
allowed protocol combinations is in Section 5.7 and that this
section is only for conceptual guidance. Also modified the
diagram to indicate that both TLS and DTLS are possible
instantiations of Transport Layer Security, and removed
references to DTLS in Section 5.7.3, instead clarifying in
Section 9 that defining new MA-Protocol-IDs requires the
definition of any interactions with existing options. [Lars
Eggert, Russ Housley, Lisa Dusseault]
3. Retitled Section 7 from 'Advanced' to 'Additional'. Some of the
features were felt not to be so advanced. [Lars Eggert]
4. Use British English consistently (this affects only the word
'signalling' and its associates). [Lars Eggert]
5. Eliminated the term 'primary key' from the description of the
routing state table in Section 4.2.1. [Adrian Farrel]
6. Clarified what determines whether Q-mode messages have a Router
Alert Option in their IP encapsulation in Section 4.3.1.
[Adrian Farrel]
7. Clarified how routing state table entries are created in
Section 4.2.1 by adding a reference to the handshake sections
[Adrian Farrel]
Schulzrinne & Hancock Expires August 31, 2007 [Page 151]
Internet-Draft GIST February 2007
8. Added a reference in Section 4.1.2 to the authentication section
(Section 8.2) to indicate the origin of the keying material
[Adrian Farrel]
9. Re-wrote the start of Section 4.1 to clarify that the interface
definition itself is non-normative. [Adrian Farrel]
10. Eliminated the RFC2119 words in Section 3, since these related
to NSLP behaviour or related node configuration requirements.
[Adrian Farrel]
11. Modified the text in Section 3.7 to clarify that the SID really
is the responsibility of the NSLP to chose, maintain along the
path, and enforce uniqueness of. [Adrian Farrel]
12. Deleted the word 'policy' in Section 4.3.2; the interaction is
with the signalling application itself, not the signalling
application policy. [Adrian Farrel]
13. Added a note in Section 4.3.4 that directly addressed messages
shouldn't be received at nodes without the NSLP during normal
operation (i.e. that this is not impossible, it's just not
expected). [Adrian Farrel]
14. Modified the text at the start of Section 4.4 to make it clear
that messaging associations have an independent lifecycle from
routing state once they have been created. [Adrian Farrel]
15. Modified the text in Section 4.4.3 to describe use of an MA for
multiple items of routing state as multiplexing rather than re-
use; changed some of the other uses of the term 're-use' to
multiplexing also. [Adrian Farrel]
16. Expanded the definition of the D flag in Appendix A.3.1.2 to
give an interpretation for the values 0 and 1. [Adrian Farrel]
17. Deleted the confusing terms 'Upper Layer' and 'Higher Layer' in
the description of the MA-Protocol-ID registry, Section 9.
[Adrian Farrel]
18. Added text in Section 1 highlighting the importance of the
framework and threats document as background reading for this
specification. [Adrian Farrel, Cullen Jennings]
19. Clarified the padding issues for NSLP-Data in Appendix A.3.10;
the NSLP itself provides and receives data which is already
aligned on 32-bit boundaries. [Adrian Farrel]
Schulzrinne & Hancock Expires August 31, 2007 [Page 152]
Internet-Draft GIST February 2007
20. Added a note on the Stack-Configuration-Data object
(Appendix A.3.5) that the format allows the MPO-Count to be
zero. [Adrian Farrel]
21. Clarified that profiles in the Stack-Proposal object
(Appendix A.3.4) must be non-empty; an error is raised for
either empty profiles or an empty list of profiles. Also, that
pad bytes must be ignored. [Adrian Farrel]
22. Clarified the syntax of the Confirm message including how it
depends on when and how it is sent. In particular,
Section 4.4.1 now states that the first Confirm MUST contain the
abbreviated SCD, and Section 4.4.5 covers the error case if the
object is missing. The description of the Confirm in
Section 5.1 has been re-written, and the format of the SCD in
Appendix A.3.5 emphasises that the time is given in milliseconds
and that the value 0 is reserved. [Adrian Farrel, Roland Bless]
23. Modified the text in Section 6.4 to explain and motivate the
differences between the various MA states and the logic for
transitions between them; in particular, turned the Connected ->
Idle transition into one driven by policy rather then directly
by timers. Clarified that the value 0 for MA-Hold-Time is
reserved in Appendix A.3.5, and also emphasised that the format
carries a value in milliseconds. [Adrian Farrel, Roland Bless]
24. Clarified that the value 0 for Routing-State Validity time is
reserved and must not be used. [Adrian Farrel]
25. Updated the text in Appendix A to use RFC2119 language
correctly. [Adrian Farrel]
26. Clarified the text on extensibility in Appendix A.2.1 to explain
that adding new non-mandatory objects should not change the
interaction with NSLPs. [Adrian Farrel]
27. Updated the text in Appendix A.3.1.1 to clarify under what
circumstances various combinations of flags can be set, and to
indicate what error message should be returned if the rules are
violated. [Adrian Farrel]
28. Added a reference to the working group state machine draft in
Section 6. [Adrian Farrel]
29. Added a reference to the framework for the origin of the
assumption about signalling application behaviour supporting re-
routing in Section 7.1.1. [Adrian Farrel]
Schulzrinne & Hancock Expires August 31, 2007 [Page 153]
Internet-Draft GIST February 2007
30. Extended the description of the meaning of the 'Reserved' blocks
in the IANA considerations (Section 9). [Adrian Farrel]
31. Clarified in Section 9 that the information needed to justify
certain registrations needs to be in the separate specfication
document (rather than in the registry itself). [Adrian Farrel]
32. Clarified the required information to accompany the registration
of a new error in Section 9. [Adrian Farrel]
33. Added a note in Section 4.4.5 that the MA-Hello request/response
diagnostic can be used for MA protocol failure detection.
[Adrian Farrel]
34. Added a note in Section 4.4.5 to indicate that the MA-Hold-Time
setting can take NSLP behaviour (e.g. refresh timers) into
account. [Adrian Farrel]
35. Rephrased the description of the case of colliding peer-identity
and interface-address in Section 4.4.3 including a forward
reference to Section 8.7 for the case of on-path attacks.
[Adrian Farrel]
36. Added clarification in Section 4.4.1 about how the Querying node
knows when downstream routing state has been installed, and
included a forward pointer from Section 3.4. [Adrian Farrel]
37. Expanded the rationale for the use of UDP for D-mode in
Section 3.2 (that it is at least partly NAT-friendly). [Adrian
Farrel]
38. Expanded the rationale for the existence of C-mode in
Section 3.2. [Adrian Farrel]
39. Added a definition for [message] routing in Section 2,
distinguishing it from normal IP routing; qualified the term
'routing' in other parts of the document, where this could be
ambiguous. [Adrian Farrel]
40. Modified the text in step 5 of the example in Section 3.10 to
make it clear that the forwarding between successive hops is a
signalling application rather than a GIST responsibility. [Sam
Hartman, Lisa Dusseault]
41. Modified the text in Section 3.10, Section 5.7.3, and
Appendix B.1 to make it clear that 'security' is not a simple
true/false attribute. (The more detailed text on message
transfer attributes elsewhere already made this distinction.)
Schulzrinne & Hancock Expires August 31, 2007 [Page 154]
Internet-Draft GIST February 2007
[Sam Hartman]
42. Added a note to the end of Section 1 pointing more strongly to
the NSIS extensibility document for general guidelines on
protocol extensibility. [Sam Hartman]
43. Added a note at the start of Section 7.2 to highlight the
relationship of the various NAT traversal solutions for GIST to
the IETF BCP on NAT traversal. [Sam Hartman]
44. Modified the description of upstream node attacks in Section 3.7
and Section 8.3 to clarify that the effect would be to disrupt
the signalling flow rather than the traffic flow itself. [Sam
Hartman]
45. Removed old section 5.7.4 on alternative channel security
protocols, and created a new Section 3.9 describing the security
services that GIST requires and where it depends on the channel
security protocol to provide them. [Russ Housley]
46. Modified some of the text in Section 1 about the meaning of the
term "path-coupled", and also noted in Section 3.3 the future
flexibility about defining alternative probe methods. [Adrian
Farrel]
47. Modified Section 1 to leave open the concept of using GIST for
multicast in certain circumstances. [Adrian Farrel]
48. Added a new Section 3.5 introducing the peering concept in more
detail, removing some of the related terminology details and
providing forward pointers to the relevant normative sections.
[Ted Hardie]
49. Modified the start of the example (Section 3.10) to be clear
that it covers just a single segment of the path. [Lisa
Dusseault]
50. Modified the end of Section 3.2 to clarify that there is no
semantic relationship between the MA and flow concepts. [Lisa
Dusseault]
51. Extended the definition of D-mode in Section 3.2 to introduce
Query-mode at the same time. [Lisa Dusseault]
52. Rewrote the start and end of Section 4.3.2 to clarify that the
scope of the discussion is the interaction with the NSLP, and
that only the description of the GIST internal processing is
deferred to a later section. [Lisa Dusseault]
Schulzrinne & Hancock Expires August 31, 2007 [Page 155]
Internet-Draft GIST February 2007
53. Modified the text at the end of Section 4.3.3 to be clear about
which options use Q-mode and which do on. [Lisa Dusseault]
54. Modified the labelling in Figure 4 to avoid the label 'Q-node'
etc. (could cause confusion with Q-mode). [Lisa Dusseault]
55. Split the old section on state maintenance into Section 4.4.4
and Section 4.4.5 to avoid confusion between the two types of
operation. [Lisa Dusseault]
Various other minor editorial corrections have also been made.
E.2. Changes In Version -11
1. Added some text in Section 1 to clarify the scope of GIST
applicability with non-path-coupled message routing methods.
2. Loosened the text about the Query encapsulation to indicate that
a Router Alert Option is needed for all the current message
routing methods but not necessarily for future ones.
3. Clarified the rules for deriving protocol encapsulation
addresses for the Response and other messages in Section 4.4.1
and Section 5.3.1.
4. Updated the ABNF and message descriptions in Section 3.4 to
cover the case of NAT traversal for stateless data messages;
also minor changes in Section 7.2.
5. Re-corrected the timeout processing rules in Section 6.4 (update
in version 10 changed rule 3 but should have changed rule 4).
In addition, the rule 3 processing is made conditional on the
state (i.e. split) since different timers are running in the two
states.
6. Clarified that the E flag can only be set on Data messages, and
added notes to the flag description in Section 7.1.5 and the
format description in Appendix A.1. Also, included a new error
condition to cover incorrect setting in Appendix A.4.4.1.
7. Clarified the text in Section 8.4 to note the issues about
Response size contributing to reflection attacks, and also the
defence against various forms of message spoofing in
Section 8.5.
8. Stated that MA-Protocol-ID value 0 is reserved (not allocated)
in Section 9.
Schulzrinne & Hancock Expires August 31, 2007 [Page 156]
Internet-Draft GIST February 2007
9. Clarified the units (bytes, 32-bit words) for all length fields
in Appendix A.
10. Clarified that the restriction on the D flag value for the
loose-end MRM applies only to Q-mode messages in
Appendix A.3.1.2.
11. Added the Hold Time to the example in Appendix D.
E.3. Changes In Version -10
1. Added further guidance on parameter setting for initial backoff
and rate control for D-mode to Section 5.3.3 [AD review comment
M1].
2. Rephrased the end of Section 8.6 to highlight the threat left
open when the Querying node does not apply a strong security
policy to offered Stack-Proposal [AD review comment M2].
3. Clarified in Section 7.2 that although NAT behaviour is only
informatively described in this specification, it is being
defined in a separate document [AD review M3].
4. Strengthened and clarified the reference to the extensibility
document for technical guidance on codepoint allocation, and
made the reference normative. Added rationale for the
'Reserved' blocks in the various registries, and added further
notes on what information must be provided to support an
allocation request [AD review comment M4].
5. Fixed an identifier collision in the ABNF for the GIST messages
in Section 5.2.2 (Common-Header in the message header and
common-header as a payload in error messages) and re-verified
the ABNF [AD review comment L1].
6. Clarified the text in Section 3.3 about the impact on NATs of
defining a new MRM, referring to the specification split
described in Section 7.2.3. Also added a flag to the MRM format
(Appendix A.3.1) to denote MRIs which do not contain network or
transport addresses, and made more specific the error message to
be returned if a NAT does not understand an MRM in Section 7.2.2
[AD review comment L2].
7. Added discussion in Section 4.1.2 on delivery failure detected
for reliable messaging in general, and for the case of Forwards-
TCP in particular in Section 5.7.2. Also noted that this needs
to be considered for future MA-Protocol-IDs used for reliable
messaging (Section 9) [AD review comment L3].
Schulzrinne & Hancock Expires August 31, 2007 [Page 157]
Internet-Draft GIST February 2007
8. Added clarifying text to Section 5.1 on what it means to invert
the direction of an MRI [AD review comment L5].
9. Enhanced the format descriptions in Appendix A to include
descriptions of all message and object fields and also field
lengths [AD review comment L6].
10. Added more explanation in Section 5.2.2 of how a message
direction is defined, in particular in the context of TTL
measurement [AD review comment L7].
11. Added a new explanation of why a well-known port is needed for
the query encapsulation in Section 5.3.2 [AD review comment L8].
12. Added a note that DCCP does not provide reliability in
Section 5.4 [AD review comment L9].
13. Clarified the rules on how long to retain stack configuration
data in Section 5.7.1 and included a default timer value [AD
review comment L10].
14. Modified the text about stack-proposal verification as part of
downgrade protection in Section 5.7.1, to clarify that the MUST
applies directly to the object verification itself; also noted
the action to be taken in case of a failed verification [AD
review comment L11].
15. Added further information on the addressing used in opening a
forwards-TCP connection in Section 5.7.2 [AD review comment
L12].
16. Modified the text in Section 5.8.1.2 to say that using the
signalling source address is a consequence of setting DF itself
rather than why DF was set in the first place; also weakened the
instruction from MUST to SHOULD [AD review comment L14].
17. Added further clarification of why routing state installed by a
downstream Query should supersede that from an upstream Query in
Section 5.8.1.3 [AD review comment L15].
18. Corrected a timer in the Messaging Association state machine
(Section 6.4) from NoHello to SendHello. Also, added default
values for MA-Hold-Time and route change probe frequency, and
explanatory text for each, to Section 4.4.4 and Section 4.4.5
[AD review comment L16].
19. Re-arranged the text in Section 7.2 to highlight the rules about
precisely which messages are and are not translated in a GIST-
Schulzrinne & Hancock Expires August 31, 2007 [Page 158]
Internet-Draft GIST February 2007
specific way by NATs [AD review comment L19].
20. Explicitly noted that 'r' bits are also reserved in Appendix A.2
[AD review comment L20].
21. Added an error condition for processing messages which have the
extensibility flags AB set to 11 in Appendix A.2.1 [AD review
comment L21].
22. Fixed the table of MRM identifiers in Section 9 so the field
name matches that in Appendix A.3.1 [AD review comment L22].
23. Clarified why only D=0 is valid for the loose-end MRM in
Appendix A.3.1.2 [AD review comment L23].
24. Clarified the rules about processing the NAT traversal object in
Appendix A.3.9 to cover the case where there are several NATs
along the path with different capabilities [AD review comment
L24].
25. Strengthened the text in Appendix A.4.1 to be clearer about what
additional information fields must be included in error messages
[AD review comment L25].
26. Tidied up the use of acronyms throughout the document, including
adding some to the terminology list in Section 2 [AD review
comment N1].
27. Added references to RFC4086 and updated 2119 language for
cryptographic randomness of SIDs and cookies in Section 3.7 and
Section 8.5 respectively [AD review comment N2].
28. Modified the transition labelling in Figure 7 to make it clearer
that in the Established-Established transition, the
[!confirmRequired] qualification applies only to the rx_Query
case [AD review comment N4].
29. Added a reference for OSPF in Section 7.1.2 [AD review comment
N5].
30. Changed NAT terminology from public/private to external/internal
to match BEHAVE usage in Section 7.2 and Section 7.4 [AD review
comment N6].
31. Updated a number of i-d references to published RFCs or working
group documents [AD review comment N7 partial].
Schulzrinne & Hancock Expires August 31, 2007 [Page 159]
Internet-Draft GIST February 2007
32. Fixed rfc2119 capitalisation of MUST not in Appendix A.3.5 [AD
review comment N8].
33. Fixed an error subcode name from 'Invalid Object' to 'Invalid
Object Type' in Appendix A.4.4.9 [AD review comment N9].
34. Added the NTO to the GIST message ABNF in Section 5.1 and
updated the forward reference to the NAT traversal section
[tracker issue 104].
35. Removed a spurious rule about creating listening MAs in
Section 6.3 and strengthened the rules about needing to have
these available but with an open policy on when to create and
destroy them in Section 5.7.1 [tracker issue 105].
36. Added text that limits the applicability of the private/
experimental space to closed network environments [tracker issue
106].
37. Added text in Section 7.1.5 encouraging GIST to use a single SII
across multiple sessions if possible to allow signalling
application aggregation [tracker issue 107].
38. Specified that this document would define GIST version 1 in
Section 5.2.1 [tracker issue 108].
39. Added the ability for RecvMessage to pass up interface
attributes in Appendix B.2 [tracker issue 110].
40. Added additional text on rules for selecting stack proposals and
MA re-use in Section 5.7.1 to ensure that re-used associations
have properties that the Querying node actually needs [tracker
issue 111].
41. Added a brief introduction to the GIST message types in a new
Section 3.4.
In addition, the following AD review comments did not lead to text
changes. See the mailing list discussion at
http://www1.ietf.org/mail-archive/web/nsis/current/msg06307.html.
L4: Direct use of PMTUD by GIST.
L13: Use of TLS 1.0 rather than 1.1.
Schulzrinne & Hancock Expires August 31, 2007 [Page 160]
Internet-Draft GIST February 2007
L17: Guidance on NSLP behaviour during rerouting,
L18: Behaviour of GIST-unaware NATs.
N3: Node state machine logic.
E.4. Changes In Version -09
1. Added a new Section 3.8 clarifying the relationship between
signalling applications and NSLPIDs; modified terminology in the
remainder of the document likewise.
2. Added a new Section 8.6 explaining the rationale behind the
downgrade attack prevention mechanism.
3. Re-wrote parts of Section 4.3.2, Section 6.1 and Appendix B.2 to
clarify the way that GIST is assumed to interact with signalling
applications to exercise policy control over whether or not two
nodes become signalling peers during a GIST handshake.
4. Generalised an error message Appendix A.4.4.12 to cover
additional MRI validation checks in Section 4.3.4 and
Section 5.8.1.2.
5. Allowed an optional Stack-Configuration-Data object in Confirm
messages to allow messaging association lifetime to be
negotiated even in the case of late state installation at the
Responding node (see Section 4.4.1 and Section 4.4.5).
6. Removed the option in Section 4.4.3 of allowing a node to treat
messaging associations with the same authenticated end points as
equivalent.
7. Include additional guidance in Section 4.4.4 to prevent routing
state being erroneously refreshed in the case of rerouting
events; also included general guidance notes on timer setting.
8. Clarified that the Stack-Proposal lists protocols in top-to-
bottom order (see Section 5.7.1).
9. Enhanced the definition of TLS usage in Section 5.7.3 with
details on ciphersuite requirements and authentication methods.
10. Tidied up terminology and discussion of how protocol options
data is carried in the SCD; renamed higher-layer-addressing to
MA-protocol-options.
Schulzrinne & Hancock Expires August 31, 2007 [Page 161]
Internet-Draft GIST February 2007
E.5. Changes In Version -08
1. Changed the protocol name from GIMPS to GIST (everywhere).
2. Inserted RFC2119 language (MUST etc.) in the appropriate places.
3. Added references to the actions to be taken in various error
conditions, including the error messages to be send
(throughout).
4. Added legacy NAT traversal to the list of excluded functions in
old section 1.1.
5. Included some text at the end of Section 3.3 analysing the case
of a GIST node which does not support a particular MRM.
6. Added a flag to mark when messages have been explicitly routed,
so they can bypass validation against current routing state (see
Section 4.3.1).
7. Re-wrote the discussion in Section 4.3.4 to cover all cases of
nodes not hosting an NSLP (including end systems), in particular
the validations that can be performed at intermediate GIST nodes
(this replaces the old section 7.2).
8. Clarified the rules about R and S flag setting in the common
header and D flag in the MRI (Section 5).
9. Included discussion of how a node with a choice of interfaces or
IP versions should select one to use in the NLI (Section 5.2.2).
10. Modified the description of messaging association protocol
selections (Section 5.7 and elsewhere) to clarify that this is
essentially capability discovery rather than an open ended
protocol negotiation.
11. Modified the description of how higher layer addressing
information is carried (Section 5.7.1 and Appendix A.3.5) to
allow the data to be tagged against a specific profile if
necessary, or omitted if the protocol does not need it.
12. Added a higher layer protocol definition for TLS in
Section 5.7.3.
13. Simplified and restructured the state machine presentation in
Section 6, in particular using a single list for the events and
eliminating the transition tables. Also modified the operation
of the Responder machine to handle retransmitted Query messages
Schulzrinne & Hancock Expires August 31, 2007 [Page 162]
Internet-Draft GIST February 2007
correctly.
14. Re-wrote the route change handling text in Section 7.1 to
clarify the relative responsibilities of GIST and NSLPs and
their interaction through the API. Notifications are now
assumed to be a signalling application responsibility, and GIST
behaviour is defined in terms of handling changes in a 3-state
model of the correctness of the routing state for each
direction.
15. Updated the NAT traversal description in Section 7.2, including
normative text about how GIST nodes should handle messages
containing NAT-Traversal objects.
16. Likewise, clarified that the responsibility for session/flow
binding in the case of tunnelling is handled by NSLPs
(Section 7.3).
17. Formalised the IANA considerations (Section 9).
18. Extended the routing state example (Appendix D) to include a
message sequence for association setup.
19. Re-arranged the sequence of sections, including placing this
change history at the end.
E.6. Changes In Version -07
1. The open issues section has finally been removed in favour of the
authoritative list of open issues in an online issue tracker at h
ttp://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index.
2. Clarified terminology on peering and adjacencies that there may
be NSIS nodes between GIMPS peers that do some message
processing, but that are not explicitly visible in the peer state
tables.
3. Added a description of the loose-end MRM (Section 5.8.2 and
Appendix A.3.1.2).
4. Added a description of an upstream Query encapsulation for the
path-coupled MRM, Section 5.8.1.3, including rationale for and
restrictions on its use.
5. The formal description of the protocol in Section 6 has been
significantly updated and extended in terms of detail.
Schulzrinne & Hancock Expires August 31, 2007 [Page 163]
Internet-Draft GIST February 2007
6. Modified the description of the interaction between NSLPs and
GIMPS for handling inbound messages for which no routing state
exists, to allow the NSLP to indicate whether state setup should
proceed and to provide NSLP payloads for the Response or
forwarded message (Section 3.10, Section 4.3.2 and Appendix B).
7. Included new text, Section 5.6, on the processing and
encapsulation of error messages. Also added formats and an error
message catalogue in Appendix A.4, including a modified format
for the overall GIMPS-Error message and the GIMPS-Error-Data
object.
8. Removed the old section 5.3.3 on NSLPID/RAO setting on the
assumption that this will be covered in the extensibility
document.
9. Included a number of other minor corrections and clarifications.
E.7. Changes In Version -06
Version -06 does not introduce any major structural changes to the
protocol definition, although it does clarify a number of details and
resolve some outstanding open issues. The primary changes are as
follows:
1. Added a new high level Section 3.3 which gathers together the
various aspects of the message routing method concept.
2. Added a new high level Section 3.7 which explains the concept
and significance of the session identifier. Also clarified that
the routing state always depends on the session identifier.
3. Added notes about the level of address validation performed by
GIMPS in Section 4.1.2 and extensions to the API in Appendix B.
4. Split the old Node-Addressing object into a Network-Layer-
Information object and Stack-Configuration-Data object. The
former refers to basic information about a node, and the latter
carries information about messaging association configuration.
Redefined the content of the various handshake messages
accordingly in Section 4.4.1 and Section 5.1.
5. Re-wrote Section 4.4.4 and Section 4.4.5 to clarify the rules on
refresh and purge of routing state and messaging associations.
Also, moved the routing state lifetime into the Network-Layer-
Information object and added a messaging association lifetime to
the Stack- Configuration-Data object (Section 5.2).
Schulzrinne & Hancock Expires August 31, 2007 [Page 164]
Internet-Draft GIST February 2007
6. Added specific message types for errors and MA-Refresh in
Section 5.1. The error object is now GIMPS-specific
(Appendix A.4.1).
7. Moved the Flow-Identifier information about the message routing
method from the general description of the object to the path-
coupled MRM section (Section 5.8.1.1), and made a number of
clarifications to the bit format (Appendix A.3.1.1).
8. Removed text about assumptions on the version numbering of
NSLPs, and restricted the scope of the description of TLV object
formats and extensibility flags to GIMPS rather than the whole
of NSIS (Appendix A).
9. Added a new Section 5.5 explaining the possible relationships
between message types and encapsulation formats.
10. Added a new Section 6 in outline form, to capture the formal
specification of the protocol operation.
11. Added new security sections on cookie requirements (Section 8.5)
and residual threats (Section 8.7).
E.8. Changes In Version -05
Version -05 reformulates the specification, to describe routing state
maintenance in terms of exchanging explicitly identified Query/
Response/Confirm messages, leaving the upstream/downstream
distinction as a specific detail of how Query messages are
encapsulated. This necessitated widespread changes in the
specification text, especially Section 4.2.1, Section 4.4,
Section 5.1 and Section 5.3 (although the actual message sequences
are unchanged). A number of other issues, especially in the area of
message encapsulation, have also been closed. The main changes are
the following:
1. Added a reference to an individual draft on the Loose End MRM as
a concrete example of an alternative message routing method.
2. Added further text (particularly in Section 2) on what GIMPS
means by the concept of 'session'.
3. Firmed up the selection of UDP as the encapsulation choice for
D-mode, removing the open issue on this topic.
4. Defined the interaction between GIMPS and signalling
applications for communicating about the cryptographic security
properties of how a message will be sent or has been received
Schulzrinne & Hancock Expires August 31, 2007 [Page 165]
Internet-Draft GIST February 2007
(see Section 4.1.2 and Appendix B).
5. Closed the issue on whether Query messages should use the
signalling or flow source address in the IP header; both options
are allowed by local policy and a flag in the common header
indicates which was used. (See Section 5.8.1.2.)
6. Added the necessary information elements to allow the IP hop
count between adjacent GIMPS peers to be measures and reported.
(See Section 5.2.2 and Appendix A.3.3.)
7. The old open-issue text on selection of IP router alert option
values has been moved into the main specification to capture the
technical considerations that should be used in assigning such
values (in old section 5.3.3).
8. Resolved the open issue on lost Confirm messages by allowing a
choice of timer-based retransmission of the Response, or an
error message from the responding node which causes the
retransmission of the Confirm (see Section 5.3.3).
9. Closed the open issue on support for message scoping (this is
now assumed to be a NSLP function).
10. Moved the authoritative text for most of the remaining open
issues to an online issue tracker.
E.9. Changes In Version -04
Version -04 includes mainly clarifications of detail and extensions
in particular technical areas, in part to support ongoing
implementation work. The main details are as follows:
1. Substantially updated Section 4, in particular clarifying the
rules on what messages are sent when and with what payloads
during routing and messaging association setup, and also adding
some further text on message transfer attributes.
2. The description of messaging association protocol setup
including the related object formats has been centralised in a
new Section 5.7, removing the old Section 6.6 and also closing
old open issues 8.5 and 8.6.
3. Made a number of detailed changes in the message format
definitions (Appendix A), as well as incorporating initial rules
for encoding message extensibility information. Also included
explicit formats for a general purpose Error object, and the
objects used to discover supported messaging association
Schulzrinne & Hancock Expires August 31, 2007 [Page 166]
Internet-Draft GIST February 2007
protocols. Updated the corresponding open issues section (old
section 9.3) with a new item on NSLP versioning.
4. Updated the GIMPS API (Appendix B), including more precision on
message transfer attributes, making the NSLP hint about storing
reverse path state a return value rather than a separate
primitive, and adding a new primitive to allow signalling
applications to invalidate GIMPS routing state. Also, added a
new parameter to SendMessage to allow signalling applications to
'bypass' a message statelessly, preserving the source of an
input message.
5. Added an outline for the future content of an IANA
considerations section (Section 9). Currently, this is
restricted to identifying the registries and allocations
required, without defining the allocation policies and other
considerations involved.
6. Shortened the background design discussion in Section 3.
7. Made some clarifications in the terminology section relating to
how the use of C-mode does and does not mandate the use of
transport or security protection.
8. The ABNF for message formats in Section 5.1 has been re-written
with a grammar structured around message purpose rather than
message direction, and additional explanation added to the
information element descriptions in Section 5.2.
9. The description of the D-mode transport in Section 5.3 has been
updated. The encapsulation rules (covering IP addressing and
UDP port allocation) have been corrected, and a new subsection
on message retransmission and rate limiting has been added,
superseding the old open issue on the same subject (section
8.10).
10. A new open issue on IP TTL measurement to detect non-GIMPS
capable hops has been added (old section 9.5).
E.10. Changes In Version -03
Version -03 includes a number of minor clarifications and extensions
compared to version -02, including more details of the GIMPS API and
messaging association setup and the node addressing object. The full
list of changes is as follows:
1. Added a new section pinning down more formally the interaction
between GIMPS and signalling applications (Section 4.1), in
Schulzrinne & Hancock Expires August 31, 2007 [Page 167]
Internet-Draft GIST February 2007
particular the message transfer attributes that signalling
applications can use to control GIMPS (Section 4.1.2).
2. Added a new open issue identifying where the interaction between
the security properties of GIMPS and the security requirements of
signalling applications should be identified (old section 9.10).
3. Added some more text in Section 4.2.1 to clarify that GIMPS has
the (sole) responsibility for generating the messages that
refresh message routing state.
4. Added more clarifying text and table to GHC and IP TTL handling
discussion of Section 4.3.4.
5. Split Section 4.4 into subsections for different scenarios, and
added more detail on Node-Addressing object content and use to
handle the case where association re-use is possible in
Section 4.4.3.
6. Added strawman object formats for Node-Addressing and Stack-
Proposal objects in Section 5.1 and Appendix A.
7. Added more detail on the bundling possibilities and appropriate
configurations for various transport protocols in Section 5.4.
8. Included some more details on NAT traversal in Section 7.2,
including a new object to carry the untranslated address-bearing
payloads, the NAT-Traversal object.
9. Expanded the open issue discussion in old section 9.3 to include
an outline set of extensibility flags.
E.11. Changes In Version -02
Version -02 does not represent any radical change in design or
structure from version -01; the emphasis has been on adding details
in some specific areas and incorporation of comments, including early
review comments. The full list of changes is as follows:
1. Added a new section 1.1 (since removed in version 12) which
summarises restrictions on scope and applicability; some
corresponding changes in terminology in Section 2.
2. Closed the open issue on including explicit GIMPS state teardown
functionality. On balance, it seems that the difficulty of
specifying this correctly (especially taking account of the
security issues in all scenarios) is not matched by the saving
of state enabled.
Schulzrinne & Hancock Expires August 31, 2007 [Page 168]
Internet-Draft GIST February 2007
3. Removed the option of a special class of message transfer for
reliable delivery of a single message. This can be implemented
(inefficiently) as a degenerate case of C-mode if required.
4. Extended Appendix A with a general discussion of rules for
message and object formats across GIMPS and other NSLPs. Some
remaining open issues are noted in old section 9.3 (since
removed).
5. Updated the discussion of RAO/NSLPID relationships to take into
account the proposed message formats and rules for allocation of
NSLP id, and propose considerations for allocation of RAO
values.
6. Modified the description of the information used to route
messages (first given in Section 4.2.1 but also throughout the
document). Previously this was related directly to the flow
identification and described as the Flow-Routing-Information.
Now, this has been renamed Message-Routing-Information, and
identifies a message routing method and any associated
addressing.
7. Modified the text in Section 4.3 and elsewhere to impose sanity
checks on the Message-Routing-Information carried in C-mode
messages, including the case where these messages are part of a
GIMPS-Query/Response exchange.
8. Added rules for message forwarding to prevent message looping in
a new Section 4.3.4, including rules on IP TTL and GIMPS hop
count processing. These take into account the new RAO
considerations described above.
9. Added an outline mechanism for messaging association protocol
stack setup, with the details in a new Section 6.6 and other
changes in Section 4.4 and the various sections on message
formats.
10. Removed the open issue on whether storing reverse routing state
is mandatory or optional. This is now explicit in the API
(under the control of the local NSLP).
11. Added an informative annex describing an abstract API between
GIMPS and NSLPs in Appendix B.
Schulzrinne & Hancock Expires August 31, 2007 [Page 169]
Internet-Draft GIST February 2007
E.12. Changes In Version -01
The major change in version -01 is the elimination of
'intermediaries', i.e. imposing the constraint that signalling
application peers are also GIMPS peers. This has the consequence
that if a signalling application wishes to use two classes of
signalling transport for a given flow, maybe reaching different
subsets of nodes, it must do so by running different signalling
sessions; and it also means that signalling adaptations for passing
through NATs which are not signalling application aware must be
carried out in D-mode. On the other hand, it allows the elimination
of significant complexity in the C-mode handling and also various
other protocol features (such as general route recording).
The full set of changes is as follows:
1. Added a worked example in Section 3.10.
2. Stated that nodes which do not implement the signalling
application should bypass the message (Section 4.3).
3. Decoupled the state handling logic for routing state and
messaging association state in Section 4.4. Also, allow
messaging associations to be used immediately in both directions
once they are opened.
4. Added simple ABNF for the various GIMPS message types in a new
Section 5.1, and more details of the common header and each
object in Section 5.2, including bit formats in Appendix A. The
common header format means that the encapsulation is now the
same for all transport types (Section 5.4).
5. Added some further details on D-mode encapsulation in
Section 5.3, including more explanation of why a well known port
is needed.
6. Removed the possibility for fragmentation over DCCP
(Section 5.4), mainly in the interests of simplicity and loss
amplification.
7. Removed all the tunnel mode encapsulations (old sections 5.3.3
and 5.3.4).
8. Fully re-wrote the route change handling description
(Section 7.1), including some additional detection mechanisms
and more clearly distinguishing between upstream and downstream
route changes. Included further details on GIMPS/NSLP
interactions, including where notifications are delivered and
Schulzrinne & Hancock Expires August 31, 2007 [Page 170]
Internet-Draft GIST February 2007
how local repair storms could be avoided. Removed old
discussion of propagating notifications through signalling
application unaware nodes (since these are now bypassed
automatically). Added discussion on how to route messages for
local state removal on the old path.
9. Revised discussion of policy-based forwarding (old Section 7.2)
to account for actual Flow-Routing-Information definition, and
also how wildcarding should be allowed and handled.
10. Removed old route recording section (old Section 6.3).
11. Extended the discussion of NAT handling (Section 7.2) with an
extended outline on processing rules at a GIMPS-aware NAT and a
pointer to implications for C-mode processing and state
management.
12. Clarified the definition of 'correct routing' of signalling
messages in Section 8 and GIMPS role in enforcing this. Also,
opened the possibility that peer node authentication could be
signalling application dependent.
13. Removed old open issues on C-mode Encapsulation (section 8.7);
added new open issues on Message Routing (old Section 9.3 of
version -05, later moved to Section 3.3) and D-mode congestion
control.
14. Added this change history.
Schulzrinne & Hancock Expires August 31, 2007 [Page 171]
Internet-Draft GIST February 2007
Authors' Addresses
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7042
Email: hgs+nsis@cs.columbia.edu
URI: http://www.cs.columbia.edu
Robert Hancock
Siemens/Roke Manor Research
Old Salisbury Lane
Romsey, Hampshire SO51 0ZN
UK
Email: robert.hancock@roke.co.uk
URI: http://www.roke.co.uk
Schulzrinne & Hancock Expires August 31, 2007 [Page 172]
Internet-Draft GIST February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Schulzrinne & Hancock Expires August 31, 2007 [Page 173]
