One document matched: draft-ietf-nsis-ntlp-14.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY rfc1812 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1812.xml">
<!ENTITY rfc2113 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2113.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4307 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4307.xml">
<!ENTITY rfc2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY rfc2474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY rfc2711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2711.xml">
<!ENTITY rfc2765 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2765.xml">
<!ENTITY rfc3280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3280.xml">
<!ENTITY rfc3692 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3692.xml">
<!ENTITY rfc4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml">
<!ENTITY rfc4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY rfc2205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205.xml">
<!ENTITY rfc2246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml">
<!ENTITY rfc2328 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml">
<!ENTITY rfc2746 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2746.xml">
<!ENTITY rfc2766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2766.xml">
<!ENTITY rfc2960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2960.xml">
<!ENTITY rfc3056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml">
<!ENTITY rfc3068 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3068.xml">
<!ENTITY rfc3175 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3175.xml">
<!ENTITY rfc3260 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3260.xml">
<!ENTITY rfc3329 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3329.xml">
<!ENTITY rfc3489 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3489.xml">
<!ENTITY I-D.ietf-behave-turn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-turn.xml">
<!ENTITY rfc3682 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3682.xml">
<!ENTITY rfc3852 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3852.xml">
<!ENTITY rfc4080 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4080.xml">
<!ENTITY rfc4081 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4081.xml">
<!ENTITY rfc4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY rfc4279 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4279.xml">
<!ENTITY rfc4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY I-D.ietf-nsis-nslp-natfw SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-nslp-natfw.xml">
<!ENTITY rfc4213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4213.xml">
<!ENTITY rfc4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY rfc4225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4225.xml">
<!ENTITY rfc4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY I-D.pashalidis-nsis-gist-legacynats SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.pashalidis-nsis-gist-legacynats.xml">
<!ENTITY I-D.pashalidis-nsis-gimps-nattraversal SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.pashalidis-nsis-gimps-nattraversal.xml">
<!ENTITY I-D.ietf-nsis-ntlp-statemachine SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-ntlp-statemachine.xml">
<!ENTITY I-D.ietf-tcpm-tcpsecure SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-tcpsecure.xml">
]>
<rfc category="std" docName="draft-ietf-nsis-ntlp-14" ipr="full3978"
updates="">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="no" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<front>
<title abbrev="GIST">GIST: General Internet Signalling Transport</title>
<author fullname="Henning Schulzrinne" initials="H." surname="Schulzrinne">
<organization abbrev="Columbia U.">Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7042</phone>
<email>hgs+nsis@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author fullname="Robert Hancock" initials="R. E." surname="Hancock">
<organization abbrev="Siemens/RMR">Siemens/Roke Manor
Research</organization>
<address>
<postal>
<street>Old Salisbury Lane</street>
<city>Romsey</city>
<region>Hampshire</region>
<code>SO51 0ZN</code>
<country>UK</country>
</postal>
<email>robert.hancock@roke.co.uk</email>
<uri>http://www.roke.co.uk</uri>
</address>
</author>
<date year="2007" />
<workgroup>Next Steps in Signaling</workgroup>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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.</t>
<t>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 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 the current GIST design 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.</t>
<t>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 <xref
target="RFC4080"></xref> 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 <xref target="RFC4080"></xref>, and the accompanying
threats document <xref target="RFC4081"></xref>, 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.</t>
<t>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 higher layer signalling 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 purpose of GIST is thus to provide the common
functionality of node discovery, message routing and message transport
in a way which is simple for multiple signalling applications to
re-use.</t>
<t>The structure of this specification is as follows. <xref
target="terminology"></xref> defines terminology, and <xref
target="design-top"></xref> gives an informal overview of the protocol
design principles and operation. The normative specification is
contained mainly in <xref target="processing"></xref> to <xref
target="security"></xref>. <xref target="processing"></xref> describes
the message sequences and <xref target="message"></xref> their format
and contents. Note that the detailed bit formats are given in <xref
target="bit-formats"></xref>. The protocol operation is captured in the
form of state machines in <xref target="formal"></xref>. <xref
target="advanced"></xref> describes some more advanced protocol features
and security considerations are contained in <xref
target="security"></xref>. In addition, <xref target="api"></xref>
describes an abstract API for the service which GIST provides to
signalling applications, and <xref target="example-flow"></xref>
provides an example message flow. Parts of the GIST design use packets
with IP options to probe the network, which leads to some migration
issues in the case of IPv4, and these are discussed in <xref
target="rao-nasties"></xref>.</t>
<t>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. In this document, <xref
target="iana"></xref> gives the formal IANA considerations for the
registries defined by the GIST specification.</t>
</section>
<section anchor="terminology"
title="Requirements Notation and Terminology">
<t>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 <xref
target="RFC2119"></xref>. In addition, the security specifications in
<xref target="ma-tls"></xref> use the terminology MUST- and SHOULD+ from
<xref target="RFC4307"></xref>.</t>
<t>The terminology used in this specification is defined in this
section. The basic entities relevant at the GIST level are shown in
<xref target="fig-term"></xref>. 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).</t>
<figure anchor="fig-term" title="Basic Terminology">
<artwork><![CDATA[
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]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="[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.</t>
<t hangText="Session:">A single application layer exchange of
information for which some state information is to be manipulated or
monitored. See <xref target="sids"></xref> for further detailed
discussion.</t>
<t hangText="Session Identifier (SID):">An identifier for a session;
the syntax is a 128 bit value which is opaque to GIST.</t>
<t hangText="[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.</t>
<t hangText="[Flow] Receiver:">The node in the network which is the
sink for the packets in a flow.</t>
<t hangText="Downstream:">In the same direction as the data
flow.</t>
<t hangText="Upstream:">In the opposite direction to the data
flow.</t>
<t hangText="GIST Node:">Any node supporting the GIST protocol,
regardless of what signalling applications it supports.</t>
<t hangText="[Adjacent] Peer:">The next node along the signalling
path, in the upstream or downstream direction, with which a GIST
node explicitly interacts.</t>
<t hangText="Querying Node:">The GIST node that initiates the
handshake process to discover the adjacent peer.</t>
<t hangText="Responding Node:">The GIST node that responds to the
handshake, becoming the adjacent peer to the Querying node.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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 transport protocol; if security protection is
required, it may use a 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, referring to flows of either direction.</t>
<t hangText="[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,
that is, forwarding packets within the network layer based on their
destination IP address. In this document, the term 'routing'
generally refers to GIST message routing unless particularly
specified.</t>
<t hangText="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 <xref
target="mrms"></xref>.</t>
<t hangText="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 <xref target="mrms"></xref>.</t>
<t hangText="Router Alert Option (RAO):">An option that can be
included in IP v4 and v6 headers to assist in the packet
interception process; see <xref target="RFC2113"></xref> and <xref
target="RFC2711"></xref>.</t>
<t hangText="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 <xref target="mtas"></xref>.</t>
</list></t>
</section>
<section anchor="design-top" title="Design Overview">
<section anchor="protocol-stacks" title="Overall Design Approach">
<t>The generic requirements identified in the NSIS framework <xref
target="RFC4080"></xref> for transport of signalling messages are
essentially two-fold:<list style="hanging">
<t hangText="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;</t>
<t hangText="Transport:">Deliver the signalling information to
that peer.</t>
</list>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 functionality into two parts, a minimal capability provided
by GIST itself, with the use of well-understood transport protocols
for the harder cases. Here, with details discussed later, the minimal
capability is restricted to messages 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.</t>
<t>In <xref target="RFC4080"></xref> 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, with a
specialised GIST messaging layer running over standard transport and
security protocols. The basic concept is shown in <xref
target="fig-stacks"></xref>. 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 <xref target="ma-setup"></xref>. The
figure also shows GIST offering its services to upper layers at an
abstract interface, the GIST API, further discussed in <xref
target="api-overview"></xref>.</t>
<figure anchor="fig-stacks"
title="Protocol Stack Architecture for Signalling Transport">
<artwork><![CDATA[
^^ +-------------+
|| | 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 |
+----------------------------------------------+]]></artwork>
</figure>
</section>
<section anchor="modes" title="Modes and Messaging Associations">
<t>Internally, GIST has two modes of operation:<list style="hanging">
<t hangText="Connection mode (C-mode):">used for larger messages
or where fast signalling application state setup in the face of
packet loss is desirable, or where channel security is
required.</t>
<t hangText="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.</t>
</list>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.</t>
<t>D-mode uses UDP, as a suitable NAT-friendly encapsulation which
does not require per-message shared state to be maintained between the
peers. Long-term evolution of GIST is assumed to preserve the
simplicity of the current D-mode design. Any extension to the security
or transport capabilities of D-mode can be viewed as the selection of
a different protocol stack under the GIST messaging layer; this is
then equivalent to defining 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 <xref
target="format-extensibility"></xref>). Note that in such an approach,
downgrade attacks as discussed in <xref target="sec-proto"></xref>
would need to be prevented by policy at the destination node.</t>
<t>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 shared security
associations and transport connections between core routers to be used
for messages for multiple flows and signalling applications. 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.</t>
<t>It must be understood that the routing and transport functions
within by GIST are not independent. If the message transfer has
requirements that require C-mode, for example if the message is so
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.</t>
<t>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.</t>
</section>
<section anchor="mrms" title="Message Routing Methods">
<t>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:<list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
</list>Most of the details of GIST operation are independent of the
routing behaviour being used. Therefore, the GIST design encapsulates
the routing-dependent details as a message routing method (MRM), and
allows multiple MRMs to be defined. This specification defines the
path-coupled MRM, corresponding to the baseline functionality
described above, and a second ("Loose End") MRM for the NAT Address
Reservation case. The detailed specifications are given in <xref
target="mrm-specs"></xref>.</t>
<t>The content of an MRM definition is as follows, using the
path-coupled MRM as an example:<list style="symbols">
<t>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 <xref
target="pc-mri"></xref>) 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'.</t>
<t>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 <xref target="pc-downstream"></xref> and
<xref target="pc-upstream"></xref>. 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.</t>
<t>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 <xref
target="pc-downstream"></xref>.</t>
<t>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 <xref
target="route-change-mechanisms"></xref>.</t>
</list>In addition, it should be noted that NAT traversal may
require translation of fields in the MRI object carried in GIST
messages (see <xref target="ga-nat-overview"></xref>). 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 <xref target="nat-rules"></xref> and <xref
target="I-D.pashalidis-nsis-gimps-nattraversal"></xref>.</t>
<t>The MRI is passed explicitly between signalling applications and
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.</t>
</section>
<section anchor="messages" title="GIST Messages">
<t>GIST has six message types: Query, Response, Confirm, Data, Error,
and MA-Hello. Apart from the invocation of the messaging association
protocols used by C-mode, 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.</t>
<t>The Query, Response and Confirm 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. The
content of the Response controls whether a Confirm message is sent: as
part of the defence against denial of service attacks, the Responding
node can delay state installation until a return routability check has
been performed, and require the Querying node to complete the
handshake with the Confirm message. In addition, if the handshake is
being used to set up a new MA, the Response is required to request a
Confirm. All of these three messages can optionally carry signalling
application data. The handshake is fully described in <xref
target="ssetup"></xref>.</t>
<t>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.</t>
</section>
<section anchor="peering" title="GIST Peering Relationships">
<t>Peering is the process whereby two GIST nodes create message
routing states which point to each other.</t>
<t>A peering relationship can only be created by a GIST handshake.
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 <xref
target="local-proc"></xref>. Nodes not hosting the NSLP forward the
Query transparently (<xref target="bypass"></xref>).</t>
<t>An existing 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
to 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 <xref
target="route-change"></xref>.</t>
</section>
<section anchor="transparency" title="Effect on Internet Transparency">
<t>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 the Query messages which 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.</t>
<t>Because this interception potentially breaks Internet transparency
for packets which have 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:<list
style="symbols">
<t>Q-mode messages are always sent as UDP traffic, and to a
specific well-known port allocated by IANA.</t>
<t>All GIST messages sent as UDP have a magic number as the first
32-bit word of the datagram payload.</t>
</list>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 level and forwarded transparently. Further discussion of the
reception process is in <xref target="reception"></xref> and the
encapsulation in <xref target="d-transport"></xref>.</t>
</section>
<section anchor="sids" title="Signalling Sessions">
<t>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.</t>
<t>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:<list
style="symbols">
<t>The simplest case is that all signalling messages for the same
flow have the same SID.</t>
<t>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.</t>
<t>A single flow may have messages for different SIDs, for example
from independently operating signalling applications.</t>
</list>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.</t>
<t>The SID assignment has the following impact on GIST
processing:<list style="symbols">
<t>Messages with the same SID that are to be delivered reliably
between the same GIST peers are delivered in order.</t>
<t>All other messages are handled independently.</t>
<t>GIST identifies routing state (upstream and downstream peer) by
the triplet (MRI, NSLP, SID).</t>
</list>Strictly speaking, 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 <xref
target="routing-integrity"></xref>) 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 <xref
target="sid-selection"></xref>.</t>
</section>
<section anchor="nslps" title="Signalling Applications and NSLPIDs">
<t>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 (<xref
target="iana"></xref>). 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. <xref target="RFC3175"></xref>).
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.</t>
</section>
<section anchor="gist-security-services" title="GIST Security Services">
<t>GIST has two distinct security goals:<list style="symbols">
<t>to protect GIST state from corruption, and to protect the nodes
on which it runs from resource exhaustion attacks; and</t>
<t>to provide secure transport for NSLP messages to the signalling
applications.</t>
</list>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 <xref
target="sid-selection"></xref> and <xref target="ssetup"></xref>, and
the overall security aspects are discussed in <xref
target="security"></xref>.</t>
<t>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:<list style="symbols">
<t>mutual authentication of the GIST peer nodes;</t>
<t>ability to verify the authenticated identity against a database
of nodes authorised to take part in GIST signalling;</t>
<t>confidentiality and integrity protection for NSLP data, and
provision of the authenticated identities used to the signalling
application.</t>
</list>The authorised peer database is described in more detail in
<xref target="signalling-peer-authorisation"></xref>, 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 <xref
target="ma-tls"></xref> 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 (<xref target="ssetup"></xref>) 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.</t>
</section>
<section anchor="example" title="Example of Operation">
<t>This section presents an example of GIST usage in a relatively
simple (in particular, NAT-free) signalling scenario, to illustrate
its main features.</t>
<figure anchor="fix-example" title="Example of Operation">
<preamble></preamble>
<artwork><![CDATA[ GN1 GN2
+------------+ +------------+
NSLP | | | |
Level | >>>>>>>>>1 | | 5>>>>>>>>5 |
| ^ V | Intermediate | ^ V |
|-^--------2-| Routers |-^--------V-|
| ^ V | | ^ V |
| ^ V | +-----+ +-----+ | ^ V |
>>>>>>>>>>^ >3>>>>>>>>4>>>>>>>>>>>4>>>>>>>>>5 5>>>>>>>>>
| | | | | | | |
GIST | 6<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<6 |
Level +------------+ +-----+ +-----+ +------------+
>>>>>, <<<<< = Signalling messages
1 - 6 = Stages in the example
(stages 7 and 8 are not shown)]]></artwork>
<postamble></postamble>
</figure>
<t>Consider the case of an RSVP-like signalling application which
makes receiver-based resource reservations 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 some distance along the path, GN1 and GN2
(see <xref target="fix-example"></xref>). We take up the story at the
point where a message is being processed above the GIST layer by the
signalling application in GN1.<list style="numbers">
<t>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
be transferred to the next downstream signalling application peer
on the path that the flow will take.</t>
<t>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-internal policy interactions between GIST and the signalling
application.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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
sending back the necessary GIST Response:<list style="hanging">
<t hangText="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.</t>
<t hangText="6.B - No Association:">GN2 sends the Response in
D-mode directly to GN1, identifying itself and agreeing to the
messaging association setup. The protocol exchanges needed to
complete this will proceed in parallel with the following
stages.</t>
</list>In each case, the result is that GN1 and GN2 are now in a
peering relationship for the flow.</t>
<t>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).</t>
<t>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.</t>
</list>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 <xref
target="route-change"></xref>).</t>
<t>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.</t>
</section>
</section>
<section anchor="processing" title="GIST Processing Overview">
<t>This section defines the basic structure and operation of GIST. <xref
target="api-overview"></xref> describes the way in which GIST interacts
with local signalling applications in the form of an abstract service
interface. <xref target="gist-state"></xref> describes the per-flow and
per-peer state that GIST maintains for the purpose of transferring
messages. <xref target="basic-processing"></xref> 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, <xref target="maintenance"></xref> describes how routing state
and messaging associations are created and managed.</t>
<section anchor="api-overview" title="GIST Service Interface">
<t>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.</t>
<t>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 <xref target="api"></xref>.</t>
<section anchor="message-handling" title="Message Handling">
<t>Fundamentally, GIST provides a simple message-by-message transfer
service for use by signalling applications: individual messages are
sent, and individual messages are received. At the service
interface, the NSLP payload, which is opaque to GIST, is accompanied
by control information expressing the application's requirements
about how the message should be routed (the MRI), and the
application also provides the session identifier (SID), see <xref
target="sid-selection"></xref>. Additional message transfer
attributes control the specific transport and security properties
that the signalling application desires.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="mtas" title="Message Transfer Attributes">
<t>Message transfer attributes are used by NSLPs to define minimum
required levels of message processing. The attributes available are
as follows:<list style="hanging">
<t hangText="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 (e.g. in
the case of a transport layer error), an error MUST be indicated
to the local signalling application identifying the routing
information for the message in question. GIST implements
reliability by using an appropriate transport protocol within a
messaging association, so mechanisms for the detection of
message loss depend on the protocol in question; for the current
specification, the case of TCP is considered in <xref
target="ma-ftcp"></xref>. When 'false', a message may be
delivered, once, several times or not at all, with no error
indications in any case.</t>
<t hangText="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 <xref target="authentication"></xref>. The
attribute can be specified explicitly by the signalling
application, or reported by GIST to the signalling application.
The latter can take place either on receiving a message, or just
before sending a message but after configuring or selecting the
messaging association to be used for it.<vspace
blankLines="1" />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 <xref target="api"></xref>.</t>
<t hangText="Local Processing:">An NSLP may provide hints to
GIST to enable more efficient or appropriate processing. For
example, the NSLP may select a priority from a range of locally
defined values to influence the sequence in which messages leave
a node. Any priority mechanism MUST respect the ordering
requirements for reliable messages within a session, and
priority values are not carried in the protocol or available at
the signalling peer or intermediate nodes. An NSLP may also
indicate that upstream path routing state will not be needed for
this flow, to inhibit the node requesting its downstream peer to
create it; conversely, even if routing state exists, the NSLP
may request that it is not used, which will lead to GIST Data
messages being sent Q-mode encapsulated instead.</t>
</list>A GIST implementation MAY deliver messages with better
performance than strictly required by the attributes given.</t>
</section>
<section anchor="sid-selection" title="SID Selection">
<t>The fact that SIDs index routing state (see <xref
target="routing-state"></xref> 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 <xref
target="RFC4086"></xref>.</t>
</section>
</section>
<section anchor="gist-state" title="GIST State">
<section anchor="routing-state" title="Message Routing State">
<t>For each flow, the GIST layer can maintain message routing state
to manage the processing of outgoing messages. This state is
conceptually organised into a table with the following structure.
Each row in the table corresponds to a unique combination of the
following three items:<list style="hanging">
<t hangText="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 <xref target="mrms"></xref>.</t>
<t hangText="Session Identification (SID):">The signalling
session with which this message should be associated; see <xref
target="sids"></xref>.</t>
<t hangText="NSLP Identification (NSLPID):">This is an
IANA-assigned identifier associated with the NSLP which is
generating messages for this flow; see <xref
target="nslps"></xref>. The inclusion of this identifier allows
the routing state to be different for different NSLPs.</t>
</list>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
<xref target="ma-reuse"></xref>), 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 <xref target="maintenance"></xref>.</t>
<t>It is also possible for the state information for either
direction to be empty. There are several possible cases:<list
style="symbols">
<t>The signalling application has indicated that no messages
will actually be sent in that direction.</t>
<t>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.</t>
<t>The node is using other techniques to route the message. For
example, it can send it in Q-mode and rely on the peer to
intercept it.</t>
</list>In particular, if the node is a flow endpoint, GIST will
refuse to create routing state for the direction beyond the end of
the flow (see <xref target="message-transmission"></xref>). Each
entry in the routing state table has an associated validity timer
indicating for how long it can be considered accurate. When this
timer expires, the entry MUST be purged if it has not been
refreshed. Installation and maintenance of routing state is
described in more detail in <xref target="maintenance"></xref>.</t>
</section>
<section title="Peer-Peer Messaging Association State">
<t>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:<list
style="symbols">
<t>a queue of any messages that require the use of an MA,
pending transmission while the MA is being established;</t>
<t>the time since the peer re-stated its desire to keep the MA
open (see <xref target="ma-maint"></xref>).</t>
</list>In addition, per-MA state, such as TCP port numbers or
timer information, is held in the messaging association protocols
themselves. However, the details of this state are not directly
visible to GIST, and they do not affect the rest of the protocol
description.</t>
</section>
</section>
<section anchor="basic-processing" title="Basic GIST Message Processing">
<t>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, in <xref
target="bypass"></xref>, 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
<xref target="fig-proc"></xref>. This section concentrates on the GIST
level processing, with full details of IP and transport layer
encapsulation in <xref target="d-transport"></xref> and <xref
target="c-transport"></xref>.</t>
<figure anchor="fig-proc" title="Message Paths through a GIST Node">
<artwork><![CDATA[ +---------------------------------------------------------+
| >> Signalling Application Processing >> |
| |
+--------^---------------------------------------V--------+
^ NSLP NSLP V
^ Payloads Payloads V
+--------^---------------------------------------V--------+
| >> GIST >> |
| ^ ^ ^ Processing V V V |
+--x-----------N--Q---------------------Q--N-----------x--+
x N Q Q N x
x N Q>>>>>>>>>>>>>>>>>>>>>Q N x
x N Q Bypass at Q N x
+--x-----+ +--N--Q--+ GIST level +--Q--N--+ +-----x--+
| C-mode | | D-mode | | D-mode | | C-mode |
|Handling| |Handling| |Handling| |Handling|
+--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+
x N Q Q N x
x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x
x N Q Bypass at Q N x
+--x--N--+ +-----Q--+ IP (router +--Q-----+ +--N--x--+
|IP Host | | 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]]></artwork>
</figure>
<section anchor="reception" title="Message Reception">
<t>Messages can be received in C-mode or D-mode.</t>
<t>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.</t>
<t>Reception in D-mode depends on the message type.<list
style="hanging">
<t hangText="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.</t>
<t hangText="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 (<xref target="q-encaps"></xref>)
it MUST be forwarded transparently at the IP level. If it does
match, GIST MUST check the NSLPID in the common header. The case
where the NSLPID does not match a local signalling application
at all is considered below in <xref target="bypass"></xref>;
otherwise, the message MUST be passed up to the GIST layer for
further processing.</t>
</list></t>
<t>Several different RAO values may be used by the NSIS protocol
suite. GIST itself does not allocate any RAO values (for either IPv4
or IPv6); an assignment is made for each NSLP using MRMs that use
the RAO in the Q-mode encapsulation. The assignment rationale is
discussed in a separate document. 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.</t>
<t>For all assignments associated with NSIS, the RAO specific
processing is the same and is as defined by this specification, here
and in <xref target="bypass"></xref> and <xref
target="q-encaps"></xref>.</t>
<t>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 (<xref
target="error-hop-limit-exceeded"></xref>); note that a correct GIST
implementation will never send such a message. Otherwise, the GIST
hop count MUST be decremented by one before the next stage.</t>
</section>
<section anchor="local-proc" title="Local Processing and Validation">
<t>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 <xref
target="maintenance"></xref>. This section concentrates on the
interaction with the signalling application, in particular the
decision to peer and how data is delivered to the NSLP.</t>
<t>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.<list style="numbers">
<t>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 <xref target="ssetup"></xref>. The application MAY
provide an NSLP payload for the same NSLPID, which GIST will
transfer in the Response.</t>
<t>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 <xref target="bypass"></xref>.
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 and GIST hop count; in particular, it
MUST NOT modify any other GIST payloads or their order. An
implementation MAY choose to achieve this by retaining the
original message, rather than reconstructing it from some parsed
internal representation.</t>
</list></t>
<t>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 <xref target="api-recvmessage"></xref> for
further discussion.</t>
<t>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:<list style="numbers">
<t>if the message was explicitly routed (see <xref
target="nslp-reroute"></xref>) or is a Data message delivered
without routing state (see <xref target="q-encaps"></xref>), the
payload is delivered but flagged to the receiving NSLP to
indicate that routing state was not validated;</t>
<t>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 (<xref
target="error-incorrectly-delivered-message"></xref>);</t>
<t>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 <xref target="routing-state-failures"></xref> for
further details);</t>
<t>else, the payload is delivered as normal.</t>
</list></t>
</section>
<section anchor="message-transmission" title="Message Transmission">
<t>Signalling applications can generate their messages for
transmission, either asynchronously, or in reply to an input message
delivered by GIST, and GIST can also generate messages autonomously.
GIST MUST verify that it is not the direct destination of an
outgoing message, and MUST reject such messages with an error
indication to the signalling application. When the message is
generated by a signalling application, it may be carried in a Query
if local policy and the message transfer attributes allow it;
otherwise this may trigger setup of an MA over which the NSLP
payload is sent in a Data message.</t>
<t>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 (<xref
target="api"></xref>) 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 <xref target="RFC1122"></xref>.</t>
<t>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 <xref target="error-proc"></xref>
for special rules applying to the transmission of error messages by
GIST.</t>
<t>The main decision is whether the message must be sent in C-mode
or D-mode. Reasons for using C-mode are:<list style="symbols">
<t>message transfer attributes: for example, the signalling
application has specified security attributes that require
channel-secured delivery, or reliable delivery.</t>
<t>message size: a message whose size (including the GIST
header, GIST objects and any NSLP payload, and an allowance for
the IP and transport layer encapsulation required by D-mode)
exceeds a fragmentation-related threshold MUST be sent over
C-mode, using a messaging association that supports
fragmentation and reassembly internally. The allowance for IP
and transport layer encapsulation is 64 bytes. The message size
MUST NOT exceed the Path MTU to the next peer, if this is known.
If this is not known, the message size MUST NOT exceed the least
of the first-hop MTU, and 576 bytes. The same limit applies to
IPv4 and IPv6.</t>
<t>congestion control: D-mode SHOULD NOT be used for signalling
where it is possible to set up routing state and use C-mode,
unless the network can be engineered to guarantee capacity for
D-mode traffic within the rate control limits imposed by GIST
(see <xref target="rate-control"></xref>).</t>
</list>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 <xref
target="ma-maint"></xref>.</t>
<t>If the use of a messaging association (i.e. C-mode) is selected,
the message is queued on the association found from the routing
state table, and further output processing is carried out according
to the details of the protocol stacks used. If no appropriate
association exists, the message is queued while one is created (see
<xref target="ssetup"></xref>), 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.</t>
<t>If a messaging association is not appropriate, the message is
sent in D-mode. The processing in this case depends on the message
type, local policy, and whether routing state exists or not.<list
style="symbols">
<t>If the message is not a Query, and local policy does not
request the use of Q-mode for this message, and routing state
exists, it is sent with the normal D-mode encapsulation directly
to the address from the routing state table.</t>
<t>If the message is a Query, or the message is Data and local
policy as given by the message transfer attributes request the
use of Q-mode, then it is sent in Q-mode as defined in <xref
target="q-encaps"></xref>; the details depend on the message
routing method.</t>
<t>If no routing state exists, GIST can attempt to use Q-mode as
in the Query case: either sending a Data message with the Q-mode
encapsulation, or using the event as a trigger for routing state
setup (see <xref target="maintenance"></xref>). 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.</t>
</list></t>
</section>
<section anchor="bypass" title="Nodes not Hosting the NSLP">
<t>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:<list
hangIndent="" style="numbers">
<t>A message contains an RAO value which is relevant to NSIS,
but it does not exactly match the Q-mode encapsulation rules of
<xref target="q-encaps"></xref>. The message MUST be
transparently forwarded at the IP layer. See <xref
target="transparency"></xref>.</t>
<t>A Q-mode encapsulated message contains an RAO value which has
been assigned to some NSIS signalling application but which is
not used on this specific node, but the IP layer is unable to
distinguish whether it needs to be passed to GIST for further
processing or whether the packet should be forwarded just like a
normal IP datagram.</t>
<t>A Q-mode encapsulated message contains an RAO value which has
been assigned to an NSIS signalling application which is used on
this node, but the signalling application does not process the
specific NSLPID in the message. (This covers the case where a
signalling application uses a set of NSLPIDs.)</t>
<t>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, <xref
target="error-unknown-nslpid"></xref>.</t>
<t>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 (<xref
target="error-endpoint-found"></xref>). The end-system includes
the MRI and SID from the original message in the error message
without interpreting them.</t>
<t>The node is GIST-aware NAT. See <xref
target="nat"></xref>.</t>
</list>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 <xref
target="local-proc"></xref>. However, a GIST implementation MUST
ensure that the IP-layer TTL field and GIST hop count are managed
correctly to prevent message looping, and this should be done
consistently independently of 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).</t>
<t>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:<list style="numbers">
<t>The message is so large that it would be fragmented on
downstream links, for example because the downstream MTU is
abnormally small (less than 576 bytes). The error "Message Too
Large" (<xref target="error-message-too-large"></xref>) SHOULD
be returned to the sender, which SHOULD begin messaging
association setup.</t>
<t>The GIST hop count has reached zero. The error "Hop Limit
Exceeded" (<xref target="error-hop-limit-exceeded"></xref>)
SHOULD be returned to the sender, which MAY retry with a larger
initial hop count.</t>
<t>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" (<xref
target="error-mri-validation-failure"></xref>) 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.</t>
</list>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 <xref target="local-proc"></xref>, 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.</t>
</section>
</section>
<section anchor="maintenance"
title="Routing State and Messaging Association Maintenance">
<t>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
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.</t>
<t>There are two different cases for state installation and
refresh:<list style="numbers">
<t>Where routing state is being discovered or a new association is
to be established; and</t>
<t>Where a suitable association already exists, including the case
where routing state for the flow is being refreshed.</t>
</list>These cases are now considered in turn, followed by the case
of background general management procedures.</t>
<section anchor="ssetup"
title="Routing State and Messaging Association Creation">
<t>The complete sequence of possible messages for GIST state setup
between adjacent peers is shown in <xref
target="fig-handshake"></xref> 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 <xref target="example-flow"></xref>.</t>
<t>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 <xref target="cookies"></xref>
for further details).</t>
<t>Provided that the signalling application has indicated that
message routing state should be set up (see <xref
target="local-proc"></xref>), reception of a Query MUST elicit a
Response. This is a normally encapsulated D-mode message with
additional GIST payloads. It contains network layer information
about the responding node, echoes the Query Cookie, and MAY contain
an NSLP payload, possibly a reply to the NSLP payload in the initial
message. In case a messaging association was requested, it MUST also
contain a Responder Cookie and its own capability information about
messaging association protocol stacks. Even if a messaging
association is not requested, the Response MAY still include a
Responder Cookie if the node's routing state setup policy requires
it (see below).</t>
<figure anchor="fig-handshake"
title="Message Sequence at State Setup">
<artwork><![CDATA[
+----------+ +----------+
| Querying | |Responding|
| Node(Q-N)| | Node(R-N)|
+----------+ +----------+
Query
----------------------> .............
Router Alert Option . Routing .
MRI/SID/NSLPID . state .
Q-N Network Layer Info . installed .
Query Cookie . at .
[Q-N Stack-Proposal . Responding.
Q-N Stack-Config-Data] . node .
[NSLP Payload] . (case 1) .
.............
......................................
. The responder can use an existing .
. messaging association if available .
. from here onwards to short-circuit .
. messaging association setup .
......................................
Response
............. <----------------------
. Routing . MRI/SID/NSLPID
. state . R-N Network Layer Info
. installed . Query cookie
. at . [Responder Cookie
. Querying . [R-N Stack-Proposal
. node . R-N Stack-Config-Data]]
............. [NSLP Payload]
....................................
. If a messaging association needs .
. to be created, it is set up here .
. and the Confirm uses it .
....................................
Confirm .............
----------------------> . Routing .
MRI/SID/NSLPID . state .
Q-N Network Layer Info . installed .
[Responder Cookie . at .
[R-N Stack-Proposal . Responding.
[Q-N Stack-Config-Data]]] . node .
[NSLP Payload] . (case 2) .
.............]]></artwork>
</figure>
<t>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 <xref target="ma-setup"></xref>. 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 <xref
target="signalling-peer-authorisation"></xref> below. Note that the
verification can depend on what the MA is to be used for (e.g. for
which MRI or session), so this step may not be possible immediately
after authentication has completed but some time later.</t>
<t>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 <xref target="rate-control"></xref>. 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
<xref target="cookies"></xref>), and the latter is to prevent
certain bidding-down attacks on messaging association security (see
<xref target="sec-proto"></xref>). This first Confirm on a new
association MUST also contain a Stack-Configuration-Data object
carrying an MA-Hold-Time value, which supersedes the value given in
the original Query. The association can be used in the upstream
direction for the MRI and NSLPID carried in the Confirm, after the
Confirm has been received.</t>
<t>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:<list style="hanging">
<t hangText="Case 1:">after the receipt of the initial Query,
or</t>
<t hangText="Case 2:">after a Confirm containing the Responder
Cookie.</t>
</list>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 <xref target="security"></xref>.
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 <xref target="nat"></xref> and
<xref target="security"></xref> respectively.</t>
</section>
<section anchor="signalling-peer-authorisation"
title="GIST Peer Authorisation">
<t>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:</t>
<t><list style="symbols">
<t>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.</t>
<t>Authorised peers are trusted to obey transport and
application level flow control rules, and not to attempt to
create overload situations.</t>
<t>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.</t>
</list>This specification models the decision as verification by
the authorising node of the peer's identity against a local list of
peers, the authorised peer database (APD). The APD is an abstract
construct, similar to the security policy database of IPsec <xref
target="RFC4301"></xref>. 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.</t>
<t>The APD consists of a list of entries. Each entry includes an
identity, the namespace from which the identity comes (e.g. DNS
domains), the scope within which the entry is applicable, and
whether authorisation is allowed or denied. The following are
example scopes:</t>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
</list>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 <xref target="ma-tls"></xref>. 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.</t>
<t>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 (<xref
target="api-networknotification"></xref>).</t>
<t>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.</t>
</section>
<section anchor="ma-reuse" title="Messaging Association Multiplexing">
<t>It is a design goal of GIST that, as far as possible, a single
messaging association should be used for multiple flows and sessions
between two peers, rather than setting up a new MA for each. This
re-use of existing MAs is referred to as messaging association
multiplexing. Multiplexing ensures that the MA cost scales only with
the number of peers, and avoids the latency of new MA setup where
possible.</t>
<t>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 normal handshake in D-mode, and this
identification must be done as reliably and securely as continuing
with this 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).</t>
<t>MA multiplexing is controlled by the Network-Layer-Information
(NLI) object, which is carried in Query, Response and Confirm
messages. The NLI object includes (among other elements):<list
style="hanging">
<t hangText="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 <xref
target="RFC1812"></xref>, which is one of the router's IP
addresses, MAY be used as one possible value for the
Peer-Identity. In scenarios with nested NATs, the Router-ID
alone may not satisfy the uniqueness requirements, in which case
it MAY be extended with additional tokens, either chosen
randomly or administratively coordinated.</t>
<t hangText="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 <xref
target="tlvs"></xref>.</t>
</list>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.</t>
<t>MA multiplexing is achieved by matching these two elements from
the NLI provided in a new GIST message with one associated with an
existing MA. The message can be either a Query or Response, although
the former is more likely:<list style="symbols">
<t>If there is a perfect match to an existing association, that
association SHOULD be re-used, provided it meets the criteria on
security and transport properties given at the end of <xref
target="ma-overview"></xref>. This is indicated by sending the
remaining messages in the handshake over that association. This
will lead to multiplexing on an association to the wrong node if
signalling nodes have colliding Peer-Identities and one is
reachable at the same Interface-Address as another. This could
be caused by an on-path attacker; on-path attacks are discussed
further in <xref target="residual"></xref>. When multiplexing is
done, and the original MA authorisation was MRI-dependent, the
verification steps of <xref
target="signalling-peer-authorisation"></xref> MUST be repeated
for the new flow.</t>
<t>In all other cases, the handshake MUST be executed in D-mode
as usual. There are in fact four possibilities:<list
style="numbers">
<t>Nothing matches: this is clearly a new peer.</t>
<t>Only the Peer-Identity matches: this may be either a new
interface on an existing peer, or a changed address mapping
behind a NAT. These should be rare events, so the expense of
a new association setup is acceptable. Another possibility
is one node using another node's Peer-Identity, for example
as some kind of attack. Because the Peer-Identity is used
only for this multiplexing process, the only consequence
this has is to require a new association setup, and this is
considered in <xref target="dos"></xref>.</t>
<t>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.</t>
<t>Both elements of the NLI object match: this is a
degenerate case, where one node recognises an existing peer,
but wishes to allow the option to set up a new association
in any case, for example to create an association with
different properties.</t>
</list></t>
</list></t>
</section>
<section anchor="maint-procedures" title="Routing State Maintenance">
<t>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 <xref
target="route-change-mechanisms" /> 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 (<xref target="rate-control" />), nodes MUST increase
the timer for new items and on the refresh of existing ones. A
suitable value is</t>
<artwork><![CDATA[ 2 * (number of routing states) / (rate limit in pkts/second)
]]></artwork>
<t>which leaves a factor of two headroom for new routing state
creation and Query retransmissions.</t>
<t>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
(<xref target="api-setstatelifetime" />) that the state is no longer
required, because this would prevent correct state repair in the
case of network rerouting at the IP layer.</t>
<t>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:<list style="symbols">
<t>The transmission latency between source and destination;</t>
<t>The need for retransmissions of Query messages;</t>
<t>The need to avoid network synchronisation of control traffic
(cf. <xref target="floyd-sync" />).</t>
</list>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.</t>
</section>
<section anchor="ma-maint" title="Messaging Association Maintenance">
<t>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:<list style="symbols">
<t>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.</t>
<t>whether the peer still wants the MA to remain in place.
During MA setup, as part of the Stack-Configuration-Data, each
node advertises its own MA-Hold-Time, which is the time for
which it will retain an MA which is not carrying signalling
traffic. A node MUST NOT tear down an MA if it has received
traffic from its peer over that period. A peer which has
generated no traffic but still wants the MA retained can use a
special null message (MA-Hello) to indicate the fact. A default
value for MA-Hold-Time of 30 seconds is RECOMMENDED. Nodes MAY
use shorter times to achieve more rapid peer failure detection,
but need to take into account the load on the network created by
the MA-Hello messages. Nodes MAY use longer times, but need to
take into account the cost of retaining idle MAs for extended
periods. Nodes MAY take signalling application behaviour (e.g.
NSLP refresh times) into account in choosing an appropriate
value.<vspace blankLines="1" />Because the Responding node can
choose not to create state until a Confirm, an abbreviated
Stack-Configuration-Data object containing just this information
from the initial Query MUST be repeated by the Querying node in
the first Confirm sent on a new MA. If the object is missing in
the Confirm, an "Object Type Error" message (<xref
target="error-object-type-error"></xref>) with subcode 2
("Missing Object") MUST be returned.</t>
</list>Messaging associations can always be set up on demand, and
messaging association status is not made directly visible outside
the GIST layer. Therefore, even if GIST tears down and later
re-establishes a messaging association, signalling applications
cannot distinguish this from the case where the MA is kept
permanently open. To maintain the transport semantics described in
<xref target="api-overview"></xref>, 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.</t>
<t>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:<list style="symbols">
<t>The transmission latency between source and destination;</t>
<t>The need for retransmissions within the messaging association
protocols;</t>
<t>The need to avoid network synchronisation of control traffic
(cf. <xref target="floyd-sync"></xref>).</t>
</list>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.</t>
</section>
<section anchor="routing-state-failures"
title="Routing State Failures">
<t>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:<list style="symbols">
<t>Where the message is random traffic from an attacker, or
backscatter (replies to such traffic).</t>
<t>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.</t>
<t>Where the routing state has never been correctly installed in
the first place, but the sending node does not know this. This
can happen if the Confirm message of the handshake is lost.</t>
</list>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:<list
style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list>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 (<xref
target="error-no-routing-state"></xref>). There are then three cases
at the receiver of the error message:<list style="hanging">
<t hangText="No routing state:">The condition MAY be logged but
a reply MUST NOT be sent (see above).</t>
<t hangText="Querying node:">The node MUST restart the GIST
handshake from the beginning, with a new Query.</t>
<t hangText="Responding node:">The node MUST delete its own
routing state and SHOULD report an error condition to the local
signalling application.</t>
</list>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. <xref
target="I-D.ietf-tcpm-tcpsecure"></xref>), 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.</t>
</section>
</section>
</section>
<section anchor="message" title="Message Formats and Transport">
<section anchor="message-overview" title="GIST Messages">
<t>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
<xref target="RFC4234" />; a more detailed description of the header
and each object is given in <xref target="formats" /> and bit formats
in <xref target="bit-formats" />. 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 <xref target="nat" />.</t>
<t>GIST-Message: The primary messages are either part of the three-way
handshake, or a simple message carrying NSLP data. Additional types
are defined for errors and keeping messaging associations alive.</t>
<artwork><![CDATA[ GIST-Message = Query / Response / Confirm /
Data / Error / MA-Hello]]></artwork>
<t>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 (<xref
target="error-object-type-error" />).</t>
<t>Query: A Query MUST be sent in D-mode using the special Q-mode
encapsulation. In addition to the common header, it contains certain
mandatory control objects, and MAY contain a signalling application
payload. A stack proposal and configuration data MUST be included if
the message exchange relates to setup of a messaging association. The
R flag MUST always be set (R=1) in a Query, since this message always
elicits a Response.</t>
<artwork><![CDATA[ Query = Common-Header
[ NAT-Traversal-Object ]
Message-Routing-Information
Session-Identification
Network-Layer-Information
Query-Cookie
[ Stack-Proposal Stack-Configuration-Data ]
[ NSLP-Data ]]]></artwork>
<t>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
Network-Layer-Information. If the message exchange relates to setup of
a new messaging association, which MUST involve a D-mode Response, a
Responder cookie MUST be included, as well as the Responder's own
stack proposal and configuration data. The R flag MUST be set (R=1) if
a Responder cookie is present but otherwise is optional; if the R flag
is set, a Confirm MUST be sent as a reply. Therefore, in particular, a
Confirm will always be required if a new MA is being set up. Note that
the direction of this MRI will be inverted compared to that in the
Query, that is, an upstream MRI becomes downstream and vice versa (see
<xref target="mrms" />).</t>
<artwork><![CDATA[ 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 ]]]></artwork>
<t>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 used, the Confirm MUST be sent in D-mode. The
Confirm MUST include the MRI (with inverted direction) and SID, and
echo the Responder-Cookie if the Response carried one. In C-mode, the
Confirm MUST also echo the Stack-Proposal from the Response (if
present) so it can be verified that this has not been tampered with.
The first Confirm on a new association MUST also repeat the
Stack-Configuration-Data from the original Query in an abbreviated
form, just containing the MA-Hold-Time.</t>
<artwork><![CDATA[ Confirm = Common-Header
Message-Routing-Information
Session-Identification
Network-Layer-Information
[ Responder-Cookie
[ Stack-Proposal
[ Stack-Configuration-Data ] ] ]
[ NSLP-Data ]]]></artwork>
<t>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.</t>
<artwork><![CDATA[ Data = Common-Header
[ NAT-Traversal-Object ]
Message-Routing-Information
Session-Identification
[ Network-Layer-Information ]
NSLP-Data]]></artwork>
<t>Error: An Error message reports a problem determined at the GIST
level. (Errors generated by signalling applications are reported in
NSLP-Data payloads and are not treated specially by GIST.) If the
message is being sent in D-mode, the originator of the error message
MUST include its own Network-Layer-Information object. All other
information related to the error is carried in a GIST-Error-Data
object.</t>
<artwork><![CDATA[ Error = Common-Header
[ NAT-Traversal-Object ]
[ Network-Layer-Information ]
GIST-Error-Data]]></artwork>
<t>MA-Hello: This message MUST be sent only in C-mode. It contains the
common header, with a NSLPID of zero, and a message identifier, the
Hello-ID. It always indicates that a node wishes to keep a messaging
association open, and if sent with R=0 and zero Hello-ID this is its
only function. A node MAY also invoke a diagnostic request/reply
exchange by setting R=1 and providing a non-zero Hello-ID; 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.</t>
<artwork><![CDATA[ MA-Hello = Common-Header
Hello-ID]]></artwork>
</section>
<section anchor="formats" title="Information Elements">
<t>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 <xref
target="bit-formats"></xref>.</t>
<section anchor="common-header" title="The Common Header">
<t>Each message begins with a fixed format common header, which
contains the following information:<list style="hanging">
<t hangText="Version:">The version number of the GIST protocol.
This specification defines GIST version 1.</t>
<t hangText="GIST hop count:">A hop count to prevent a message
from looping indefinitely.</t>
<t hangText="Length:">The number of 32 bit words in the message
following the common header.</t>
<t hangText="Upper layer identifier (NSLPID):">This gives the
specific NSLP that this message is used for.</t>
<t hangText="Message type:">The message type (Query, Response,
etc.)</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="Explicit routing:">A flag which if set (E=1)
indicates that the message was explicitly routed (see <xref
target="nslp-reroute"></xref>).</t>
</list>Note that in D-mode, <xref target="d-transport"></xref>,
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.</t>
</section>
<section anchor="tlvs" title="TLV Objects">
<t>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).<list
style="hanging">
<t hangText="Message-Routing-Information (MRI):">Information
sufficient to define how the signalling message should be routed
through the network. <artwork><![CDATA[
Message-Routing-Information = message-routing-method
method-specific-information
]]></artwork>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 <xref target="mrms" />).
It is provided by the NSLP in the message sender and used by
GIST to select the message routing.</t>
<t hangText="Session-Identification (SID):">The GIST session
identifier is a 128 bit, cryptographically random identifier
chosen by the node which originates the signalling exchange. See
<xref target="sids"></xref>.</t>
<t hangText="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. <artwork><![CDATA[
Network-Layer-Information = peer-identity
interface-address
RS-validity-time
IP-TTL
]]></artwork>The use of the RS-validity-time field is described in <xref
target="maint-procedures" />. The peer-identity and
interface-address are used for matching existing associations,
as discussed in <xref target="ma-reuse" />. <vspace
blankLines="1" />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 (<xref target="legacy-nat-overview" />).
If this object is carried in a Query or Confirm, the
interface-address MUST specifically be set to an address bound
to an interface associated with the MRI, to allow its use in
route change handling as discussed in <xref
target="route-change" />. 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.<vspace blankLines="1" />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.<list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>On receiving an upstream message, the IP-TTL is stored as
the IP-hop-count-to-peer for the downstream peer.</t>
</list>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.</t>
<t hangText="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 <xref target="ma-setup" />.
<artwork><![CDATA[
Stack-Proposal = 1*stack-profile
stack-profile = 1*protocol-layer
]]></artwork>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).</t>
<t hangText="Stack-Configuration-Data (SCD):">This object
carries information about the overall configuration of a
messaging association. <artwork><![CDATA[
Stack-Configuration-Data = MA-Hold-Time
0*MA-protocol-options
]]></artwork>The MA-Hold-Time field indicates how long a node will hold open
an inactive association; see <xref target="ma-maint" /> 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 <xref target="ma-setup" />.</t>
<t hangText="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 <xref
target="cookies"></xref> for further details on requirements and
mechanisms for cookie generation.</t>
<t hangText="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 (<xref
target="error-object-value-error"></xref>) 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.</t>
<t hangText="NSLP-Data:">The NSLP payload to be delivered to the
signalling application. GIST does not interpret the payload
content.</t>
<t hangText="GIST-Error-Data:">This contains the information to
report the cause and context of an error. <artwork><![CDATA[
GIST-Error-Data = error-class error-code error-subcode
common-error-header
[ Message-Routing-Information-content ]
[ Session-Identification-content ]
0*additional-information
[ comment ]
]]></artwork>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 <xref
target="error-formats" />. 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.</t>
</list></t>
</section>
</section>
<section anchor="d-transport" title="D-mode Transport">
<t>This section describes the various encapsulation options for D-mode
messages. Although there are several possibilities, depending on
message type, MRM, and local policy, the general design principle is
that the sole purpose of the encapsulation is to ensure that the
message is delivered to or intercepted at the correct peer. Beyond
that, minimal significance is attached to the type of encapsulation or
the values of addresses or ports used for it. This allows new options
to be developed in the future to handle particular deployment
requirements without modifying the overall protocol specification.</t>
<section anchor="d-normal-encaps" title="Normal Encapsulation">
<t>Normal encapsulation MUST be used for all D-mode messages where
the signalling peer is already known from previous signalling. This
includes Response and Confirm messages, and Data messages except if
these are being sent without using local routing state. Normal
encapsulation is simple: the message is carried in a single UDP
datagram. UDP checksums MUST be enabled. The UDP payload MUST always
begin with a 32 bit magic number with value 0x4e04 bda5 in network
byte order; this is followed by the GIST common header and the
complete set of payloads. If the magic number is not present, the
message MUST be silently dropped. The normal encapsulation is shown
in outline in <xref target="norm-box"></xref>.</t>
<figure anchor="norm-box" title="Normal Encapsulation Packet Format">
<preamble></preamble>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IP Header //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// UDP Header //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GIST Magic Number (0x4e04bda5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// GIST Common Header //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// GIST Payloads //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<postamble></postamble>
</figure>
<t>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
<xref target="ssetup"></xref>. 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 <xref
target="legacy-nat-overview"></xref>.</t>
</section>
<section anchor="q-encaps" title="Q-mode Encapsulation">
<t>Q-mode encapsulation MUST be used for messages where no routing
state is available or where the routing state is being refreshed, in
particular for Query messages. Q-mode can also be used when
requested by local policy. Q-mode encapsulation is similar to normal
encapsulation, with changes in IP address selection, IP options, and
a defined method for selecting UDP ports.</t>
<section anchor="q-mode-v4"
title="Encapsulation and Interception in IPv4">
<t>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 <xref
target="legacy-nat-overview"></xref>.</t>
<t>Current MRMs define the use of a Router Alert Option <xref
target="RFC2113"></xref> to assist the peer in intercepting the
message depending on the NSLPID. If the MRM defines the use of
RAO, the sender MUST include it unless it has been specifically
configured not to (see below). A node MAY make the initial
interception decision based purely on IP-Protocol number transport
header analysis. Implementations MAY provide an option to disable
the setting of RAO on Q-mode packets on a per-destination prefix
basis; however, the option MUST be disabled by default and MUST
only be enabled when it has been separately verified that the 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 <xref
target="rao-nasties"></xref>.</t>
<t>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 ICMP "packet too large"
messages will be sent to the source address of the original IP
datagram, and since all MRM definitions recommend S=1 for at least
some retransmissions, ICMP errors related to fragmentation will be
seen at the Querying node.</t>
<t>The upper layer protocol, identified by the IP-Protocol field
in the IP header, MUST be UDP.</t>
</section>
<section title="Encapsulation and Interception in IPv6">
<t>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 <xref
target="legacy-nat-overview"></xref>.</t>
<t>For all current MRMs, the IP header is given a Router Alert
Option <xref target="RFC2711"></xref> 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.</t>
<t>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.</t>
</section>
<section anchor="q-mode-upper"
title="Upper Layer Encapsulation and Overall Interception Requirements">
<t>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.</t>
<t>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 <xref
target="iana"></xref>). 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.</t>
<t>Within the network, there may be packets using the GIST UDP
port but which are not in fact GIST traffic. Q-mode packets carry
the same magic number as other D-mode packets (see <xref
target="d-normal-encaps"></xref>). A Q-mode packet intercepted
within the network which does not match both the UDP destination
port and the magic number MUST be forwarded transparently at the
IP layer, regardless of any RAO value it contains. 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. If a Q-mode packet
is received at an end system (i.e. the at the destination address
of the IP datagram), if it does not start with the correct magic
number it MUST be silently dropped as in the D-mode case.</t>
</section>
<section title="IP Option Processing">
<t>For both IPv4 and IPv6, for Q-mode packets with IP options
allowed by the above requirements, IP options processing is
intended to be carried out independently of GIST processing. Note
that for the options allowed by the above rules, the option
semantics are independent of the payload: UDP payload
modifications are not prevented by the options and do not affect
the option content, and conversely the presence of the options
does not affect the UDP payload.</t>
<t>On packets originated by GIST, IP options MAY be added
according to node-local policies on outgoing IP data. On packets
forwarded by GIST without NSLP processing, IP options MUST be
processed as for a normally forwarded IP packet. On packets
locally delivered to the NSLP, the IP options MAY be passed to the
NSLP and equivalent options used on subsequently generated
outgoing Q-mode packets. In this case, routing related options
SHOULD be processed identically as they would be for a normally
forwarded IP packet.</t>
</section>
</section>
<section anchor="rate-control" title="Retransmission and Rate Control">
<t>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.</t>
<t>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. Nodes MAY use smaller values of
T1 if it is known that the Query should be answered within the local
network. T1 MAY be chosen larger, and this is RECOMMENDED if it is
known in advance (such as on high latency access links) that the
round-trip time is larger. The default value of T2 is 64*T1. Note
that Queries may go unanswered either because of message loss (in
either direction), or because there is no reachable GIST peer.
Therefore, implementations MAY trade off reliability (large T2)
against promptness of error feedback to applications (small T2). If
the NSLP has indicated a timeout on the validity of this payload
(see <xref target="api-sendmessage"></xref>), T2 MUST be chosen so
that the process terminates within this timeout. Retransmitted
Queries MUST use different Query-Cookie values. If the Query carries
NSLP data, it may be delivered multiple times to the signalling
application. These rules apply equally to the message that first
creates routing state, and those that refresh it. In all cases,
Responses MUST be sent promptly to avoid spurious retransmissions.
Nodes generating any type of retransmission MUST be prepared to
receive and match a reply to any of them, not just the one most
recently sent. Although a node SHOULD terminate its retransmission
process when any reply is received, it MUST continue to process
further replies as normal.</t>
<t>This algorithm is sufficient to handle lost Queries and
Responses. The case of a lost Confirm is more subtle. The Responding
node MAY run a retransmission timer to resend the Response until a
Confirm is received; the timer MUST use the same backoff mechanism
and parameters as for Responses. The problem of an amplification
attack stimulated by a malicious Query is handled by requiring the
cookie mechanism to enable the node receiving the Response to
discard it efficiently if it does not match a previously sent Query.
This approach is only appropriate if the Responding node is prepared
to store per-flow state after receiving a single (Query) message,
which includes the case where the node has queued NSLP data. If the
Responding node has delayed state installation, the error condition
will only be detected when a Data message arrives. This is handled
as a routing state error (see <xref
target="routing-state-failures"></xref>) which causes the Querying
node to restart the handshake.</t>
<t>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 they MAY be dropped
with an error condition indicated back to local signalling
applications. In either case, the effect of this will be to reduce
the rate at which new transactions can be initiated by signalling
applications, thereby reducing the load on the network.</t>
<t>The rate limiting mechanism is implementation-defined, but it is
RECOMMENDED that a token bucket limiter as described in <xref
target="RFC4443"></xref> 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. Note that, according to
the rules of <xref target="message-transmission"></xref>, in general
D-mode SHOULD only be used for Queries and Responses rather than
normal signalling traffic unless capacity for normal signalling
traffic can be engineered.</t>
</section>
</section>
<section anchor="c-transport" title="C-mode Transport">
<t>It is a requirement of the NTLP defined in <xref
target="RFC4080"></xref> 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 can be carried out by GIST during message
construction. Either way, two approaches can be distinguished:<list
style="numbers">
<t>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.</t>
<t>Messages awaiting transmission are gathered together while the
node is not allowed to send them, for example because it is
congestion controlled.</t>
</list>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 (<xref
target="mtas"></xref>).</t>
<t>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.</t>
</section>
<section anchor="encaps-table"
title="Message Type/Encapsulation Relationships">
<t>GIST has four primary message types (Query, Response, Confirm, and
Data) and three possible encapsulation methods (normal D-mode, Q-mode,
and C-mode). The combinations of message type and encapsulation which
are allowed for message transmission are given in the table below. In
some cases there are several possible choices, depending on the
existence of routing state or messaging associations. The rules
governing GIST policy, including whether or not to create such state
to handle a message, are described normatively in the other sections
of this specification. If a message which can only be sent in Q/D-mode
arrives in C-mode or vice versa, this MUST be rejected with an
"Incorrect Encapsulation" error message (<xref
target="error-incorrect-encapsulation"></xref>). However, it should be
noted that the processing of the message at the receiver is not
otherwise affected by the encapsulation method used, except that the
decapsulation process may provide additional information, such as
translated addresses or IP hop count to be used in the subsequent
message processing.</t>
<texttable>
<ttcol align="center">Message</ttcol>
<ttcol align="center">Normal D-mode</ttcol>
<ttcol align="center">Query D-mode (Q-mode)</ttcol>
<ttcol align="center">C-mode</ttcol>
<c>Query</c>
<c>Never</c>
<c>Always</c>
<c>Never</c>
<c>Response</c>
<c>Unless a messaging association is being re-used</c>
<c>Never</c>
<c>If a messaging association is being re-used</c>
<c>Confirm</c>
<c>Only if no messaging association has been set up or is being
re-used</c>
<c>Never</c>
<c>If a messaging association has been set up or is being
re-used</c>
<c>Data</c>
<c>If routing state exists for the flow but no messaging
association</c>
<c>If the MRI can be used to derive the Q-mode encapsulation, and
either no routing state exists or local policy requires Q-mode</c>
<c>If a messaging association exists</c>
</texttable>
</section>
<section anchor="error-proc" title="Error Message Processing">
<t>Special rules apply to the encapsulation and transmission of error
messages.</t>
<t>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.<list
style="symbols">
<t>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.</t>
<t>If the incoming message was received over a messaging
association, the error MUST be sent back over the same messaging
association.</t>
</list>The NSLPID in the common header of the Error message has the
value zero. If for any reason the message cannot be sent (for example,
because it is too large to send in D-mode, or because the MA over
which the original message arrived has since been closed) an error
SHOULD be logged locally. The receiver of the Error message can infer
the NSLPID for the message that caused the error from the Common
Header that is embedded in the Error object.</t>
</section>
<section anchor="ma-setup" title="Messaging Association Setup">
<section anchor="ma-overview" title="Overview">
<t>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.</t>
<t>Capability discovery is carried out in Query and Response
messages, using Stack-Proposal and Stack-Configuration-Data (SCD)
objects. If a new messaging association is required it is then set
up, followed by a Confirm. Messaging association multiplexing is
achieved by short-circuiting this exchange by sending the Response
or Confirm messages on an existing association (<xref
target="ma-reuse"></xref>); 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.</t>
<t>Every possible protocol for a messaging association has the
following attributes:<list style="symbols">
<t>MA-Protocol-ID, a 1-byte IANA assigned value (see <xref
target="iana"></xref>).</t>
<t>A specification of the (non-negotiable) policies about how
the protocol should be used; for example, in which direction a
connection should be opened.</t>
<t>[Depending on the specific protocol:] Formats for an
MA-protocol-options field to carry the protocol addressing and
other configuration information in the SCD object. The format
may differ depending on whether the field is present in the
Query or Response. Some protocols do not require the definition
of such additional data, in which case no corresponding
MA-protocol-options field will occur in the SCD object.</t>
</list>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 SCD 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 for example be used to carry
different port numbers for TCP depending on whether it is to be used
with or without TLS. An message flow which shows several of the
features of Stack-Proposal and Stack-Configuration-Data formats can
be found in <xref target="example-flow"></xref>.</t>
<t>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 SCD are both present but not consistent, for example, if they
refer to different protocols, or an MA-protocol-options field refers
to a non-existent profile, an "Object Value Error" message (<xref
target="error-object-value-error"></xref>) with subcode 5
("Stack-Proposal - Stack-Configuration-Data Mismatch") MUST be
returned and the message dropped.</t>
<t>A node generating a SCD object MUST honour the implied protocol
configurations for the period during which a messaging association
might be set up; in particular, it MUST be immediately prepared to
accept incoming datagrams or connections at the protocol/port
combinations advertised. This MAY require the creation of listening
endpoints for the transport and security protocols in question, or a
node MAY keep a pool of such endpoints open for extended periods.
However, the received object contents MUST be retained only for the
duration of the Query/Response exchange and to allow any necessary
association setup to complete. They may become invalid because of
expired bindings at intermediate NATs, or because the advertising
node is using agile ports. Once the setup is complete, or if it is
not necessary, or fails for some reason, the object contents MUST be
discarded. A default time of 30 seconds to keep the contents is
RECOMMENDED.</t>
<t>A Query requesting messaging association setup always contains a
Stack-Proposal and SCD object. The Stack-Proposal MUST only include
protocol configurations that are suitable for the transfer
attributes of the messages that the Querying node wishes to use the
messaging association for. For example, it should not simply include
all configurations that the Querying node is capable of
supporting.</t>
<t>The Response always contains a Stack-Proposal and SCD object,
unless multiplexing (where the Responder decides to use an existing
association) occurs. For such a Response, the security protocols
listed in the Stack-Proposal MUST NOT depend on the Query. A node
MAY make different proposals depending on the combination of
interface and NSLPID. If multiplexing does occur, which is indicated
by sending the Response over an existing messaging association, the
following rules apply:<list style="symbols">
<t>The re-used messaging association MUST NOT have weaker
security properties than all of the options that would have been
offered in the full Response that would have been sent without
re-use.</t>
<t>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.</t>
</list>Once the messaging association is set up, the Querying node
repeats the responder's Stack-Proposal over it in the Confirm. The
responding node MUST verify that this has not been changed as part
of bidding-down attack prevention, as well as verifying the
Responder cookie (<xref target="cookies"></xref>). If either check
fails, the responding node MUST NOT NOT create the message routing
state (or MUST delete it if it already exists) and SHOULD log an
error condition locally. If this is the first message on a new MA,
the MA MUST be torn down. See <xref target="sec-proto"></xref> for
further discussion.</t>
</section>
<section anchor="ma-ftcp" title="Protocol Definition: Forwards-TCP">
<t>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:<list style="symbols">
<t>in a Query: no information apart from the field header.</t>
<t>in a Response: 2 byte port number at which the connection
will be accepted, followed by 2 pad bytes.</t>
</list>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.</t>
<t>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 <xref target="mtas"></xref>.</t>
</section>
<section anchor="ma-tls"
title="Protocol Definition: Transport Layer Security">
<t>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 <xref
target="RFC2246"></xref> and MUST use the highest protocol version
supported by both peers. Implementation of TLS1.1 <xref
target="RFC4346"></xref> 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.</t>
<t>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.</t>
<t>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 <xref target="RFC4279"></xref>. 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.</t>
<t>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.</t>
<section anchor="tls-identity-matching"
title="Identity Checking in TLS">
<t>After TLS authentication, a node MUST check the identity
presented by the peer in order to avoid man-in-the-middle attacks,
and verify that the peer is authorised to take part in signalling
at the GIST layer. The authorisation check is carried out by
comparing the presented identity with each Authorised Peer
Database (APD) entry in turn, as discussed in <xref
target="signalling-peer-authorisation"></xref>. This section
defines the identity comparison algorithm for a single APD
entry.</t>
<t>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.</t>
<t>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 <xref target="RFC3280"></xref> 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).</t>
<t>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.</t>
</section>
</section>
</section>
<section anchor="mrm-specs" title="Specific Message Routing Methods">
<t>Each message routing method (see <xref target="mrms"></xref>)
requires the definition of the format of the message routing
information (MRI) and Q-mode encapsulation rules. These are given in
the following subsections for the MRMs currently defined. A GIST
implementation on a node MUST support whatever MRMs are required by
the NSLPs on that node; GIST implementations SHOULD provide support
for both the MRMs defined here, in order to minimise deployment
barriers for new signalling applications that need them.</t>
<section title="The Path-Coupled MRM">
<section anchor="pc-mri" title="Message Routing Information">
<t>For the path-coupled MRM, this is conceptually the Flow
Identifier as in the NSIS Framework <xref target="RFC4080" />.
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 <xref target="bypass" /> and <xref target="nat" /> for
further discussion). <artwork><![CDATA[
MRI = network-layer-version
source-address prefix-length
destination-address prefix-length
IP-protocol
diffserv-codepoint
[ flow-label ]
[ ipsec-SPI / L4-ports]
]]></artwork> 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.</t>
<t>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 (<xref target="error-object-value-error"></xref>)
with subcodes 1 ("Value Not Supported") or 2 ("Invalid Flag-Field
Combination") and drop the message.</t>
</section>
<section anchor="pc-downstream"
title="Downstream Q-mode Encapsulation">
<t>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.<list style="symbols">
<t>The destination IP address MUST be the flow destination
address as given in the MRI of the message payload.</t>
<t>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:<list
style="symbols">
<t>In order to receive ICMP error messages about the
signalling message, such as unreachable port or address.
If these are delivered to the flow source rather than the
signalling source, it will be very difficult for the
querying node to detect that it is the last GIST node on
the path. Another case is where there is an abnormally low
MTU along the path, in which case the querying node needs
to see the ICMP error (recall that Q-mode packets are sent
with DF set).</t>
<t>In order to receive GIST Error messages where the error
message sender could not interpret the NLI in the original
message.</t>
<t>In order to attempt to run GIST through an unmodified
NAT, which will only process and translate IP addresses in
the IP header (see <xref
target="legacy-nat-overview"></xref>).</t>
</list>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.</t>
</list>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.</t>
<t>A GIST implementation SHOULD apply validation checks to the
MRI, to reject Query messages that are being injected by nodes
with no legitimate interest in the flow being signalled for. In
general, if the GIST node can detect that no flow could arrive
over the same interface as the Query, it MUST be rejected with an
appropriate error message. Such checks apply only to messages with
the Q-mode encapsulation, since only those messages are required
to track the flow path. The main checks are that the IP version
used in the encapsulation should match that of the MRI and the
version(s) used on that interface, and that the full range of
source addresses (the source-address masked with its
prefix-length) would pass ingress filtering checks. For these
cases, the error message is "MRI Validation Failure" (<xref
target="error-mri-validation-failure"></xref>) with subcodes 1 or
2 ("IP Version Mismatch" or "Ingress Filter Failure")
respectively.</t>
</section>
<section anchor="pc-upstream" title="Upstream Q-mode Encapsulation">
<t>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.</t>
<t>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:<list style="symbols">
<t>The upstream GIST peer is 1 IP hop away, and can be reached
by tracing back through the interface on which the flow
arrives.</t>
<t>The upstream peer is a border router of a single-homed
(stub) network.</t>
</list>This section defines an upstream Q-mode encapsulation and
validation checks for when it can be used. The functionality to
generate upstream Queries is OPTIONAL, but if received they MUST
be processed in the normal way with some additional IP TTL checks.
No special functionality is needed for this.</t>
<t>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.</t>
<t>The details of the encapsulation are as follows:<list
style="symbols">
<t>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).</t>
<t>The source address SHOULD be the signalling node address,
so in the common header S=1.</t>
<t>A router alert option is included as in the downstream
case.</t>
<t>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.</t>
<t>The IP layer TTL of the message MUST be set to 255.</t>
</list>The sending GIST implementation SHOULD attempt to send
the Query via the same interface and to the same link layer
neighbour from which the data packets of the flow are
arriving.</t>
<t>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 (<xref
target="error-invalid-ip-layer-ttl"></xref>). This can be
determined by examining the received IP layer TTL, similar to the
generalised IP TTL security mechanism described in <xref
target="RFC3682"></xref>. 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.</t>
</section>
</section>
<section anchor="le-mrm" title="The Loose-End MRM">
<t>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 <xref
target="I-D.ietf-nsis-nslp-natfw"></xref>.</t>
<section title="Message Routing Information">
<t>For the loose-end MRM, only a simplified version of the Flow
Identifier is needed.</t>
<artwork><![CDATA[
MRI = network-layer-version
source-address
destination-address]]></artwork>
<t>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.</t>
</section>
<section anchor="le-downstream"
title="Downstream Q-mode Encapsulation">
<t>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:<list style="symbols">
<t>The IP destination address MUST be the destination address
as given in the MRI of the message payload.</t>
<t>By default, the IP source address is the source address
from the MRI (S=0). However, the use of the signalling source
address (S=1) is allowed as in the case of the path-coupled
MRM.</t>
</list>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.</t>
</section>
</section>
</section>
</section>
<section anchor="formal" title="Formal Protocol Specification">
<t>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 <xref
target="route-change"></xref>. A more detailed description of the GIST
protocol operation in state machine syntax can be found in <xref
target="I-D.ietf-nsis-ntlp-statemachine"></xref>.</t>
<t>Conceptually, GIST processing at a node may be seen in terms of four
types of cooperating state machine:<list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Messaging associations have their own lifecycle, represented by
an 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.</t>
</list>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 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.</t>
<t>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. <texttable
title="Incoming Events">
<ttcol width="30%">Name</ttcol>
<ttcol>Meaning</ttcol>
<c>rx_Query</c>
<c>A Query has been received.</c>
<c>rx_Response</c>
<c>A Response has been received.</c>
<c>rx_Confirm</c>
<c>A Confirm has been received.</c>
<c>rx_Data</c>
<c>A Data message has been received.</c>
<c>rx_Message</c>
<c>rx_Query||rx_Response||rx_Confirm||rx_Data.</c>
<c>rx_MA-Hello</c>
<c>A MA-Hello message has been received.</c>
<c>tg_NSLPData</c>
<c>A signalling application has requested data transfer (via API
SendMessage).</c>
<c>tg_Connected</c>
<c>The protocol stack for a messaging association has completed
connecting.</c>
<c>tg_RawData</c>
<c>GIST wishes to transfer data over a particular messaging
association.</c>
<c>tg_MAIdle</c>
<c>GIST decides that it is no longer necessary to keep an MA open
for itself.</c>
<c>er_NoRSM</c>
<c>A "No Routing State" error was received.</c>
<c>er_MAConnect</c>
<c>A messaging association protocol failed to complete a
connection.</c>
<c>er_MAFailure</c>
<c>A messaging association failed.</c>
</texttable></t>
<section anchor="node-sm" title="Node Processing">
<t>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:<list style="hanging">
<t hangText="Rule 1 (rx_Query):"><artwork><![CDATA[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]]></artwork></t>
<t hangText="Rule 2 (rx_Response):"><artwork><![CDATA[// a routing state error
discard message]]></artwork></t>
<t hangText="Rule 3 (rx_Confirm):"><artwork><![CDATA[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]]></artwork></t>
<t hangText="Rule 4 (rx_Data):"><artwork><![CDATA[if (node policy will only process Data messages with matching
routing state) then
send "No Routing State" error message
else
pass directly to NSLP]]></artwork></t>
<t hangText="Rule 4 (er_NoRSM):"><artwork><![CDATA[discard the message]]></artwork></t>
<t hangText="Rule 5 (tg_NSLPData):"><artwork><![CDATA[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]]></artwork></t>
</list></t>
</section>
<section anchor="q-sm" title="Query Node Processing">
<t>The Querying-Node state machine (Querying-SM) has three
states:<list style="symbols">
<t>Awaiting Response</t>
<t>Established</t>
<t>Awaiting Refresh</t>
</list>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 retransmit a Query for this reason.</t>
<t>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
refresh the routing state (as in Awaiting Response) but NSLP data can
be handled normally.</t>
<t>The timers relevant to this state machine are as follows:<list
style="hanging">
<t hangText="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 (see <xref target="maint-procedures"></xref>).</t>
<t hangText="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.</t>
<t hangText="Inactive_QNode:">Indicates that no NSLP 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.</t>
</list>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.</t>
<figure anchor="fig-qsm" title="Query Node State Machine">
<artwork><![CDATA[ [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)]]></artwork>
</figure>
<t>The processing rules are as follows:<list style="hanging">
<t hangText="Rule 1:">Store the message for later transmission</t>
<t hangText="Rule 2:"><artwork><![CDATA[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]]></artwork></t>
<t hangText="Rule 3:"><artwork><![CDATA[// Assume the Confirm was lost in transit or the peer has reset;]]></artwork><artwork><![CDATA[// restart the handshake
send Query
(re)start No_Response timer]]></artwork></t>
<t hangText="Rule 4:"><artwork><![CDATA[if a new MA-SM is needed create one
if the R flag was set send a Confirm
send any stored Data messages
stop No_Response timer
start Refresh_QNode timer
start Inactive_QNode timer if it was not running
if there was piggybacked NSLP-Data
pass it to the NSLP
restart Inactive_QNOde timer
]]></artwork></t>
<t hangText="Rule 5:"><artwork><![CDATA[send Data message
restart Inactive_QNode timer]]></artwork></t>
<t hangText="Rule 6:">Terminate</t>
<t hangText="Rule 7:"><artwork><![CDATA[pass any data to the NSLP
restart Inactive_QNode timer]]></artwork></t>
<t hangText="Rule 8:"><artwork><![CDATA[send Query
start No_Response timer
stop Refresh_QNode timer]]></artwork></t>
</list></t>
</section>
<section anchor="r-sm" title="Responder Node Processing">
<t>The Responding-Node state machine (Responding-SM) has three
states:<list style="symbols">
<t>Awaiting Confirm</t>
<t>Established</t>
<t>Awaiting Refresh</t>
</list>The policy governing the handling of Query messages and the
creation of the Responding-SM has three cases:<list style="numbers">
<t>No Confirm is required for a Query, and the state machine can
be created immediately.</t>
<t>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
Confirm is received.</t>
<t>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.</t>
</list>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.</t>
<t>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.</t>
<t>The timers relevant to the operation of this state machine are as
follows:<list style="hanging">
<t hangText="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. If this timer
fires, the routing state machine is deleted, regardless of whether
a No_Confirm timer is running.</t>
<t hangText="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.</t>
</list>The detailed state transitions and processing rules are
described below as in the Query node case.</t>
<figure anchor="fig-rsm" title="Responder Node State Machine">
<artwork><![CDATA[ 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)]]></artwork>
</figure>
<t>The processing rules are as follows:<list style="hanging">
<t hangText="Rule 1:"><artwork><![CDATA[// a Confirm is required
send Response with R=1
(re)start No_Confirm timer with the initial timer value]]></artwork></t>
<t hangText="Rule 2:"><artwork><![CDATA[pass any NSLP-Data object to the NSLP
start Expire_RNode timer]]></artwork></t>
<t hangText="Rule 3:">send the Data message</t>
<t hangText="Rule 4:">pass data to NSLP</t>
<t hangText="Rule 5:"><artwork><![CDATA[// no Confirm is required
send Response with R=0
start Expire_RNode timer]]></artwork></t>
<t hangText="Rule 6:"><artwork><![CDATA[drop incoming data
send "No Routing State" error message]]></artwork></t>
<t hangText="Rule 7:">store Data message</t>
<t hangText="Rule 8:"><artwork><![CDATA[pass any NSLP-Data object to the NSLP
send any stored Data messages
stop No_Confirm timer
start Expire_RNode timer]]></artwork></t>
<t hangText="Rule 9:"><artwork><![CDATA[if number of Responses sent has reached threshold
// nResp_isMax is true
destroy self
else
send Response
start No_Response timer]]></artwork></t>
<t hangText="Rule 10:"><artwork><![CDATA[// can happen e.g. a retransmitted Response causes a duplicate Confirm
silently ignore]]></artwork></t>
<t hangText="Rule 11:">destroy self</t>
</list></t>
</section>
<section anchor="ma-sm" title="Messaging Association Processing">
<t>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.</t>
<t>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 <xref
target="ma-maint"></xref>).</t>
<t>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.</t>
<t>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 (<xref target="api-networknotification"></xref>).</t>
<t>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.</t>
<t>The timers relevant to the operation of this state machine are as
follows:<list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
</list>The detailed state transitions and processing rules are
described below as in the Query node case.</t>
<figure anchor="fig-masm" title="Messaging Association State Machine">
<artwork><![CDATA[ [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)]]></artwork>
</figure>
<t>The processing rules are as follows:<list style="hanging">
<t hangText="Rule 1:"><artwork><![CDATA[pass message to transport layer
if the NoHello timer was running, stop it
(re)start SendHello]]></artwork></t>
<t hangText="Rule 2:"><artwork><![CDATA[pass message to Node-SM, or R-SM (for a Confirm),
or Q-SM (for a Response)
if the NoHello timer was running, stop it]]></artwork></t>
<t hangText="Rule 3:"><artwork><![CDATA[if reply requested
send MA-Hello
restart SendHello timer]]></artwork></t>
<t hangText="Rule 4:"><artwork><![CDATA[send MA-Hello message
restart SendHello timer]]></artwork></t>
<t hangText="Rule 5:">queue message for later transmission</t>
<t hangText="Rule 6:"><artwork><![CDATA[pass outstanding queued messages to transport layer
stop any timers controlling connection establishment
start SendHello timer]]></artwork></t>
<t hangText="Rule 7:"><artwork><![CDATA[stop SendHello timer
start NoHello timer]]></artwork></t>
<t hangText="Rule 8:"><artwork><![CDATA[report failure to routing state machines and signalling applications
destroy self]]></artwork></t>
<t hangText="Rule 9:"><artwork><![CDATA[if reply requested
send MA-Hello
restart NoHello timer]]></artwork></t>
</list></t>
</section>
</section>
<section anchor="advanced" title="Additional Protocol Features">
<section anchor="route-change" title="Route Changes and Local Repair">
<section anchor="route-change-intro" title="Introduction">
<t>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.</t>
<figure anchor="fig-reroute" title="A Re-Routing Event">
<artwork><![CDATA[
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]]></artwork>
</figure>
<t>Route change management is complicated by the distributed nature
of the problem. Consider the re-routing event shown in <xref
target="fig-reroute"></xref>. 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.</t>
<t>The NSIS framework <xref target="RFC4080"></xref> 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.</t>
</section>
<section anchor="route-change-mechanisms"
title="Route Change Detection Mechanisms">
<t>There are two aspects to detecting a route change at a single
node:<list style="symbols">
<t>Detecting that the outgoing path, in the direction of the
Query, has or may have changed.</t>
<t>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.</t>
</list></t>
<t>At a single node, these processes are largely independent,
although clearly a change in one direction at a node corresponds to
a change in 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).</t>
<t>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 subsections is intended to be universal.</t>
<t>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.<list style="hanging">
<t hangText="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.</t>
<t hangText="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 <xref
target="RFC2328"></xref> 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.</t>
<t hangText="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.</t>
<t hangText="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 (<xref
target="api-invalidateroutingstate"></xref>).</t>
<t hangText="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 <xref target="maint-procedures"></xref>. 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 between probes.</t>
</list></t>
<texttable>
<ttcol>Method</ttcol>
<ttcol>Query direction</ttcol>
<ttcol>Response direction</ttcol>
<c>Local Trigger</c>
<c>Discovers new interface (and peer if local)</c>
<c>Not applicable</c>
<c>Extended Trigger</c>
<c>Discovers new interface and may determine new peer</c>
<c>May determine that route from peer will have changed</c>
<c>C-mode Monitoring</c>
<c>Provides hint that change has occurred</c>
<c>Provides hint that change has occurred</c>
<c>Data Plane Monitoring</c>
<c>Not applicable</c>
<c>NSLP informs GIST that a change may have occurred</c>
<c>Probing</c>
<c>Discovers changed NLI in Response</c>
<c>Discovers changed NLI in Query</c>
</texttable>
</section>
<section anchor="reroute-support"
title="GIST Behaviour Supporting Re-Routing">
<t>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 <xref
target="load-splitting"></xref> below.) This classification applies
separately to the Querying and Responding node for each pair of GIST
peers. The levels are:<list style="hanging">
<t hangText="Bad:">The routing state is either missing
altogether, or not safe to use to send data.</t>
<t hangText="Tentative:">The routing state may have changed, but
it is still usable for sending NSLP data pending
verification.</t>
<t hangText="Good:">The routing state has been established and
no events affecting it have since been detected.</t>
</list></t>
<t>These classifications are not identical to the states described
in <xref target="formal"></xref>, but there are dependencies between
them. Specifically, routing state is considered Bad until the state
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 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.</t>
<t>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 (<xref
target="api-networknotification"></xref>), unless the change was
caused via the API in the first place.</t>
<t>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:<list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>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
SHOULD begin it if the upstream routing state is still known to be
Good.</t>
</section>
<section anchor="load-splitting"
title="Load Splitting and Route Flapping">
<t>The Q-mode encapsulation rules of <xref
target="mrm-specs"></xref> 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. For
example, a mobile node might be switching back and forth between two
links, or might appear to have disappeared even though it is still
attached to the network via a different route.</t>
<t>This specification does not define mechanisms for GIST to manage
multiple parallel routes or an unstable route; instead, GIST MAY
expose this to the NSLP, which can then manage it according to
signalling application requirements. 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 <xref target="api"></xref>.</t>
<t>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
(<xref target="format-common-header"></xref>). 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 (<xref target="api-recvmessage"></xref>). Signalling
applications should validate the source and effect of the message
themselves, and if appropriate should in particular indicate to GIST
(see <xref target="api-setstatelifetime"></xref>) that routing state
is no longer required for this flow. This is necessary to prevent
GIST in nodes on the old path initiating routing state refresh and
thus causing state conflicts at the crossover router.</t>
<t>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 (<xref
target="api-networknotification"></xref>). 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.</t>
</section>
<section anchor="nslp-reroute"
title="Signalling Application Operation">
<t>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.</t>
<t>The following outline description of a possible set of NSLP
actions takes the scenario of <xref target="fig-reroute"></xref> as
an example.<list style="numbers">
<t>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.</t>
<t>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 routing state to Tentative/Bad
automatically, and this will cause the signalling application to
propagate the notification further upstream.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="nat" title="NAT Traversal">
<t>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.</t>
<t>There is a dual problem of whether the GIST peers either side of
the 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 <xref
target="RFC3489"></xref> or TURN <xref
target="I-D.ietf-behave-turn"></xref> 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.</t>
<t>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 <xref
target="legacy-nat-overview"></xref> below. A more general solution
can be constructed using GIST-awareness in the NATs themselves; this
solution is outlined in <xref target="ga-nat-overview"></xref> with
processing rules in <xref target="nat-rules"></xref>.</t>
<t>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 <xref
target="RFC4787"></xref>, 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 <xref target="iana"></xref>).</t>
<section anchor="legacy-nat-overview" title="Legacy NAT Handling">
<t>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.</t>
<t>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.</t>
<t>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
retransmissions (see <xref target="mrm-specs"></xref>). 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 (<xref target="error-object-type-error"></xref>) 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.</t>
<t>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.</t>
<t>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 <xref
target="I-D.pashalidis-nsis-gist-legacynats"></xref>. Any such
traversal procedure MUST be incorporated into GIST using the
existing GIST extensibility capabilities. Note also that this
detection process only functions with the handshake exchange; it
cannot operate on simple Data messages, whether they are Q-mode or
normally encapsulated. Nodes SHOULD NOT send Data messages outside a
messaging association if they cannot ensure that they are operating
in an environment free of legacy NATs.</t>
</section>
<section anchor="ga-nat-overview" title="GIST-aware NAT Traversal">
<t>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 the MRI, 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
<xref target="format-mri"></xref>), it should reject the message
with an "Object Type Error" message (<xref
target="error-object-type-error"></xref>) with subcode 4
("Untranslated Object").</t>
<t>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.</t>
<t>The new object, the NAT-Traversal object (<xref
target="format-nto"></xref>), 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.</t>
<t>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, they use different MRI
values to refer to the same flow. However, subsequent messages after
the Query/Response (Data messages and the initial Confirm) need to
use a common MRI, since the NAT does not rewrite these, and this is
chosen to be the MRI of the Querying node. It is the responsibility
of the Responding node to translate between the two MRIs on inbound
and outbound messages, which is why the unmodified MRI is propagated
in the NAT-Traversal object.</t>
</section>
<section anchor="nat-rules" title="Message Processing Rules">
<t>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 <xref
target="I-D.pashalidis-nsis-gimps-nattraversal"></xref>.</t>
<t>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.<list style="numbers">
<t>Verify that bindings for any data flow are actually in
place.</t>
<t>Create a new Message-Routing-Information object with fields
modified according to the data flow bindings.</t>
<t>Create bindings for subsequent C-mode signalling based on the
information in the Network-Layer-Information and
Stack-Configuration-Data objects.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Forward the message with these new payloads.</t>
</list></t>
<t>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 (<xref target="error-object-type-error"></xref>) 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.</t>
<t>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:<list style="numbers">
<t>Verify the existence of bindings for the data flow.</t>
<t>Leave the Message-Routing-Information object unchanged.</t>
<t>Modify the NLI and SCD objects for the Responding node if
necessary, and create or update any bindings for C-mode
signalling traffic.</t>
<t>Forward the message.</t>
</list></t>
<t>A GIST node receiving such a message (Response or Error) 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.</t>
<t>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 <xref target="cookies"></xref> this is
automatic.</t>
</section>
</section>
<section anchor="tunnels" title="Interaction with IP Tunnelling">
<t>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.</t>
<t>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 place
and to carry out additional signalling if necessary; in other words,
at least one tunnel endpoint must be signalling application aware.</t>
<t>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 <xref
target="RFC2746"></xref>. 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.</t>
</section>
<section anchor="transition"
title="IPv4-IPv6 Transition and Interworking">
<t>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.<list
style="hanging">
<t hangText="Dual Stack:">(As described in <xref
target="RFC4213"></xref>.) 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 <xref target="tlvs"></xref>). Messages
with mismatching versions MUST be rejected with an "MRI Validation
Failure" error message (<xref
target="error-mri-validation-failure"></xref>) 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.</t>
<t hangText="Packet Translation:">(Applicable to SIIT <xref
target="RFC2765"></xref> and NAT-PT <xref
target="RFC2766"></xref>.) 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 <xref
target="nat"></xref>. 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 <xref
target="RFC2765"></xref>.</t>
<t hangText="Tunnelling:">(Applicable to 6to4 <xref
target="RFC3056"></xref>.) 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.<vspace blankLines="1" />From the GIST perspective, the
treatment should be similar to any other IP tunnelling mechanism,
as described in <xref target="tunnels"></xref>. 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, <xref
target="RFC3068"></xref> 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.</t>
</list></t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>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 <xref
target="RFC4081"></xref>; the NSIS framework <xref
target="RFC4080"></xref> assigns a subset of the responsibilities to the
NTLP. The main issues to be handled can be summarised as:<list
style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list>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.</t>
<t>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 <xref
target="ma-setup"></xref>.</t>
<section title="Message Confidentiality and Integrity">
<t>GIST can use messaging association functionality, specifically in
this version TLS (<xref target="ma-tls"></xref>), to ensure message
confidentiality 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.</t>
</section>
<section anchor="authentication" title="Peer Node Authentication">
<t>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.</t>
<t>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
<xref target="routing-integrity"></xref> below.</t>
<t>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 <xref target="api"></xref> 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.</t>
</section>
<section anchor="routing-integrity" title="Routing State Integrity">
<t>Internal state in a node (see <xref target="gist-state"></xref>) is
used to route messages. If this state is corrupted, signalling
messages may be misdirected.</t>
<t>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 <xref target="RFC4225"></xref>.</t>
<t>In one direction, peer identification is installed and refreshed
only on receiving a Response (compare <xref
target="fig-handshake"></xref>). 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.</t>
<t>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:<list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="Authorisation:">a stronger approach is to carry out a
peer authorisation check (see <xref
target="signalling-peer-authorisation"></xref>) 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 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.</t>
<t hangText="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.</t>
</list></t>
</section>
<section anchor="dos"
title="Denial of Service Prevention and Overload Protection">
<t>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 <xref
target="rate-control"></xref>.)</t>
<t>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.</t>
<t>We use a combination of two defences against these attacks:<list
style="numbers">
<t>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 gets
significantly larger if a new connection needs to be established
first.</t>
<t>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 <xref
target="RFC2960"></xref> and other modern protocols.</t>
</list></t>
<t>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 <xref target="local-proc"></xref>,
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.</t>
<t>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.</t>
<t>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 <xref
target="api-recvmessage"></xref>). 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 applications can also manage
overload by invoking flow control, as described in <xref
target="message-handling"></xref>.</t>
</section>
<section anchor="cookies" title="Requirements on Cookie Mechanisms ">
<t>The requirements on the Query cookie can be summarised as
follows:<list style="hanging">
<t hangText="Liveness:">The cookie must be live, that is, it must
change from one handshake to the next. To prevent replay
attacks.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list>Likewise, the requirements on the Responder cookie can be
summarised as follows:<list style="hanging">
<t hangText="Liveness:">The cookie must be live as above, to
prevent replay attacks.</t>
<t hangText="Creation simplicity:">The cookie must be lightweight
to generatem, to avoid resource exhaustion at the responding
node.</t>
<t hangText="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.</t>
<t hangText="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 Peer-Identity and Interface-Address given in the NLI
of the Query, and the MRI/NSLPID for the messaging. It also
includes the interface on which the Query was received (since a
Q-mode encapsulated message is the one that will best follow the
data path and so arrive on the correct interface).</t>
</list>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 <xref target="RFC4086" />.</t>
<t>A suitable basic implementation for the R-Cookie is as follows:</t>
<artwork><![CDATA[
R-Cookie = liveness data + reception interface
+ hash (locally known secret,
Q-Node NLI identity and address, MRI, NSLPID,
liveness data)]]></artwork>
<t>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. In the case of GIST-aware NAT traversal
with delayed state installation it is necessary to carry additional
data in the cookie; appropriate constructions are described in <xref
target="I-D.pashalidis-nsis-gimps-nattraversal" />.</t>
<t>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.</t>
<t>If a node receives a message for which cookie validation fails, it
MAY return an "Object Value Error" message (<xref
target="error-object-value-error" />) with subcode 4 ("Invalid
Cookie") to the sender and SHOULD log an error condition locally, 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.</t>
</section>
<section anchor="sec-proto" title="Security Protocol Selection Policy">
<t>This specification defines a single mandatory-to-implement security
protocol (TLS, <xref target="ma-tls"></xref>). 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 protocol for a messaging association is optional. Security
protocol selection is carried out as part of the GIST handshake
mechanism (<xref target="ssetup"></xref>).</t>
<t>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 <xref
target="RFC3329"></xref>):<list style="numbers">
<t>The Response does not depend on the Stack-Proposal in the Query
(see <xref target="ma-overview"></xref>). Therefore, tampering
with the Query has no effect on the resulting messaging
association configuration.</t>
<t>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.</t>
</list>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.</t>
</section>
<section anchor="residual" title="Residual Threats">
<t>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.</t>
<t>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
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.</t>
<t>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 <xref
target="RFC3852"></xref>.</t>
<t>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.</t>
<t>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 (<xref
target="sid-selection"></xref>). 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.</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>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.</t>
<t>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.</t>
<t>The allocation policies used in this section follow the guidance
given in <xref target="RFC2434"></xref>. In addition, for a number of
the GIST registries, this specification also defines
private/experimental ranges as discussed in <xref
target="RFC3692"></xref>. 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.</t>
<t>This specification allocates the following codepoints in existing
registries:<list>
<t>Well-known UDP port XXX as the destination port for Q-mode
encapsulated GIST messages (<xref target="d-transport"></xref>).</t>
</list></t>
<t>This specification creates the following registries with the
structures as defined below:<list style="hanging">
<t hangText="NSLP Identifiers:">Each signalling application requires
the assignment of one or more NSLPIDs. The following NSLPID is
allocated by this specification: <texttable>
<ttcol width="10%">NSLPID</ttcol>
<ttcol>Application</ttcol>
<c>0</c>
<c>Used for GIST messages not related to any signalling
application.</c>
</texttable>Every other NSLPID that uses an MRM which requires RAO
usage MUST be associated with a specific RAO value; multiple NSLPIDs
MAY be associated with the same RAO 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 <xref
target="reception" />, <xref target="bypass" /> and <xref
target="q-encaps" />. The NSLPID is a 16 bit integer, and allocation
policies for further values are as follows:<list style="hanging">
<t hangText="1-32703:">IESG Approval</t>
<t hangText="32704-32767:">Private/Experimental Use</t>
<t hangText="32768-65536:">Reserved - not to be allocated</t>
</list></t>
<t hangText="GIST Message Type:">The GIST common header (<xref
target="format-common-header" />) contains a 1 byte message type
field. The following values are allocated by this specification:
<texttable>
<ttcol width="10%">MType</ttcol>
<ttcol>Message</ttcol>
<c>0</c>
<c>Query</c>
<c>1</c>
<c>Response</c>
<c>2</c>
<c>Confirm</c>
<c>3</c>
<c>Data</c>
<c>4</c>
<c>Error</c>
<c>5</c>
<c>MA-Hello</c>
</texttable> Allocation policies for further values are as
follows:<list style="hanging">
<t hangText="6-63:">Standards Action</t>
<t hangText="64-119:">Expert Review</t>
<t hangText="120-127:">Private/Experimental Use</t>
<t hangText="128-255:">Reserved - not to be allocated</t>
</list></t>
<t hangText="Object Types:">There is a 12-bit field in the object
header (<xref target="format-general" />). The following values for
object type are defined by this specification: <texttable>
<ttcol width="10%">OType</ttcol>
<ttcol>Object Type</ttcol>
<c>0</c>
<c>Message Routing Information</c>
<c>1</c>
<c>Session ID</c>
<c>2</c>
<c>Network Layer Information</c>
<c>3</c>
<c>Stack Proposal</c>
<c>4</c>
<c>Stack Configuration Data</c>
<c>5</c>
<c>Query Cookie</c>
<c>6</c>
<c>Responder Cookie</c>
<c>7</c>
<c>NAT Traversal</c>
<c>8</c>
<c>NSLP Data</c>
<c>9</c>
<c>Error</c>
<c>10</c>
<c>Hello ID</c>
</texttable> Allocation policies for further values are as
follows:<list style="hanging">
<t hangText="10-1023:">Standards Action</t>
<t hangText="1024-1999:">Specification Required</t>
<t hangText="2000-2047:">Private/Experimental Use</t>
<t hangText="2048-4095:">Reserved - not to be allocated</t>
</list>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 <xref
target="format-extensibility" />).</t>
<t hangText="Message Routing Methods:">GIST allows multiple message
routing methods (see <xref target="mrms" />). The MRM is indicated
in the leading byte of the MRI object (<xref
target="format-mri" />). This specification defines the following
values: <texttable>
<ttcol width="15%">MRM-ID</ttcol>
<ttcol>Message Routing Method</ttcol>
<c>0</c>
<c>Path Coupled MRM</c>
<c>1</c>
<c>Loose End MRM</c>
</texttable> Allocation policies for further values are as
follows:<list style="hanging">
<t hangText="2-63:">Standards Action</t>
<t hangText="64-119:">Expert Review</t>
<t hangText="120-127:">Private/Experimental Use</t>
<t hangText="128-255:">Reserved - not to be allocated</t>
</list>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 <xref target="mrms" />.</t>
<t hangText="MA-Protocol-IDs:">Each protocol that can be used in a
messaging association is identified by a 1-byte MA-Protocol-ID
(<xref target="ma-setup" />). 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 (<xref target="format-stack-proposal" /> and <xref
target="format-stack-configuration-data" />). The following values
are defined by this specification: <texttable>
<ttcol width="30%">MA-Protocol-ID</ttcol>
<ttcol>Protocol</ttcol>
<c>0</c>
<c>Reserved - not to be allocated</c>
<c>1</c>
<c>TCP opened in the forwards direction</c>
<c>2</c>
<c>TLS initiated in the forwards direction</c>
</texttable> Allocation policies for further values are as
follows:<list style="hanging">
<t hangText="3-63:">Standards Action</t>
<t hangText="64-119:">Expert Review</t>
<t hangText="120-127:">Private/Experimental Use</t>
<t hangText="128-255:">Reserved - not to be allocated</t>
</list>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 <xref target="gist-security-services" />
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 which could be used with Transport Layer Security), the
specification MUST define the interaction between the two.</t>
<t hangText="Error Codes/Subcodes:">There is a 2 byte error code and
1 byte subcode in the Value field of the Error object (<xref
target="object-error"></xref>). Error codes 1-12 are defined in
<xref target="error-catalogue"></xref> 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:<list style="hanging">
<t hangText="Error case:">textual name of error</t>
<t hangText="Error class:">from the categories given in <xref
target="error-classes"></xref></t>
<t hangText="Error code:">allocated by IANA, if a new code is
required</t>
<t hangText="Error subcode:">subcode point, also allocated by
IANA</t>
<t hangText="Additional information:">what additional
information fields it is mandatory to include in the error
message, from <xref target="additional-info"></xref></t>
</list></t>
<t hangText="Additional Information Types:">An Error object (<xref
target="object-error"></xref>) may contain Additional Information
fields. Each possible field type is identified by a 16-bit AI-Type.
AI-Types 1-4 are defined in <xref target="additional-info"></xref>;
additional AI-Types are allocated on a first-come, first-served
basis.</t>
</list></t>
</section>
<section title="Acknowledgements">
<t>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, Vitor Bernado, Roland
Bless, Bob Braden, Marcus Brunner, Benoit Campedel, Yoshiko Chong, Luis
Cordeiro, Elwyn Davies, Michel Diaz, Christian Dickmann, Pasi Eronen,
Alan Ford, Xiaoming Fu, Bo Gao, Ruediger Geib, Eleanor Hepworth, Thomas
Herzog, Cheng Hong, Teemu Huovila, Jia Jia, Cornelia Kappler, Georgios
Karagiannis, Ruud Klaver, Chris Lang, Lauri Liuhto, 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,
Nuutti Varis, Michael Welzl, Lars Westberg, and Mayi Zoumaro-djayoon.
Parts of the TLS usage description (<xref target="ma-tls"></xref>) 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 Jari Arkko, 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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1122;
&rfc1812;
&rfc2113;
&rfc2119;
&rfc4307;
&rfc2434;
&rfc2474;
&rfc2711;
&rfc2765;
&rfc3280;
&rfc3692;
&rfc4234;
&rfc4346;
</references>
<references title="Informative References">
&rfc2205;
&rfc2246;
&rfc2328;
&rfc2746;
&rfc2766;
&rfc2960;
&rfc3056;
&rfc3068;
&rfc3175;
&rfc3260;
&rfc3329;
&rfc3489;
&I-D.ietf-behave-turn;
&rfc3682;
&rfc3852;
&rfc4080;
&rfc4081;
&rfc4086;
&rfc4279;
&rfc4443;
&I-D.ietf-nsis-nslp-natfw;
&rfc4213;
&rfc4301;
&rfc4225;
&rfc4787;
<reference anchor="floyd-sync">
<front>
<title>The Synchronisation of Periodic Routing Messages</title>
<author fullname="Sally Floyd" initials="S." surname="Floyd">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="September" year="1993" />
</front>
<seriesInfo name="SIGCOMM Symposium on Communications Architectures and Protocols"
value="pp. 33--44" />
</reference>
&I-D.pashalidis-nsis-gist-legacynats;
&I-D.pashalidis-nsis-gimps-nattraversal;
&I-D.ietf-nsis-ntlp-statemachine;
&I-D.ietf-tcpm-tcpsecure;
</references>
<section anchor="bit-formats" title="Bit-Level Formats and Error Messages">
<t>This appendix provides formats for the various component parts of the
GIST messages defined abstractly in <xref target="formats"></xref>. The
whole of this appendix is normative.</t>
<t>Each GIST message consists of a header and a sequence of objects. The
GIST header has a specific format, described in more detail in <xref
target="format-common-header"></xref> 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 <xref
target="format-general"></xref> below, followed in <xref
target="format-tlvs"></xref> by the format for each object. Finally,
<xref target="error-formats"></xref> provides the formats used for error
reporting.</t>
<t>In the following object diagrams, '//' is used to indicate a variable
sized field and ':' is used to indicate a field that is optionally
present.</t>
<section anchor="format-common-header" title="The GIST Common Header">
<t>This header begins all GIST messages. It has a fixed format, as
shown below.</t>
<artwork><![CDATA[
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t><list style="hanging">
<t hangText="Version (8 bits):">The GIST protocol version
number.</t>
<t hangText="GIST hops (8 bits):">A hop count for the number of
GIST-aware nodes this message can still be processed by (including
the destination).</t>
<t hangText="Message Length (16 bits):">The total number of 32-bit
words in the message after the common header itself.</t>
<t hangText="NSLPID (16 bits):">IANA assigned identifier of the
signalling application the message refers to.</t>
<t hangText="Type (8 bits):">The GIST message type (Query,
Response, etc.).</t>
<t hangText="S flag:">S=1 if the IP source address is the same as
the signalling source address, S=0 if it is different.</t>
<t hangText="R flag:">R=1 if a reply to this message is explicitly
requested.</t>
<t hangText="E flag:">E=1 if the message was explicitly routed
(<xref target="nslp-reroute" />).</t>
</list>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.</t>
<t>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 (<xref
target="error-common-header-parse-error" />) with the appropriate
subcode, and not process the message further.</t>
</section>
<section anchor="format-general" title="General Object Format">
<t>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.</t>
<artwork><![CDATA[
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t><list style="hanging">
<t hangText="A/B flags:">The bits marked 'A' and 'B' are
extensibility flags which are defined in <xref
target="format-extensibility" /> below; the remaining bits marked
'r' are reserved.</t>
<t hangText="Type (12 bits):">An IANA-assigned identifier for the
type of object.</t>
<t hangText="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 (<xref
target="error-object-value-error" />) with subcode 0 "Incorrect
Length" MUST be returned and the message dropped.</t>
<t hangText="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.</t>
</list>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.</t>
<section anchor="format-extensibility" title="Object Extensibility">
<t>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.<list style="hanging">
<t hangText="AB=00 ("Mandatory"):">If the object is
not understood, the entire message containing it MUST be
rejected with an "Object Type Error" message (<xref
target="error-object-type-error" />) with subcode 1
("Unrecognised Object").</t>
<t hangText="AB=01 ("Ignore"):">If the object is not
understood, it MUST be deleted and the rest of the message
processed as usual.</t>
<t hangText="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.</t>
</list>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 (<xref target="error-object-type-error" />) with
subcode 5 ("Invalid Extensibility Flags").</t>
<t>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.</t>
</section>
</section>
<section anchor="format-tlvs" title="GIST TLV Objects">
<section anchor="format-mri" title="Message-Routing-Information">
<t>
<list style="hanging">
<t hangText="Type:">Message-Routing-Information</t>
<t hangText="Length:">Variable (depends on MRM)</t>
</list>
</t>
<artwork><![CDATA[
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) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t><list style="hanging">
<t hangText="MRM-ID (8 bits):">An IANA-assigned identifier for
the message routing method.</t>
<t hangText="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.</t>
</list>The remainder of the object contains method-specific
addressing information, which is described below.</t>
<section anchor="format-mri-pcmrm" title="Path-Coupled MRM">
<t>In the case of basic path-coupled routing, the addressing
information takes the following format. The N-flag N=0 for this
MRM.</t>
<artwork><![CDATA[
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t><list style="hanging">
<t hangText="IP-Ver (4 bits):">The IP version number, 4 or
6.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="P flag:">P=1 means that the Protocol field is
significant.</t>
<t hangText="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>
<t hangText="T flag:">T=1 means that the DiffServ field
(DS-field) is significant.</t>
<t hangText="DS-field (6 bits):">The DiffServ field. See <xref
target="RFC2474" /> and <xref target="RFC3260" />.</t>
<t hangText="F flag:">F=1 means that flow label is present and
is significant. F MUST NOT be set if IP-Ver is not 6.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="SPI field (32 bits):">The SPI field; see <xref
target="RFC4301" />. If S=0, the entire 32 bit word containing
the SPI is absent.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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).</t>
</list>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 (<xref
target="error-object-value-error" />) with subcode 2 ("Invalid
Flag-Field Combination") MUST be returned.</t>
</section>
<section anchor="format-mri-lemrm" title="Loose-End MRM">
<t>In the case of the loose-end MRM, the addressing information
takes the following format. The N-flag N=0 for this MRM.</t>
<artwork><![CDATA[
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<t>
<list style="hanging">
<t hangText="IP-Ver (4 bits):">The IP version number, 4 or
6.</t>
<t hangText="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.</t>
<t hangText="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
<xref target="le-mrm" />).</t>
</list>
</t>
</section>
</section>
<section title="Session Identification">
<t>
<list style="hanging">
<t hangText="Type:">Session-Identification</t>
<t hangText="Length:">Fixed (4 32-bit words)</t>
</list>
</t>
<artwork><![CDATA[
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</section>
<section anchor="format-network-layer-information"
title="Network-Layer-Information">
<t>
<list style="hanging">
<t hangText="Type:">Network-Layer-Information</t>
<t hangText="Length:">Variable (depends on length of
Peer-Identity and IP version)</t>
</list>
</t>
<artwork><![CDATA[
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>
<list style="hanging">
<t hangText="PI-Length (8 bits):">The byte length of the Peer
Identity field.</t>
<t hangText="Peer Identity (variable):">The Peer Identity field.
Note that the Peer-Identity field itself is padded to a whole
number of words.</t>
<t hangText="IP-TTL (8 bits):">Initial or reported IP layer
TTL.</t>
<t hangText="IP-Ver (4 bits):">The IP version for the Interface
Address field.</t>
<t hangText="Interface Address (variable):">The IP address
allocated to the interface, matching the IP-Ver field.</t>
<t hangText="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.</t>
</list>
</t>
</section>
<section anchor="format-stack-proposal" title="Stack Proposal">
<t>
<list style="hanging">
<t hangText="Type:">Stack-Proposal</t>
<t hangText="Length:">Variable (depends on number of profiles
and size of each profile)</t>
</list>
</t>
<artwork><![CDATA[
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 N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prof-Count (8 bits): The number of profiles listed. MUST be > 0.
]]></artwork>
<t>Each profile is itself a sequence of protocol layers, and the
profile is formatted as a list as follows:<list style="symbols">
<t>The first byte is a count of the number of layers in the
profile. MUST be > 0.</t>
<t>This is followed by a sequence of 1-byte MA-Protocol-IDs as
described in <xref target="ma-setup" />.</t>
<t>The profile is padded to a word boundary with 0, 1, 2 or 3
zero bytes. These bytes MUST be ignored at the receiver.</t>
</list>If there are no profiles (Prof-Count=0) then an "Object
Value Error" message (<xref target="error-object-value-error" />)
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.</t>
</section>
<section anchor="format-stack-configuration-data"
title="Stack-Configuration-Data">
<t>
<list style="hanging">
<t hangText="Type:">Stack-Configuration-Data</t>
<t hangText="Length:">Variable (depends on number of protocols
and size of each MA-protocol-options field)</t>
</list>
</t>
<artwork><![CDATA[
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="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 (<xref target="ma-maint" />)
corresponds to a value of 30000. The value 0 (zero) is reserved
and MUST NOT be used.</t>
</list>The MA-protocol-options fields are formatted as
follows:</t>
<artwork><![CDATA[
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>
<list style="hanging">
<t hangText="MA-Protocol-ID (8 bits):">Protocol identifier as
described in <xref target="ma-setup" />.</t>
<t hangText="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'.</t>
<t hangText="Length (8 bits):">The byte length of
MA-protocol-options field that follows. This will be zero-padded
up to the next word boundary.</t>
<t hangText="D flag:">If set (D=1), this protocol MUST NOT be
used for a messaging association.</t>
<t hangText="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.</t>
</list>
</t>
</section>
<section title="Query Cookie">
<t>
<list style="hanging">
<t hangText="Type:">Query-Cookie</t>
<t hangText="Length:">Variable (selected by querying node)</t>
</list>
</t>
<artwork><![CDATA[
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>The contents are implementation defined. See <xref
target="cookies" /> for further discussion.</t>
</section>
<section title="Responder Cookie">
<t>
<list style="hanging">
<t hangText="Type:">Responder-Cookie</t>
<t hangText="Length:">Variable (selected by responding node)</t>
</list>
</t>
<artwork><![CDATA[
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>The contents are implementation defined. See <xref
target="cookies" /> for further discussion.</t>
</section>
<section anchor="format-hello-id" title="Hello-ID">
<t>
<list style="hanging">
<t hangText="Type:">Hello-ID</t>
<t hangText="Length:">Fixed (1 32-bit word)</t>
</list>
</t>
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>The contents are implementation defined. See <xref
target="tlvs" /> for further discussion.</t>
</section>
<section anchor="format-nto" title="NAT Traversal">
<t><list style="hanging">
<t hangText="Type:">NAT-Traversal</t>
<t hangText="Length:">Variable (depends on length of contained
fields)</t>
</list>This object is used to support the NAT traversal mechanisms
described in <xref target="ga-nat-overview" />.</t>
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>
<list style="hanging">
<t hangText="MRI-Length (8 bits):">The length of the included
MRI payload in 32- bit words.</t>
<t
hangText="Original Message-Routing-Information (variable):">The
MRI data from when the message was first sent, not including the
object header.</t>
<t hangText="Type-Count (8 bits):">The number of objects in the
'List of translated objects' field.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list>
</t>
</section>
<section anchor="format-nslp-data" title="NSLP Data">
<t><list style="hanging">
<t hangText="Type:">NSLP-Data</t>
<t hangText="Length:">Variable (depends on NSLP)</t>
</list>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.</t>
<artwork><![CDATA[
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</section>
</section>
<section anchor="error-formats" title="Errors">
<section anchor="object-error" title="Error Object">
<t>
<list style="hanging">
<t hangText="Type:">Error</t>
<t hangText="Length:">Variable (depends on error)</t>
</list>
</t>
<artwork><![CDATA[
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).]]></artwork>
<t>A GIST Error object contains an 8 bit error-class (see <xref
target="error-classes" />), 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.</t>
<t>The Info Count field contains the number of Additional
Information fields in the object, and the possible formats for these
fields are given in <xref target="additional-info" />. The precise
set of fields to include depends on the error code/subcode. For
every error description in the error catalogue <xref
target="error-catalogue" />, 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.</t>
</section>
<section anchor="additional-info"
title="Additional Information Fields">
<t>The Common Error Header may be followed by some Additional
Information fields. Each Additional Information field has a simple
TLV format as follows:</t>
<artwork><![CDATA[ 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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>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.</t>
<t>Message Length Info:</t>
<artwork><![CDATA[ 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.
]]></artwork>
<t>MTU Info:</t>
<artwork><![CDATA[ 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.]]></artwork>
<t>Object Type Info:</t>
<artwork><![CDATA[ 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.]]></artwork>
<t>Object Value Info:</t>
<artwork><![CDATA[ 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.]]></artwork>
<list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="Object (variable):">The invalid TLV object (including
the TLV Header).</t>
</list>
</section>
<section anchor="error-classes" title="Error Classes">
<t>The first byte of the error object, "Error Class", indicates the
severity level. The currently defined severity levels are:<list
style="hanging">
<t hangText="0 (Informational):">reply data which should not be
thought of as changing the condition of the protocol state
machine.</t>
<t hangText="1 (Success):">reply data which indicates that the
message being responded to has been processed successfully in
some sense.</t>
<t hangText="2 (Protocol-Error):">the message has been rejected
because of a protocol error (e.g. an error in message
format).</t>
<t hangText="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).</t>
<t hangText="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.</t>
</list>Additional error class values are reserved.</t>
<t>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).</t>
</section>
<section anchor="error-catalogue" title="Error Catalogue">
<t>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.</t>
<section anchor="error-common-header-parse-error"
title="Common Header Parse Error">
<artwork><![CDATA[
Class: Protocol-Error
Code: 1
Additional Info: For subcode 3 only, Message Length Info carries
the calculated message length.
]]></artwork>
<t>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:<list
style="hanging">
<t hangText="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.</t>
<t hangText="1: Unknown Type:">The GIST message type is
unknown.</t>
<t hangText="2: Invalid R-flag:">The R flag in the header is
inconsistent with the message type.</t>
<t hangText="3: Incorrect Message Length:">The overall message
length is not consistent with the set of objects carried.</t>
<t hangText="4: Invalid E-flag:">The E flag is set in the
header but this is not a Data message.</t>
</list></t>
</section>
<section anchor="error-hop-limit-exceeded"
title="Hop Limit Exceeded">
<artwork><![CDATA[
Class: Permanent-Failure
Code: 2
Additional Info: None
]]></artwork>
<t>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.</t>
</section>
<section anchor="error-incorrect-encapsulation"
title="Incorrect Encapsulation">
<artwork><![CDATA[
Class: Protocol-Error
Code: 3
Additional Info: None
]]></artwork>
<t>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).</t>
</section>
<section anchor="error-incorrectly-delivered-message"
title="Incorrectly Delivered Message">
<artwork><![CDATA[
Class: Protocol-Error
Code: 4
Additional Info: None
]]></artwork>
<t>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.</t>
</section>
<section anchor="error-no-routing-state" title="No Routing State">
<artwork><![CDATA[
Class: Protocol-Error
Code: 5
Additional Info: None
]]></artwork>
<t>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 also <xref target="node-sm" /> and <xref
target="r-sm" />.</t>
</section>
<section anchor="error-unknown-nslpid" title="Unknown NSLPID">
<artwork><![CDATA[
Class: Permanent-Failure
Code: 6
Additional Info: None
]]></artwork>
<t>This message is sent if a router receives a directly addressed
message for an NSLP which it does not support.</t>
</section>
<section anchor="error-endpoint-found" title="Endpoint Found">
<artwork><![CDATA[
Class: Permanent-Failure
Code: 7
Additional Info: None
]]></artwork>
<t>This message is sent if a GIST node at a flow endpoint receives
a Query message for an NSLP which it does not support.</t>
</section>
<section anchor="error-message-too-large" title="Message Too Large">
<artwork><![CDATA[
Class: Permanent-Failure
Code: 8
Additional Info: MTU Info
]]></artwork>
<t>A router receives a message which it can't forward because it
exceeds the IP MTU on the next or subsequent hops.</t>
</section>
<section anchor="error-object-type-error" title="Object Type Error">
<artwork><![CDATA[
Class: Protocol-Error
Code: 9
Additional Info: Object Type Info
]]></artwork>
<t>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:<list
style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="5: Invalid Extensibility Flags:">This subcode is
used if an object is received with the extensibility flags
AB=11.</t>
</list></t>
</section>
<section anchor="error-object-value-error"
title="Object Value Error">
<artwork><![CDATA[
Class: Protocol-Error
Code: 10
Additional Info: 1 or 2 Object Value Info fields as given below
]]></artwork>
<t>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:<list
style="hanging">
<t hangText="0: Incorrect Length:">The overall length does not
match the object length calculated from the object
contents.</t>
<t hangText="1: Value Not Supported:">The value of a field is
not supported by the GIST node.</t>
<t hangText="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 (<xref
target="format-mri-pcmrm" />), but in future there may be
more.</t>
<t hangText="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").</t>
<t hangText="4: Invalid Cookie:">The message contains a cookie
which could not be verified by the node.</t>
<t
hangText="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.</t>
</list></t>
</section>
<section anchor="error-invalid-ip-layer-ttl"
title="Invalid IP layer TTL">
<artwork><![CDATA[
Class: Permanent-Failure
Code: 11
Additional Info: None
]]></artwork>
<t>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.</t>
</section>
<section anchor="error-mri-validation-failure"
title="MRI Validation Failure">
<artwork><![CDATA[
Class: Permanent-Failure
Code: 12
Additional Info: Object Value Info
]]></artwork>
<t>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. <xref
target="pc-downstream" />). 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:<list style="hanging">
<t hangText="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.</t>
<t hangText="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 <xref
target="transition" />).</t>
<t hangText="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.</t>
</list></t>
</section>
</section>
</section>
</section>
<section anchor="api" title="API between GIST and Signalling Applications">
<t>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.</t>
<t>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.</t>
<section anchor="api-sendmessage" title="SendMessage">
<t>This primitive is passed from a signalling application to GIST. It
is used whenever the signalling application wants to initiate sending
a message.</t>
<artwork><![CDATA[
SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle,
NSLPID, Session-ID, MRI, SII-Handle,
Transfer-Attributes, Timeout, IP-TTL, GIST-Hop-Count )]]></artwork>
<t>The following arguments are mandatory.<list style="hanging">
<t hangText="NSLP-Data:">The NSLP message itself.</t>
<t hangText="NSLP-Data-Size:">The length of NSLP-Data.</t>
<t hangText="NSLP-Message-Handle:">A handle for this message, that
can be used by GIST as a reference in subsequent MessageStatus
notifications (<xref target="api-messagestatus" />). 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.</t>
<t hangText="NSLPID:">An identifier indicating which NSLP this
is.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list>The following arguments are optional:<list style="hanging">
<t hangText="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.</t>
<t hangText="Transfer-Attributes:">Attributes defining how the
message should be handled (see <xref target="mtas" />). The
following attributes can be considered:<list style="hanging">
<t hangText="Reliability:">Values 'unreliable' or
'reliable'.</t>
<t hangText="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).</t>
<t hangText="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.</t>
</list></t>
<t hangText="Timeout:">Length of time GIST should attempt to send
this message before indicating an error.</t>
<t hangText="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).</t>
<t hangText="GIST-Hop-Count:">The value for the hop count when
sending the message.</t>
</list></t>
</section>
<section anchor="api-recvmessage" title="RecvMessage">
<t>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).</t>
<artwork><![CDATA[
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 )]]></artwork>
<t>
<list style="hanging">
<t hangText="NSLP-Data:">The NSLP message itself (may be
empty).</t>
<t hangText="NSLP-Data-Size:">The length of NSLP-Data (may be
zero).</t>
<t hangText="NSLPID:">An identifier indicating which NSLP this
message is for.</t>
<t hangText="Session-ID:">The NSIS session identifier.</t>
<t hangText="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.</t>
<t hangText="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 <xref target="local-proc" />). If True, the
signalling application should return the following values via the
RecvMessage call:<list>
<t>A boolean indicating whether to set up the state.</t>
<t>Optionally, an NSLP-Payload to carry in the generated
Response or forwarded Query respectively.</t>
</list>This mechanism could be extended to enable the signalling
application to indicate to GIST whether state installation should
be immediate or deferred (see <xref target="rate-control" /> and
<xref target="r-sm" /> for further discussion).</t>
<t hangText="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.</t>
<t hangText="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:<list
style="symbols">
<t>Whether the signalling source address is one of the flow
endpoints (i.e. whether this is the first or last GIST
hop);</t>
<t>Whether the signalling source address has been validated by
a return routability check.</t>
<t>Whether the message was explicitly routed (and so has not
been validated by GIST as delivered consistently with local
routing state).</t>
</list></t>
<t hangText="IP-TTL:">The value of the IP layer TTL this message
was received with (if available).</t>
<t hangText="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.</t>
<t hangText="GIST-Hop-Count:">The value of the hop count the
message was received with, after being decremented in the GIST
receive-side processing.</t>
<t hangText="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.</t>
</list>
</t>
</section>
<section anchor="api-messagestatus" title="MessageStatus">
<t>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.</t>
<artwork><![CDATA[
MessageStatus (NSLP-Message-Handle, Transfer-Attributes, Error-Type)]]></artwork>
<t>
<list style="hanging">
<t hangText="NSLP-Message-Handle:">A handle for the message
provided by the signalling application in SendMessage.</t>
<t hangText="Transfer-Attributes:">The reliability and security
attributes that will be used to transmit this particular
message.</t>
<t hangText="Error-Type:">Indicates the type of error that
occurred. For example, 'no next node found'.</t>
</list>
</t>
</section>
<section anchor="api-networknotification" title="NetworkNotification">
<t>This primitive is passed from GIST to a signalling application. It
indicates that a network event of possible interest to the signalling
application occurred.</t>
<artwork><![CDATA[
NetworkNotification ( NSLPID, MRI, Network-Notification-Type )]]></artwork>
<t>
<list style="hanging">
<t hangText="NSLPID:">An identifier indicating which NSLP this is
message is for.</t>
<t hangText="MRI:">Provides the message routing information to
which the network notification applies.</t>
<t hangText="Network-Notification-Type:">Indicates the type of
event that caused the notification and associated additional data.
Five events have been identified:<list style="hanging">
<t hangText="Last Node:">GIST has detected that this is the
last NSLP-aware node in the path. See <xref
target="bypass" />.</t>
<t hangText="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 <xref target="reroute-support" />. The new status is
reported; if the status is Good, the SII-Handle of the peer is
also reported, as for RecvMessage.</t>
<t hangText="Route Deletion:">GIST has determined that an old
route is now definitely invalid, e.g. that flows are
definitely not using it (see <xref
target="load-splitting" />). The SII-Handle of the peer is
also reported.</t>
<t hangText="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 <xref target="signalling-peer-authorisation" />.</t>
<t hangText="Communication Failure:">Communication with the
peer has failed; messages may have been lost.</t>
</list></t>
</list>
</t>
</section>
<section anchor="api-setstatelifetime" title="SetStateLifetime">
<t>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.</t>
<artwork><![CDATA[
SetStateLifetime ( NSLPID, MRI, SID, State-Lifetime )]]></artwork>
<t>
<list style="hanging">
<t hangText="NSLPID:">Provides the NSLPID to which the routing
state lifetime applies.</t>
<t hangText="MRI:">Provides the message routing information to
which the routing state lifetime applies; includes the direction
(in the D flag).</t>
<t hangText="SID:">The session ID which the signalling application
will be using with this routing state. Can be wildcarded.</t>
<t hangText="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).</t>
</list>
</t>
</section>
<section anchor="api-invalidateroutingstate"
title="InvalidateRoutingState">
<t>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 <xref target="route-change" />.</t>
<artwork><![CDATA[
InvalidateRoutingState ( NSLPID, MRI, Status, NSLP-Data,
NSLP-Data-Size, Urgent )]]></artwork>
<t>
<list style="hanging">
<t hangText="NSLPID:">The NSLP originating the message. May be
null (in which case the invalidation applies to all signalling
applications).</t>
<t hangText="MRI:">The flow for which routing state should be
invalidated; includes the direction of the change (in the D
flag).</t>
<t hangText="Status:">The new status that should be assumed for
the routing state, one of Bad or Tentative (see <xref
target="reroute-support" />).</t>
<t hangText="NSLP-Data, NSLP-Data-Size">Optional: a payload
provided by the NSLP to be used the next GIST handshake. This can
be used as part of a conditional peering process (see <xref
target="local-proc" />). The payload will be transmitted without
security protection.</t>
<t hangText="Urgent:">A hint as to whether rediscovery should take
place immediately, or only with the next signalling message.</t>
</list>
</t>
</section>
</section>
<section anchor="rao-nasties"
title="Deployment Issues with Router Alert Options">
<t>The GIST peer discovery handshake (<xref target="ssetup"></xref>)
depends on the interception of Q-mode encapsulated IP packets (<xref
target="reception"></xref> and <xref target="q-encaps"></xref>) by
routers. There are two fundamental requirements on the process:<list
style="numbers">
<t>Packets relevant to GIST must be intercepted.</t>
<t>Packets not relevant to GIST must be forwarded transparently.</t>
</list>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 UDP encapsulation for Q-mode traffic, GIST allows NATs
at least to pass these messages (<xref
target="legacy-nat-overview"></xref>), 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.</t>
<t>The IPv4 RAO is defined by <xref target="RFC2113"></xref>, 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.)</t>
<t>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:<list style="numbers">
<t>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.</t>
<t>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).</t>
</list>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).</t>
<t>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.<list
style="symbols">
<t>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 <xref
target="q-mode-v4"></xref>.)</t>
<t>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.</t>
</list>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 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.</t>
<t>The situation with IPv6 is rather different, since in that case the
use of non-zero RAO values is well established in the specification
(<xref target="RFC2711"></xref>) 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.</t>
</section>
<section anchor="example-flow"
title="Example Routing State Table and Handshake">
<t><xref target="fig-ex"></xref> 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.</t>
<figure anchor="fig-ex" title="A Signalling Scenario">
<artwork><![CDATA[
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 |
+------------------------------------+---------+--------+-----------+]]></artwork>
</figure>
<t>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.)</t>
<t><xref target="fig-seq"></xref> shows a GIST handshake setting up a
messaging association 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.</t>
<figure anchor="fig-seq" title="GIST Handshake Message Sequence">
<artwork><![CDATA[
-------------------------- Query ---------------------------->
IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST)
D-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)
D-mode magic number (0x4e04 bda5)
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))]]></artwork>
</figure>
</section>
<section title="Change History">
<t>Note to the RFC Editor: this appendix to be removed before
publication as an RFC.</t>
<section title="Changes in Version -14" toc="exclude">
<t>The following changes were made in version 14. They include fixes
for the issues identified at the Karlsruhe interop event.</t>
<t><list style="numbers">
<t>Changed the treatment of D-mode messages received (at the IP
destination address) with the wrong magic number so they are
silently dropped rather than generating an error message (<xref
target="d-normal-encaps"></xref>, <xref
target="q-mode-upper"></xref>, and <xref
target="error-common-header-parse-error"></xref>).</t>
<t>Added a dedicated figure to illustrate the example in <xref
target="example"></xref>.</t>
<t>Added a note in <xref target="reception"></xref> to clarify
that GIST messages with zero hop count should never be seen from
correct implementations.</t>
<t>Added a figure to show the high-level format of normal D-mode
encapsulation (especially the location of the magic number) to
<xref target="d-normal-encaps"></xref>.</t>
<t>Added a clarification in <xref target="q-mode-v4"></xref>
explaining the significance of S=1 for the processing of ICMP
error messages, and made the text there more consistent with the
RFC2119 language in <xref target="pc-downstream"></xref>.</t>
<t>Corrected the message size rules in <xref
target="message-transmission"></xref> to allow the use of messages
up to the path MTU to the next peer if this is known. Also made
the default MTU limit consistent in the bypass processing rules in
<xref target="bypass"></xref>.</t>
<t>Clarified the ability to use Q-mode for Data messages when
requested by local policy, in <xref target="mtas"></xref>, <xref
target="message-transmission"></xref>, <xref
target="q-encaps"></xref> and <xref
target="encaps-table"></xref>.</t>
<t>Clarified in <xref target="error-proc"></xref> that the NSLPID
of messages that cause an error should be deduced from the Common
Header embedded in the Error object.</t>
<t>Modified the text in <xref target="local-proc"></xref> to
clarify that the Hop Count is still decremented in this case (but
no other GIST payloads).</t>
<t>Tidied up the text in <xref target="bypass"></xref> describing
the scenarios under which a GIST message may be bypassed at the
GIST level.</t>
<t>Clarified the text in <xref
target="legacy-nat-overview"></xref> to say that the legacy NAT
detection procedure does not handle the case of Data messages sent
outside a messaging association.</t>
<t>Extended the description at the end of <xref
target="ga-nat-overview"></xref> to explain the responsibility of
the Responding node to translate between the MRIs used either side
of the NAT for messages sent after the handshake.</t>
<t>Modified the text introducing <xref
target="encaps-table"></xref> to restrict the Incorrect
Encapsulation error message to apply only when a message that
should be in C-mode arrives in D-mode and vice versa.</t>
<t>Clarified that rule 6 in <xref target="r-sm"></xref> should
include dropping the incoming data. [Interop ticket 36]</t>
<t>Modified the handling of the Stack-Proposal verification in
<xref target="ma-overview"></xref> to say that the MA is only torn
down if it is a new one; otherwise, the action is that the routing
state for the MRI is deleted or never created. Added the
verification of the Responder cookie to be included in the same
set of checks. [Interop ticket 43, 49]</t>
<t>Clarified that the timer used to retransmit Responses follows
the same rules as other timers in <xref
target="rate-control"></xref>;also, in <xref target="r-sm"></xref>
stated that Expire_RNode should be reset to the initial value on a
new Query, and its expiration overrides any outstanding No_Confirm
timer. [Interop ticket 48]</t>
<t>Clarified in <xref target="error-proc"></xref> that if the
messaging association that should be used to deliver an Error
message has been closed, this comes into the category of 'messages
that cannot be sent'. [Interop ticket 50]</t>
<t>Amended the description of Confirm contents in <xref
target="message-overview"></xref> to note that the Stack-Proposal
may not be present if it was not present in the Response. (This
can only happen if the Response was sent over an existing MA; if a
new MA is set up, a Stack-Proposal is required in the Response.
Therefore, if the abbreviated SCD is sent in the Confirm, there
will always be a Stack-Proposal to accompany it.) [Interop ticket
55]</t>
<t>Refined the definition of the Inactive_QNode timer in <xref
target="q-sm"></xref> to clarify that this is just to measure the
activity in terms of NSLP traffic rather than GIST-internal
traffic, and modified Rule 4 accordingly. [Interop ticket 64]</t>
<t>Deleted the term 'full handshake' as this implied mandatory use
of the 3 message for (Q/R/C), whereas in the places the term was
used the purpose was to highlight that the handshake was taking
place in D-mode rather than partly in C-mode. Whether a Confirm is
sent is under the control of the Responder. [Interop ticket
65]</t>
<t>Clarified in <xref target="messages"></xref> and <xref
target="message-overview"></xref> that generation of a Confirm is
controlled by the content of the Response, and that when a new MA
is being set up the rules for content of a Response require a
Confirm. [Interop ticket 66]</t>
<t>Modified the Responder-Cookie construction in <xref
target="cookies"></xref> to clarify which parts of the NLI are
included and to carry the reception interface outside the hash,
and pointed to <xref
target="I-D.pashalidis-nsis-gimps-nattraversal"></xref> for
further constructions in the case of GIST-aware NAT traversal.</t>
<t>Removed remaining sections of this change history.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:20:19 |