< draft-ietf-nsis-ntlp-12.txt   draft-ietf-nsis-ntlp-13.txt >
Next Steps in Signaling H. Schulzrinne Next Steps in Signaling H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Intended status: Standards Track R. Hancock Intended status: Standards Track R. Hancock
Expires: August 31, 2007 Siemens/RMR Expires: October 4, 2007 Siemens/RMR
February 27, 2007 April 2, 2007
GIST: General Internet Signalling Transport GIST: General Internet Signalling Transport
draft-ietf-nsis-ntlp-12 draft-ietf-nsis-ntlp-13
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 31, 2007. This Internet-Draft will expire on October 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies protocol stacks for the routing and transport This document specifies protocol stacks for the routing and transport
of per-flow signalling messages along the path taken by that flow of per-flow signalling messages along the path taken by that flow
through the network. The design uses existing transport and security through the network. The design uses existing transport and security
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation and Terminology . . . . . . . . . . . . 6 2. Requirements Notation and Terminology . . . . . . . . . . . . 6
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 9 3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 9
3.2. Modes and Messaging Associations . . . . . . . . . . . . 10 3.2. Modes and Messaging Associations . . . . . . . . . . . . 10
3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 12 3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 12
3.4. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 14 3.4. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 14
3.5. GIST Peering Relationships . . . . . . . . . . . . . . . 14 3.5. GIST Peering Relationships . . . . . . . . . . . . . . . 15
3.6. Effect on Internet Transparency . . . . . . . . . . . . . 15 3.6. Effect on Internet Transparency . . . . . . . . . . . . . 15
3.7. Signalling Sessions . . . . . . . . . . . . . . . . . . . 16 3.7. Signalling Sessions . . . . . . . . . . . . . . . . . . . 16
3.8. Signalling Applications and NSLPIDs . . . . . . . . . . . 17 3.8. Signalling Applications and NSLPIDs . . . . . . . . . . . 17
3.9. GIST Security Services . . . . . . . . . . . . . . . . . 17 3.9. GIST Security Services . . . . . . . . . . . . . . . . . 17
3.10. Example of Operation . . . . . . . . . . . . . . . . . . 18 3.10. Example of Operation . . . . . . . . . . . . . . . . . . 18
4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 21 4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 22
4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 21 4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 22
4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 23 4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 24
4.3. Basic GIST Message Processing . . . . . . . . . . . . . . 25 4.3. Basic GIST Message Processing . . . . . . . . . . . . . . 26
4.4. Routing State and Messaging Association Maintenance . . . 32 4.4. Routing State and Messaging Association Maintenance . . . 34
5. Message Formats and Transport . . . . . . . . . . . . . . . . 45 5. Message Formats and Transport . . . . . . . . . . . . . . . . 47
5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 45 5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 47
5.2. Information Elements . . . . . . . . . . . . . . . . . . 47 5.2. Information Elements . . . . . . . . . . . . . . . . . . 49
5.3. D-mode Transport . . . . . . . . . . . . . . . . . . . . 51 5.3. D-mode Transport . . . . . . . . . . . . . . . . . . . . 53
5.4. C-mode Transport . . . . . . . . . . . . . . . . . . . . 56 5.4. C-mode Transport . . . . . . . . . . . . . . . . . . . . 59
5.5. Message Type/Encapsulation Relationships . . . . . . . . 57 5.5. Message Type/Encapsulation Relationships . . . . . . . . 59
5.6. Error Message Processing . . . . . . . . . . . . . . . . 58 5.6. Error Message Processing . . . . . . . . . . . . . . . . 60
5.7. Messaging Association Setup . . . . . . . . . . . . . . . 59 5.7. Messaging Association Setup . . . . . . . . . . . . . . . 61
5.8. Specific Message Routing Methods . . . . . . . . . . . . 63 5.8. Specific Message Routing Methods . . . . . . . . . . . . 65
6. Formal Protocol Specification . . . . . . . . . . . . . . . . 69 6. Formal Protocol Specification . . . . . . . . . . . . . . . . 71
6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 71 6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 73
6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 72 6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 74
6.3. Responder Node Processing . . . . . . . . . . . . . . . . 75 6.3. Responder Node Processing . . . . . . . . . . . . . . . . 77
6.4. Messaging Association Processing . . . . . . . . . . . . 78 6.4. Messaging Association Processing . . . . . . . . . . . . 80
7. Additional Protocol Features . . . . . . . . . . . . . . . . 82 7. Additional Protocol Features . . . . . . . . . . . . . . . . 84
7.1. Route Changes and Local Repair . . . . . . . . . . . . . 82 7.1. Route Changes and Local Repair . . . . . . . . . . . . . 84
7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 89 7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 91
7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 94 7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 96
7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 95 7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 97
8. Security Considerations . . . . . . . . . . . . . . . . . . . 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 99
8.1. Message Confidentiality and Integrity . . . . . . . . . . 97 8.1. Message Confidentiality and Integrity . . . . . . . . . . 99
8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 98 8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 100
8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 98 8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 100
8.4. Denial of Service Prevention and Overload Protection . . 100 8.4. Denial of Service Prevention and Overload Protection . . 102
8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 102 8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 104
8.6. Security Protocol Selection Policy . . . . . . . . . . . 103 8.6. Security Protocol Selection Policy . . . . . . . . . . . 105
8.7. Residual Threats . . . . . . . . . . . . . . . . . . . . 104 8.7. Residual Threats . . . . . . . . . . . . . . . . . . . . 106
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 111 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 113
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 112 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 114
11.1. Normative References . . . . . . . . . . . . . . . . . . 112 11.1. Normative References . . . . . . . . . . . . . . . . . . 114
11.2. Informative References . . . . . . . . . . . . . . . . . 113 11.2. Informative References . . . . . . . . . . . . . . . . . 115
Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 116 Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 118
A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 116 A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 118
A.2. General Object Format . . . . . . . . . . . . . . . . . . 117 A.2. General Object Format . . . . . . . . . . . . . . . . . . 119
A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 118 A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 120
A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 127 A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 129
Appendix B. API between GIST and Signalling Applications . . . . 136 Appendix B. API between GIST and Signalling Applications . . . . 138
B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 136 B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 138
B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 138 B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 140
B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 139 B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 141
B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 140 B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 142
B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 141 B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 143
B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 141 B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 143
Appendix C. Deployment Issues with Router Alert Options . . . . 142 Appendix C. Deployment Issues with Router Alert Options . . . . 145
Appendix D. Example Routing State Table and Handshake . . . . . 145 Appendix D. Example Routing State Table and Handshake . . . . . 148
Appendix E. Change History . . . . . . . . . . . . . . . . . . . 147 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 150
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 172 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 176
Intellectual Property and Copyright Statements . . . . . . . . . 173 Intellectual Property and Copyright Statements . . . . . . . . . 177
1. Introduction 1. Introduction
Signalling involves the manipulation of state held in network Signalling involves the manipulation of state held in network
elements. 'Manipulation' could mean setting up, modifying and elements. 'Manipulation' could mean setting up, modifying and
tearing down state; or it could simply mean the monitoring of state tearing down state; or it could simply mean the monitoring of state
which is managed by other mechanisms. which is managed by other mechanisms.
This specification concentrates mainly on path-coupled signalling, This specification concentrates mainly on path-coupled signalling,
controlling resources on network elements which are located on the controlling resources on network elements which are located on the
skipping to change at page 4, line 37 skipping to change at page 4, line 37
environments where the multicast replication points can be made GIST- environments where the multicast replication points can be made GIST-
capable. GIST can also be extended to cover other types of capable. GIST can also be extended to cover other types of
signalling pattern, not related to any end-to-end flow in the signalling pattern, not related to any end-to-end flow in the
network, in which case the distinction between GIST and end-to-end network, in which case the distinction between GIST and end-to-end
higher-layer signalling will be drawn differently or not at all. higher-layer signalling will be drawn differently or not at all.
Every signalling application requires a set of state management Every signalling application requires a set of state management
rules, as well as protocol support to exchange messages along the rules, as well as protocol support to exchange messages along the
data path. Several aspects of this protocol support are common to data path. Several aspects of this protocol support are common to
all or a large number of signalling applications, and hence can be all or a large number of signalling applications, and hence can be
developed as a common protocol. The NSIS framework given in [31] developed as a common protocol. The NSIS framework given in [30]
provides a rationale for a function split between the common and provides a rationale for a function split between the common and
application specific protocols, and gives outline requirements for application specific protocols, and gives outline requirements for
the former, the 'NSIS Transport Layer Protocol' (NTLP). The the former, the 'NSIS Transport Layer Protocol' (NTLP). The
application specific protocols are referred to as 'NSIS Signalling application specific protocols are referred to as 'NSIS Signalling
Layer Protocols' (NSLPs), and are defined in separate documents. The Layer Protocols' (NSLPs), and are defined in separate documents. The
NSIS framework, and the accompanying threats document [32], provide NSIS framework [30], and the accompanying threats document [31],
important background information to this specification, including provide important background information to this specification,
information on how GIST is expected to be used in various network including information on how GIST is expected to be used in various
types and what role it is expected to perform. network types and what role it is expected to perform.
This specification provides a concrete solution for the NTLP. It is This specification provides a concrete solution for the NTLP. It is
based on the use of existing transport and security protocols under a based on the use of existing transport and security protocols under a
common messaging layer, the General Internet Signalling Transport common messaging layer, the General Internet Signalling Transport
(GIST). GIST does not handle signalling application state itself; in (GIST). GIST does not handle signalling application state itself; in
that crucial respect, it differs from application signalling that crucial respect, it differs from application signalling
protocols such as SIP, RTSP, and the control component of FTP. protocols such as SIP, RTSP, and the control component of FTP.
Instead, GIST manages its own internal state and the configuration of Instead, GIST manages its own internal state and the configuration of
the underlying transport and security protocols to ensure the the underlying transport and security protocols to ensure the
transfer of signalling messages on behalf of signalling applications transfer of signalling messages on behalf of signalling applications
skipping to change at page 5, line 31 skipping to change at page 5, line 31
example message flow. Parts of the GIST design depend on the use of example message flow. Parts of the GIST design depend on the use of
packets with IP options to probe the network, which leads to packets with IP options to probe the network, which leads to
migration issues in networks with non-GIST nodes, especially in the migration issues in networks with non-GIST nodes, especially in the
case of IPv4, and these are discussed in Appendix C. case of IPv4, and these are discussed in Appendix C.
Because of the layered structure of the NSIS protocol suite, protocol Because of the layered structure of the NSIS protocol suite, protocol
extensions to cover a new signalling requirement could be carried out extensions to cover a new signalling requirement could be carried out
either within GIST, or within the signalling application layer, or either within GIST, or within the signalling application layer, or
both. General guidelines on how to extend different layers of the both. General guidelines on how to extend different layers of the
protocol suite, and in particular when and how it is appropriate to protocol suite, and in particular when and how it is appropriate to
extend GIST, are contained in a separate document, [15]. In this extend GIST, are contained in a separate document, [14]. In this
document, Section 9 gives the formal IANA considerations for the document, Section 9 gives the formal IANA considerations for the
registries already defined by the GIST specification. registries already defined by the GIST specification.
2. Requirements Notation and Terminology 2. Requirements Notation and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4]. In document are to be interpreted as described in RFC 2119 [4]. In
addition, the security specifications in Section 5.7.3 use the addition, the security specifications in Section 5.7.3 use the
terminology MUST- and SHOULD+ from [5]. terminology MUST- and SHOULD+ from [5].
skipping to change at page 7, line 23 skipping to change at page 7, line 23
Upstream: In the opposite direction to the data flow. Upstream: In the opposite direction to the data flow.
GIST Node: Any node along the data path supporting GIST, regardless GIST Node: Any node along the data path supporting GIST, regardless
of what signalling applications it supports. of what signalling applications it supports.
[Adjacent] Peer: The next node along the signalling path, in the [Adjacent] Peer: The next node along the signalling path, in the
upstream or downstream direction, with which a GIST node upstream or downstream direction, with which a GIST node
explicitly interacts. explicitly interacts.
Querying Node: The GIST node that initiates the handshake process to
discover the adjacent peer.
Responding Node: The GIST node that responds to the handshake,
becoming the adjacent peer to the Querying node.
Datagram Mode (D-mode): A mode of sending GIST messages between Datagram Mode (D-mode): A mode of sending GIST messages between
nodes without using any transport layer state or security nodes without using any transport layer state or security
protection. Datagram mode uses UDP encapsulation, with source and protection. Datagram mode uses UDP encapsulation, with source and
destination IP addresses derived either from the flow definition destination IP addresses derived either from the flow definition
or previously discovered adjacency information. or previously discovered adjacency information.
Connection Mode (C-mode): A mode of sending GIST messages directly Connection Mode (C-mode): A mode of sending GIST messages directly
between nodes using point-to-point messaging associations (see between nodes using point-to-point messaging associations (see
below). Connection mode allows the re-use of existing transport below). Connection mode allows the re-use of existing transport
and security protocols where such functionality is required. and security protocols where such functionality is required.
Messaging Association (MA): A single connection between two Messaging Association (MA): A single connection between two
explicitly identified GIST adjacent peers, i.e. between a given explicitly identified GIST adjacent peers, i.e. between a given
signalling source and destination address. A messaging signalling source and destination address. A messaging
association may use a specific transport protocol and known ports. association may use a specific transport protocol and known ports.
If security protection is required, it may use a specific network If security protection is required, it may use a specific network
layer security association, or use a transport layer security layer security association, or use a transport layer security
association internally. A messaging association is bidirectional; association internally. A messaging association is bidirectional:
signalling messages can be sent over it in either direction, and signalling messages can be sent over it in either direction,
can refer to flows of either direction. referring to flows of either direction.
[Message] Routing: Message routing describes the process of [Message] Routing: Message routing describes the process of
determining which is the next GIST peer along the signalling path. determining which is the next GIST peer along the signalling path.
For signalling along a flow path, the message routing carried out For signalling along a flow path, the message routing carried out
by GIST is built on top of normal IP routing. In this document, by GIST is built on top of normal IP routing. In this document,
the term 'routing' generally refers to GIST message routing unless the term 'routing' generally refers to GIST message routing unless
otherwise qualified. otherwise qualified.
Message Routing Method (MRM): There can be different algorithms for Message Routing Method (MRM): There can be different algorithms for
discovering the route that signalling messages should take. These discovering the route that signalling messages should take. These
are referred to as message routing methods, and GIST supports are referred to as message routing methods, and GIST supports
alternatives within a common protocol framework. See Section 3.3. alternatives within a common protocol framework. See Section 3.3.
Message Routing Information (MRI): The set of data item values which Message Routing Information (MRI): The set of data item values which
is used to route a signalling message according to a particular is used to route a signalling message according to a particular
MRM; for example, for routing along a flow path, the MRI includes MRM; for example, for routing along a flow path, the MRI includes
flow source and destination addresses, protocol and port numbers. flow source and destination addresses, protocol and port numbers.
See Section 3.3. See Section 3.3.
Router Alert Option (RAO): An option that can be included in IP v4
and v6 headers to assist in the packet interception process; see
[3] and [8].
Transfer Attributes: A description of the requirements which a Transfer Attributes: A description of the requirements which a
signalling application has for the delivery of a particular signalling application has for the delivery of a particular
message; for example, whether the message should be delivered message; for example, whether the message should be delivered
reliably. See Section 4.1.2. reliably. See Section 4.1.2.
Router Alert Option (RAO): An option that can be included in IP v4
and v6 headers to assist in the packet interception process; see
[3] and [8].
3. Design Overview 3. Design Overview
3.1. Overall Design Approach 3.1. Overall Design Approach
The generic requirements identified in the NSIS framework [31] for The generic requirements identified in the NSIS framework [30] for
transport of signalling messages are essentially two-fold: transport of signalling messages are essentially two-fold:
Routing: Determine how to reach the adjacent signalling node along Routing: Determine how to reach the adjacent signalling node along
each direction of the data path (the GIST peer), and if necessary each direction of the data path (the GIST peer), and if necessary
explicitly establish addressing and identity information about explicitly establish addressing and identity information about
that peer; that peer;
Transport: Deliver the signalling information to that peer. Transport: Deliver the signalling information to that peer.
To meet the routing requirement, one possibility is for the node to To meet the routing requirement, one possibility is for the node to
skipping to change at page 9, line 34 skipping to change at page 9, line 34
exchange data. Once the routing decision has been made, the node has 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 to select a mechanism for transport of the message to the peer. GIST
divides the transport problems into two categories, the easy and the divides the transport problems into two categories, the easy and the
difficult. It handles the easy cases internally, and uses well- difficult. It handles the easy cases internally, and uses well-
understood transport protocols for the harder cases. Here, with understood transport protocols for the harder cases. Here, with
details discussed later, "easy" messages are those that are sized details discussed later, "easy" messages are those that are sized
well below the lowest maximum transmission unit (MTU) along a path, well below the lowest maximum transmission unit (MTU) along a path,
are infrequent enough not to cause concerns about congestion and flow are infrequent enough not to cause concerns about congestion and flow
control, and do not need security protection or guaranteed delivery. control, and do not need security protection or guaranteed delivery.
In [31] all of these routing and transport requirements are assigned In [30] all of these routing and transport requirements are assigned
to a single notional protocol, the NSIS Transport Layer Protocol to a single notional protocol, the NSIS Transport Layer Protocol
(NTLP). The strategy of splitting the transport problem leads to a (NTLP). The strategy of splitting the transport problem leads to a
layered structure for the NTLP, of a specialised GIST messaging layer layered structure for the NTLP, of a specialised GIST messaging layer
running over standard transport and security protocols. The basic running over standard transport and security protocols. The basic
concept is shown in Figure 2. Note that not every combination of concept is shown in Figure 2. Note that not every combination of
transport and security protocols implied by the figure is actually transport and security protocols implied by the figure is actually
possible for use in GIST; the actual combinations allowed by this possible for use in GIST; the actual combinations allowed by this
specification are defined in Section 5.7. The figure also shows GIST specification are defined in Section 5.7. The figure also shows GIST
offering its services to upper layers at an abstract interface, the offering its services to upper layers at an abstract interface, the
GIST API, further discussed in Section 4.1. GIST API, further discussed in Section 4.1.
skipping to change at page 11, line 11 skipping to change at page 11, line 11
modest delay constraints and no security requirements. A special modest delay constraints and no security requirements. A special
case of D-mode called Query-mode (Q-mode) is used when no routing case of D-mode called Query-mode (Q-mode) is used when no routing
state exists. state exists.
Connection mode (C-mode): used for larger messages or where fast Connection mode (C-mode): used for larger messages or where fast
state setup in the face of packet loss is desirable, or where state setup in the face of packet loss is desirable, or where
channel security is required. channel security is required.
D-mode uses UDP, as a suitable NAT-friendly encapsulation which does D-mode uses UDP, as a suitable NAT-friendly encapsulation which does
not require per-message shared state to be maintained between the not require per-message shared state to be maintained between the
peers. It is currently an assumption that long-term evolution of peers. Long-term evolution of GIST is assumed to preserve the
GIST will preserve the simplicity of the current D-mode design. simplicity of the current D-mode design. Extensions to the security
Extensions to the security or transport capabilities of D-mode can be or transport capabilities of D-mode can be provided equivalently by
provided equivalently by selecting a different protocol stack under selecting a different protocol stack under the GIST messaging layer,
the GIST messaging layer, which would then become another option which would then become another option within the overall C-mode
within the overall C-mode framework. This includes both the case of framework. This includes both the case of using existing protocols,
using existing protocols, and specific development of a message and specific development of a message exchange and payload
exchange and payload encapsulation to support GIST requirements. encapsulation to support GIST requirements. Alternatively, if any
Alternatively, if any necessary parameters (e.g. a shared secret for necessary parameters (e.g. a shared secret for use in integrity or
use in integrity or confidentiality protection) can be negotiated confidentiality protection) can be negotiated out-of-band, then the
out-of-band, then the additional functions can be added directly to additional functions can be added directly to D-mode by adding an
D-mode by adding an optional object to the message (see optional object to the message (see Appendix A.2.1). Note that
Appendix A.2.1). Note that downgrade attacks on such approach would downgrade attacks on such approach would need to be prevented by
need to be prevented by policy at the destination node, similar to policy at the destination node, similar to the situation discussed in
the situation discussed in Section 8.6. Section 8.6.
C-mode can in principle use any stream or message-oriented transport C-mode can in principle use any stream or message-oriented transport
protocol; this specification defines TCP as the initial choice. It protocol; this specification defines TCP as the initial choice. It
can in principle employ specific network layer security associations, can in principle employ specific network layer security associations,
or an internal transport layer security association; this or an internal transport layer security association; this
specification defines TLS as the initial choice. When GIST messages specification defines TLS as the initial choice. When GIST messages
are carried in C-mode, they are treated just like any other traffic are carried in C-mode, they are treated just like any other traffic
by intermediate routers between the GIST peers. Indeed, it would be by intermediate routers between the GIST peers. Indeed, it would be
impossible for intermediate routers to carry out any processing on impossible for intermediate routers to carry out any processing on
the messages without terminating the transport and security protocols the messages without terminating the transport and security protocols
skipping to change at page 13, line 4 skipping to change at page 13, line 4
NAT Address Reservations: This applies to the case where a node NAT Address Reservations: This applies to the case where a node
behind a NAT wishes to reserve an address at which it can be 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 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 be sent outbound from what will be the flow receiver although no
reverse routing state for the flow yet exists. reverse routing state for the flow yet exists.
Most of the details of GIST operation are independent of which is Most of the details of GIST operation are independent of which is
being used. Therefore, the GIST design encapsulates the routing- being used. Therefore, the GIST design encapsulates the routing-
dependent details as a message routing method (MRM), and allows dependent details as a message routing method (MRM), and allows
multiple MRMs to be defined. The default is the path-coupled MRM, multiple MRMs to be defined. This specification defines the path-
which corresponds to the baseline functionality described above; a coupled MRM, corresponding to the baseline functionality described
second MRM for the NAT Address Reservation case is also defined. above, and a second MRM for the NAT Address Reservation case. The
detailed specifications are given in Section 5.8.
The content of a MRM definition is as follows, using the path-coupled The content of a MRM definition is as follows, using the path-coupled
MRM as an example: MRM as an example:
o The format of the information that describes the path that the o The format of the information that describes the path that the
signalling should take, the Message Routing Information (MRI). signalling should take, the Message Routing Information (MRI).
For the path-coupled MRM, this is just the Flow Identifier (see For the path-coupled MRM, this is just the Flow Identifier (see
Section 5.8.1.1) and some additional control information. Section 5.8.1.1) and some additional control information.
Specifically, the MRI always includes a flag to distinguish Specifically, the MRI always includes a flag to distinguish
between the two directions that signalling messages can take, between the two directions that signalling messages can take,
skipping to change at page 13, line 49 skipping to change at page 13, line 50
supporting techniques may be possible; see Section 7.1.2. supporting techniques may be possible; see Section 7.1.2.
In addition, it should be noted that NAT traversal may require In addition, it should be noted that NAT traversal may require
translation of fields in the MRI object carried in GIST messages (see translation of fields in the MRI object carried in GIST messages (see
Section 7.2.2). The generic MRI format includes a flag that must be Section 7.2.2). The generic MRI format includes a flag that must be
given as part of the MRM definition, to indicate if some kind of given as part of the MRM definition, to indicate if some kind of
translation is necessary. Development of a new MRM therefore translation is necessary. Development of a new MRM therefore
includes updates to the GIST specification, and may include updates includes updates to the GIST specification, and may include updates
to specifications of NAT behaviour. These updates may be done in to specifications of NAT behaviour. These updates may be done in
separate documents as is the case for NAT traversal for the MRMs of separate documents as is the case for NAT traversal for the MRMs of
the base GIST specification, as described in Section 7.2.3 and [43]. the base GIST specification, as described in Section 7.2.3 and [42].
The MRI is passed explicitly between signalling applications and The MRI is passed explicitly between signalling applications and
GIST; therefore, signalling application specifications must define GIST; therefore, signalling application specifications must define
which MRMs they require. Signalling applications may use fields in which MRMs they require. Signalling applications may use fields in
the MRI in their packet classifiers; if they use additional the MRI in their packet classifiers; if they use additional
information for packet classification, this would be carried at the information for packet classification, this would be carried at the
NSLP level and so would be invisible to GIST. Any node hosting a NSLP level and so would be invisible to GIST. Any node hosting a
particular signalling application needs to use a GIST implementation particular signalling application needs to use a GIST implementation
that supports the corresponding MRMs. The GIST processing rules that supports the corresponding MRMs. The GIST processing rules
allow nodes not hosting the signalling application to ignore messages allow nodes not hosting the signalling application to ignore messages
for it at the GIST level, so it does not matter if these nodes for it at the GIST level, so it does not matter if these nodes
support the MRM or not. support the MRM or not.
3.4. GIST Messages 3.4. GIST Messages
GIST has six message types: Query, Response, Confirm, Data, Error, GIST has six message types: Query, Response, Confirm, Data, Error,
and MA-Hello. Apart from the invocation of the messaging association and MA-Hello. Apart from the invocation of the messaging association
protocols, all GIST communication consists of these messages. In protocols used by C-mode, all GIST communication consists of these
addition, all signalling application data is carried as additional messages. In addition, all signalling application data is carried as
payloads in these messages, alongside the GIST information. additional payloads in these messages, alongside the GIST
information.
The first three messages implement the handshake that GIST uses to The Query, Response and Confirm messages implement the handshake that
set up routing state and messaging associations. The handshake is GIST uses to set up routing state and messaging associations. The
initiated from the Querying node towards the Responding node. The handshake is initiated from the Querying node towards the Responding
first message is the Query, which is encapsulated in a special way node. The first message is the Query, which is encapsulated in a
depending on the message routing method, in order to probe the special way depending on the message routing method, in order to
network infrastructure so that the correct peer will intercept it and probe the network infrastructure so that the correct peer will
become the Responding node. A Query always triggers a Response in intercept it and become the Responding node. A Query always triggers
the reverse direction as the second message of the handshake. As a Response in the reverse direction as the second message of the
part of the defence against denial of service attacks, the Responding handshake. As part of the defence against denial of service attacks,
node can delay state installation until a return routability check, the Responding node can delay state installation until a return
and require the Querying node to complete the handshake with the routability check, and require the Querying node to complete the
Confirm. All of these three messages can optionally carry signalling handshake with the Confirm message. All of these three messages can
application data. The handshake is fully described in Section 4.4.1. optionally carry signalling application data. The handshake is fully
described in Section 4.4.1.
The Data message is used purely to encapsulate and deliver signalling The Data message is used purely to encapsulate and deliver signalling
application data. Usually it is sent using pre-established routing application data. Usually it is sent using pre-established routing
state. However, if there are no security or transport requirements state. However, if there are no security or transport requirements
and no need for persistent reverse routing state, it can also be sent 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 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 indicate error conditions at the GIST level, and the MA-Hello message
can be used as a diagnostic and keepalive for the messaging can be used as a diagnostic and keepalive for the messaging
association protocols. association protocols.
skipping to change at page 15, line 48 skipping to change at page 16, line 5
as normal Internet traffic. as normal Internet traffic.
Because this interception potentially breaks Internet transparency Because this interception potentially breaks Internet transparency
for packets which are nothing to do with GIST, the encapsulation used for packets which are nothing to do with GIST, the encapsulation used
by GIST in this case (called Query-mode or Q-mode) has several by GIST in this case (called Query-mode or Q-mode) has several
features to avoid accidental collisions with other traffic: features to avoid accidental collisions with other traffic:
o Q-mode messages are always sent as UDP traffic, and to a specific o Q-mode messages are always sent as UDP traffic, and to a specific
well-known port allocated by IANA. well-known port allocated by IANA.
o The first 32-bit word of the UDP datagram payload contains a magic o All GIST messages sent as UDP have a magic number as the first 32-
number. bit word of the datagram payload.
Even if a node intercepts a packet as potentially a GIST message, 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 unless it passes both these checks it will be ignored at the GIST
level and forward transparently. Further discussion of the reception level and forwarded transparently. Further discussion of the
process is in Section 4.3.1 and the encapsulation in Section 5.3.2. reception process is in Section 4.3.1 and the encapsulation in
Section 5.3.
3.7. Signalling Sessions 3.7. Signalling Sessions
GIST requires signalling applications to associate each of their GIST requires signalling applications to associate each of their
messages with a signalling session. Informally, given an application messages with a signalling session. Informally, given an application
layer exchange of information for which some network control state layer exchange of information for which some network control state
information is to be manipulated or monitored, the corresponding information is to be manipulated or monitored, the corresponding
signalling messages should be associated with the same session. signalling messages should be associated with the same session.
Signalling applications provide the session identifier (SID) whenever Signalling applications provide the session identifier (SID) whenever
they wish to send a message, and GIST reports the SID when a message they wish to send a message, and GIST reports the SID when a message
skipping to change at page 16, line 27 skipping to change at page 16, line 34
preserved unchanged. Usually, NSLPs will preserve the SID value preserved unchanged. Usually, NSLPs will preserve the SID value
along the entire signalling path, but this is not enforced by or even 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 visible to GIST, which only sees the scope of the SID as the single
hop between adjacent NSLP peers. hop between adjacent NSLP peers.
Most GIST processing and state information is related to the flow Most GIST processing and state information is related to the flow
(defined by the MRI, see above) and signalling application (given by (defined by the MRI, see above) and signalling application (given by
the NSLP identifier, see below). There are several possible the NSLP identifier, see below). There are several possible
relationships between flows and sessions, for example: relationships between flows and sessions, for example:
o The simplest case is that all messages for the same flow have the o The simplest case is that all signalling messages for the same
same SID. flow have the same SID.
o Messages for more than one flow may use the same SID, for example o Messages for more than one flow may use the same SID, for example
because one flow is replacing another in a mobility or multihoming because one flow is replacing another in a mobility or multihoming
scenario. scenario.
o A single flow may have messages for different SIDs, for example o A single flow may have messages for different SIDs, for example
from independently operating signalling applications. from independently operating signalling applications.
Because of this range of options, GIST does not perform any Because of this range of options, GIST does not perform any
validation on how signalling applications map between flows and validation on how signalling applications map between flows and
skipping to change at page 17, line 5 skipping to change at page 17, line 13
The SID assignment has the following impact on GIST processing: The SID assignment has the following impact on GIST processing:
o Messages with the same SID that are to be delivered reliably o Messages with the same SID that are to be delivered reliably
between the same GIST peers are delivered in order. between the same GIST peers are delivered in order.
o All other messages are handled independently. o All other messages are handled independently.
o GIST identifies routing state (upstream and downstream peer) by o GIST identifies routing state (upstream and downstream peer) by
the triplet (MRI, NSLP, SID). the triplet (MRI, NSLP, SID).
Strictly, the routing state should not depend on the SID. However, Strictly speaking, the routing state should not depend on the SID.
if the routing state is keyed only by (MRI, NSLP), there is a trivial However, if the routing state is keyed only by (MRI, NSLP), there is
denial of service attack (see Section 8.3) where a malicious off-path a trivial denial of service attack (see Section 8.3) where a
node asserts that it is the peer for a particular flow. Such an malicious off-path node asserts that it is the peer for a particular
attack would not redirect the traffic but would reroute the flow. Such an attack would not redirect the traffic but would
signalling. Instead, the routing state is also segregated between reroute the signalling. Instead, the routing state is also
different SIDs, which means that the attacking node can only disrupt segregated between different SIDs, which means that the attacking
a signalling session if it can guess the corresponding SID. node can only disrupt a signalling session if it can guess the
Normative rules on the selection of SIDs are given in Section 4.1.3. corresponding SID. Normative rules on the selection of SIDs are
given in Section 4.1.3.
3.8. Signalling Applications and NSLPIDs 3.8. Signalling Applications and NSLPIDs
The functionality for signalling applications is supported by NSIS The functionality for signalling applications is supported by NSIS
signalling layer protocols (NSLPs). Each NSLP is identified by a 16 signalling layer protocols (NSLPs). Each NSLP is identified by a 16
bit NSLP identifier (NSLPID), assigned by IANA (Section 9). A single bit NSLP identifier (NSLPID), assigned by IANA (Section 9). A single
signalling application, such as resource reservation, may define a signalling application, such as resource reservation, may define a
family of NSLPs to implement its functionality, for example to carry family of NSLPs to implement its functionality, for example to carry
out signalling operations at different levels in a hierarchy (cf. out signalling operations at different levels in a hierarchy (cf.
[23]). However, the interactions between the different NSLPs (for [23]). However, the interactions between the different NSLPs (for
skipping to change at page 18, line 35 skipping to change at page 18, line 44
the authentication process, and any GIST extension to incorporate the authentication process, and any GIST extension to incorporate
them would need to define the details of the corresponding them would need to define the details of the corresponding
interactions with GIST operation. interactions with GIST operation.
3.10. Example of Operation 3.10. Example of Operation
This section presents an example of GIST usage in a relatively simple This section presents an example of GIST usage in a relatively simple
(in particular, NAT-free) signalling scenario, to illustrate its main (in particular, NAT-free) signalling scenario, to illustrate its main
features. features.
Consider the case of an RSVP-like signalling application which Consider the case of an RSVP-like signalling application which makes
allocates resources for a single unicast flow. In general, receiver-based resource reservations for a single unicast flow. In
signalling can take place along the entire end-to-end path (between general, signalling can take place along the entire end-to-end path
flow source and destination), but the role of GIST is only to (between flow source and destination), but the role of GIST is only
transfer signalling messages over a single segment of the path, to transfer signalling messages over a single segment of the path,
between neighbouring resource-capable nodes. Basic GIST operation is between neighbouring resource-capable nodes. Basic GIST operation is
the same, whether it involves the endpoints or only interior nodes: the same, whether it involves the endpoints or only interior nodes:
in either case, GIST is triggered by a request from a local in either case, GIST is triggered by a request from a local
signalling application. The example here describes how GIST signalling application. The example here describes how GIST
transfers messages between two adjacent peers along the path, GN1 and transfers messages between two adjacent peers along the path, GN1 and
GN2 (see Figure 1 in Section 2). We take up the story at the point GN2 (see Figure 1 in Section 2). We take up the story at the point
where a message is being processed above the GIST layer by the where a message is being processed above the GIST layer by the
signalling application in GN1. signalling application in GN1.
1. The signalling application in GN1 determines that this message is 1. The signalling application in GN1 determines that this message is
skipping to change at page 20, line 13 skipping to change at page 20, line 23
that it will peer with GN1. There are two possible cases for that it will peer with GN1. There are two possible cases for
sending back the necessary GIST Response: sending back the necessary GIST Response:
6.A - Association Exists: GN1 and GN2 already have an 6.A - Association Exists: GN1 and GN2 already have an
appropriate MA. GN2 simply records the identity of GN1 as its appropriate MA. GN2 simply records the identity of GN1 as its
upstream peer for that flow and NSLP, and sends a Response upstream peer for that flow and NSLP, and sends a Response
back to GN1 over the MA identifying itself as the peer for back to GN1 over the MA identifying itself as the peer for
this flow. this flow.
6.B - No Association: GN2 sends the Response in D-mode directly 6.B - No Association: GN2 sends the Response in D-mode directly
to GN1, identifying itself and agreeing to the association to GN1, identifying itself and agreeing to the messaging
setup. The protocol exchanges needed to complete this will association setup. The protocol exchanges needed to complete
proceed in parallel with the following stages. this will proceed in parallel with the following stages.
In each case, the result is that GN1 and GN2 are now in a peering In each case, the result is that GN1 and GN2 are now in a peering
relationship for the flow. relationship for the flow.
7. Eventually, another NSLP message works its way upstream from the 7. Eventually, another NSLP message works its way upstream from the
receiver to GN2. This message contains a description of the receiver to GN2. This message contains a description of the
actual resources requested, along with authorisation and other actual resources requested, along with authorisation and other
security information. The signalling application in GN2 passes security information. The signalling application in GN2 passes
this payload to the GIST level, along with the flow definition this payload to the GIST level, along with the flow definition
and transfer attributes; in this case, it could request reliable and transfer attributes; in this case, it could request reliable
skipping to change at page 21, line 50 skipping to change at page 22, line 50
Appendix B. Appendix B.
4.1.1. Message Handling 4.1.1. Message Handling
Fundamentally, GIST provides a simple message-by-message transfer Fundamentally, GIST provides a simple message-by-message transfer
service for use by signalling applications: individual messages are service for use by signalling applications: individual messages are
sent, and individual messages are received. At the service sent, and individual messages are received. At the service
interface, the NSLP payload, which is opaque to GIST, is accompanied interface, the NSLP payload, which is opaque to GIST, is accompanied
by control information expressing the application's requirements by control information expressing the application's requirements
about how the message should be routed, and the application also about how the message should be routed, and the application also
provides the session identifier (see Section 4.1.3). Additional provides the session identifier (SID), see Section 4.1.3. Additional
message transfer attributes control the specific transport and message transfer attributes control the specific transport and
security properties that the signalling application desires. security properties that the signalling application desires.
The distinction between GIST D- and C-mode is not visible at the The distinction between GIST D- and C-mode is not visible at the
service interface. In addition, the functionality to handle service interface. In addition, the functionality to handle
fragmentation and reassembly, bundling together of small messages for fragmentation and reassembly, bundling together of small messages for
efficiency, and congestion control are not visible at the service efficiency, and congestion control are not visible at the service
interface; GIST will take whatever action is necessary based on the interface; GIST will take whatever action is necessary based on the
properties of the messages and local node state. properties of the messages and local node state.
skipping to change at page 23, line 31 skipping to change at page 24, line 31
if routing state exists, the NSLP may request that it is not used, if routing state exists, the NSLP may request that it is not used,
which will lead to data being sent Q-mode encapsulated instead. which will lead to data being sent Q-mode encapsulated instead.
4.1.3. SID Selection 4.1.3. SID Selection
The fact that SIDs index routing state (see Section 4.2.1 below) The fact that SIDs index routing state (see Section 4.2.1 below)
means that there are requirements for how they are selected. means that there are requirements for how they are selected.
Specifically, signalling applications MUST choose SIDs so that they Specifically, signalling applications MUST choose SIDs so that they
are cryptographically random, and SHOULD NOT use several SIDs for the are cryptographically random, and SHOULD NOT use several SIDs for the
same flow, to avoid additional load from routing state maintenance. same flow, to avoid additional load from routing state maintenance.
Guidance on secure randomness generation can be found in [33]. Guidance on secure randomness generation can be found in [32].
4.2. GIST State 4.2. GIST State
4.2.1. Message Routing State 4.2.1. Message Routing State
For each flow, the GIST layer can maintain message routing state to For each flow, the GIST layer can maintain message routing state to
manage the processing of outgoing messages. This state is manage the processing of outgoing messages. This state is
conceptually organised into a table with the following structure. conceptually organised into a table with the following structure.
Each row in the table corresponds to a unique combination of the Each row in the table corresponds to a unique combination of the
information about how the message is to be routed, the session being following three items:
signalled for, and the signalling application itself:
Message Routing Information (MRI): This defines the method to be Message Routing Information (MRI): This defines the method to be
used to route the message, the direction in which to send the used to route the message, the direction in which to send the
message, and any associated addressing information; see message, and any associated addressing information; see
Section 3.3. Section 3.3.
Session Identification (SID): The signalling session with which this Session Identification (SID): The signalling session with which this
message should be associated; see Section 3.7. message should be associated; see Section 3.7.
NSLP Identification (NSLPID): This is an IANA-assigned identifier NSLP Identification (NSLPID): This is an IANA-assigned identifier
skipping to change at page 24, line 40 skipping to change at page 25, line 37
because it is acting as a proxy, or because it has determined that because it is acting as a proxy, or because it has determined that
there are no further signalling nodes in that direction. there are no further signalling nodes in that direction.
o The node is using other techniques to send the message. For o The node is using other techniques to send the message. For
example, it can send it in Q-mode and rely on the peer to example, it can send it in Q-mode and rely on the peer to
intercept it. intercept it.
In addition, if the node is a flow endpoint, GIST will refuse to In addition, if the node is a flow endpoint, GIST will refuse to
create routing state for the direction beyond the end of the flow create routing state for the direction beyond the end of the flow
(see Section 4.3.3). Each entry in the routing state table has an (see Section 4.3.3). Each entry in the routing state table has an
associated validity timer for how long it can be considered accurate; associated validity timer indicating for how long it can be
when this timer expires, the entry MUST be purged if it has not been considered accurate. When this timer expires, the entry MUST be
refreshed. Installation and maintenance of routing state is purged if it has not been refreshed. Installation and maintenance of
described in more detail in Section 4.4. routing state is described in more detail in Section 4.4.
Note also that the routing state is described as a table of per-flow
entries, but that there is no implied constraint on how the
information is stored. However, in general, and especially if GIST
peers are several IP hops away, there is no way to identify the
correct downstream peer for a flow and signalling application from
the local forwarding table using prefix matching, and the same
applies always to upstream peer state because of the possibility of
asymmetric IP routing: prefix aggregation is not possible, and per-
flow state has to be stored, just as for RSVP [16].
4.2.2. Peer-Peer Messaging Association State 4.2.2. Peer-Peer Messaging Association State
The per-flow message routing state is not the only state stored by 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 GIST. There is also the state required to manage the MAs. Since
these are not per-flow, they are stored separately from the routing these are not per-flow, they are stored separately from the routing
state, including the following per-MA information: state, including the following per-MA information:
o a queue of messages pending transmission while an MA is being o a queue of messages pending transmission while an MA is being
established; established;
o a timer for how long since the peer re-stated its desire to keep o the time since the peer re-stated its desire to keep the MA open
the MA open (see Section 4.4.5). (see Section 4.4.5).
In addition, per-MA state is held in the messaging association In addition, per-MA state is held in the messaging association
protocols themselves. However, the details of this state are not protocols themselves. However, the details of this state are not
directly visible to GIST, and they do not affect the rest of the directly visible to GIST, and they do not affect the rest of the
protocol description. protocol description.
4.3. Basic GIST Message Processing 4.3. Basic GIST Message Processing
This section describes how signalling application messages are This section describes how signalling application messages are
processed in the case where any necessary messaging associations and processed in the case where any necessary messaging associations and
skipping to change at page 27, line 30 skipping to change at page 28, line 30
level. If it does match, the GIST MUST check the NSLPID in the level. If it does match, the GIST MUST check the NSLPID in the
common header. The case where the NSLPID does not match a local common header. The case where the NSLPID does not match a local
signalling application at all is considered below in signalling application at all is considered below in
Section 4.3.4; otherwise, the message MUST be passed up to the Section 4.3.4; otherwise, the message MUST be passed up to the
GIST layer for further processing. GIST layer for further processing.
Several different RAO values may be used by the NSIS protocol suite. Several different RAO values may be used by the NSIS protocol suite.
GIST itself does not allocate any RAO values (for either IPv4 or 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 IPv6); an assignment is made for each NSLP using MRMs that use the
RAO in the Q-mode encapsulation. The assignment rationale is RAO in the Q-mode encapsulation. The assignment rationale is
discussed in [15]. The RAO value assigned for an NSLPID may be discussed in [14]. The RAO value assigned for an NSLPID may be
different for IPv4 and IPv6. Note the different significance between different for IPv4 and IPv6. Note the different significance between
the RAO and the NSLPID values: the meaning of a message (which the RAO and the NSLPID values: the meaning of a message (which
signalling application it refers to, whether it should be processed signalling application it refers to, whether it should be processed
at a node) is determined only from the NSLPID; the role of the RAO 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 value is simply to allow nodes to pre-filter which IP datagrams are
analysed to see if they might be Q-mode GIST messages. analysed to see if they might be Q-mode GIST messages.
For all assignments associated with NSIS, the RAO specific processing For all assignments associated with NSIS, the RAO specific processing
is the same and is as defined by this specification, here and in is the same and is as defined by this specification, here and in
Section 4.3.4 and Section 5.3.2. Section 4.3.4 and Section 5.3.2.
Immediately after reception, the GIST hop count is checked. Any Immediately after reception, the GIST hop count is checked. Any
message with a GIST hop count of zero MUST be rejected with a "Hop message with a GIST hop count of zero MUST be rejected with a "Hop
Limit Exceeded" error message (Appendix A.4.4.2), following which the Limit Exceeded" error message (Appendix A.4.4.2). Otherwise, the
GIST hop count MUST be decremented by one. GIST hop count MUST be decremented by one.
4.3.2. Local Processing and Validation 4.3.2. Local Processing and Validation
Once a message has been received, it is processed locally within the Once a message has been received, it is processed locally within the
GIST layer. Further processing depends on the message type and GIST layer. Further processing depends on the message type and
payloads carried; most of the GIST payloads are associated with payloads carried; most of the GIST payloads are associated with
internal state maintenance, and details are covered in Section 4.4. internal state maintenance, and details are covered in Section 4.4.
This section concentrates on the interaction with the signalling This section concentrates on the interaction with the signalling
skipping to change at page 30, line 6 skipping to change at page 31, line 6
policy and the stored routing state to determine how to handle it. policy and the stored routing state to determine how to handle it.
The following processing applies equally to locally generated The following processing applies equally to locally generated
messages and messages forwarded from within the GIST or signalling messages and messages forwarded from within the GIST or signalling
application levels. However, see Section 5.6 for special rules application levels. However, see Section 5.6 for special rules
applying to the transmission of error messages by GIST. applying to the transmission of error messages by GIST.
The main decision is whether the message must be sent in C-mode or The main decision is whether the message must be sent in C-mode or
D-mode. Reasons for using C-mode are: D-mode. Reasons for using C-mode are:
o message transfer attributes: for example, the signalling o message transfer attributes: for example, the signalling
application has requested channel secured delivery, or reliable application has requested channel-secured delivery, or reliable
delivery. delivery.
o message size: a message whose size (including the GIST header, o message size: a message whose size (including the GIST header,
GIST objects and any NSLP payload, and an allowance for the IP and GIST objects and any NSLP payload, and an allowance for the IP and
transport layer encapsulation required by D-mode) exceeds a transport layer encapsulation required by D-mode) exceeds a
fragmentation-related threshold MUST be sent over C-mode, using a fragmentation-related threshold MUST be sent over C-mode, using a
messaging association that supports fragmentation and reassembly messaging association that supports fragmentation and reassembly
internally. The allowance for IP and transport layer internally. The allowance for IP and transport layer
encapsulation is 64 bytes. If the Path MTU to the next peer is encapsulation is 64 bytes. The message size MUST NOT exceed the
known, the message size MUST NOT exceed that Path MTU; if the Path least of the following three quantities: the Path MTU to the next
MTU is not known, the message size MUST NOT exceed 576 bytes. The peer (if known), the first-hop MTU, and 576 bytes. The same limit
same limit applies to IPv4 and IPv6. applies to IPv4 and IPv6.
o local policy: for example, a node MAY send messages over a o congestion control: D-mode SHOULD NOT be used for signalling where
messaging association solely to benefit from adaptive congestion it is possible to set up routing state and use C-mode, unless the
control. network can be engineered to guarantee capacity for D-mode traffic
within the rate control limits imposed by GIST (see
Section 5.3.3).
In principle, as well as determining that some messaging association In principle, as well as determining that some messaging association
must be used, GIST MAY select between a set of alternatives, e.g. for must be used, GIST MAY select between a set of alternatives, e.g. for
load sharing or because different messaging associations provide load sharing or because different messaging associations provide
different transport or security attributes. For the case of reliable different transport or security attributes. For the case of reliable
delivery, GIST MUST NOT distribute messages for the same session over delivery, GIST MUST NOT distribute messages for the same session over
multiple messaging associations in parallel, but MUST use a single multiple messaging associations in parallel, but MUST use a single
association at any given time. The case of moving over to a new association at any given time. The case of moving over to a new
association is covered in Section 4.4.5. association is covered in Section 4.4.5.
If the use of a messaging association is selected, the message is If the use of a messaging association (i.e. C-mode) is selected, the
queued on the association found from the routing state table, and message is queued on the association found from the routing state
further output processing is carried out according to the details of table, and further output processing is carried out according to the
the protocol stacks used. If no appropriate association exists, the details of the protocol stacks used. If no appropriate association
message is queued while one is created (see Section 4.4.1), which exists, the message is queued while one is created (see
will trigger the exchange of additional GIST messages. If no Section 4.4.1), which will trigger the exchange of additional GIST
association can be created, this is an error condition, and should be messages. If no association can be created, this is an error
indicated back to the local signalling application. condition, and should be indicated back to the local signalling
application.
If a messaging association is not required, the message is sent in If a messaging association is not required, the message is sent in
D-mode. The processing in this case depends on the message type and D-mode. The processing in this case depends on the message type and
whether routing state exists or not. whether routing state exists or not.
o If the message is not a Query, and routing state exists, it is o If the message is not a Query, and routing state exists, it is
sent with the normal D-mode encapsulation directly to the address sent with the normal D-mode encapsulation directly to the address
from the routing state table. from the routing state table.
o If the message is a Query, then it is sent in Q-mode as defined in o If the message is a Query, then it is sent in Q-mode as defined in
(Section 5.3.2); the details depend on the message routing method. (Section 5.3.2); the details depend on the message routing method.
o If no routing state exists, GIST can attempt to use Q-mode as in o If no routing state exists, GIST can attempt to use Q-mode as in
the Query case. If this is not possible, e.g. because the the Query case: either sending a Data message with the Q-mode
encapsulation for the MRM is only defined for one message encapsulation, or using the event as a trigger for routing state
setup (see Section 4.4). If this is not possible, e.g. because
the encapsulation for the MRM is only defined for one message
direction, then this is an error condition which is reported back direction, then this is an error condition which is reported back
to the local signalling application. to the local signalling application.
4.3.4. Nodes not Hosting the NSLP 4.3.4. Nodes not Hosting the NSLP
A node may receive messages where it has no signalling application A node may receive messages where it has no signalling application
corresponding to the message NSLPID. There are several possible corresponding to the message NSLPID. There are several possible
cases depending mainly on the encapsulation: cases depending mainly on the encapsulation:
1. A message contains an RAO value which is relevant to NSIS, but it 1. A message contains an RAO value which is relevant to NSIS, but it
skipping to change at page 31, line 52 skipping to change at page 33, line 9
"Endpoint Found" informational message (Appendix A.4.4.7). The "Endpoint Found" informational message (Appendix A.4.4.7). The
end-system includes the MRI and SID from the original message in end-system includes the MRI and SID from the original message in
the error message without interpreting them. the error message without interpreting them.
6. The node is GIST-aware NAT. See Section 7.2. 6. The node is GIST-aware NAT. See Section 7.2.
In cases (2) and (3), the role of GIST is to forward the message 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 essentially as though it were a normal IP datagram, and it will not
become a peer to the node sending the message. Forwarding with become a peer to the node sending the message. Forwarding with
modified NSLP payloads is covered above in Section 4.3.2. However, a modified NSLP payloads is covered above in Section 4.3.2. However, a
GIST implementation must ensure that the IP-layer TTL field and GIST GIST implementation MUST ensure that the IP-layer TTL field and GIST
hop count are managed correctly to prevent message looping, and this hop count are managed correctly to prevent message looping, and this
should be done consistently independently of whether the processing should be done consistently independently of whether the processing
takes place on the fast path or in GIST-specific code. The rules are 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 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 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 GIST hop count MUST be decremented as in the case of normal input
processing, which also applies to cases (4) and (5). processing, which also applies to cases (4) and (5).
A GIST node processing Q-mode encapsulated messages in this way A GIST node processing Q-mode encapsulated messages in this way
SHOULD make the routing decision based on the full contents of the SHOULD make the routing decision based on the full contents of the
skipping to change at page 33, line 20 skipping to change at page 34, line 27
1. Where routing state is being discovered or a new association is 1. Where routing state is being discovered or a new association is
to be established; and to be established; and
2. Where a suitable association already exists, including the case 2. Where a suitable association already exists, including the case
where routing state for the flow is being refreshed. where routing state for the flow is being refreshed.
These cases are now considered in turn, followed by the case of These cases are now considered in turn, followed by the case of
background general management procedures. background general management procedures.
4.4.1. State Setup 4.4.1. Routing State and Messaging Association Creation
The complete sequence of possible messages for GIST state setup The complete sequence of possible messages for GIST state setup
between adjacent peers is shown in Figure 4 and described in detail between adjacent peers is shown in Figure 4 and described in detail
in the following text. The figure informally summarises the contents in the following text. The figure informally summarises the contents
of each message, including optional elements in square brackets. An of each message, including optional elements in square brackets. An
example is given in Appendix D. example is given in Appendix D.
The initial message in any routing state maintenance operation is a The initial message in any routing state maintenance operation is a
Query, sent from the querying node and intercepted at the responding Query, sent from the querying node and intercepted at the responding
node. This message has addressing and other identifiers appropriate node. This message has addressing and other identifiers appropriate
skipping to change at page 34, line 16 skipping to change at page 36, line 16
| Querying | |Responding| | Querying | |Responding|
| Node(Q-N)| | Node(R-N)| | Node(Q-N)| | Node(R-N)|
+----------+ +----------+ +----------+ +----------+
Query Query
----------------------> ............. ----------------------> .............
Router Alert Option . Routing . Router Alert Option . Routing .
MRI/SID/NSLPID . state . MRI/SID/NSLPID . state .
Q-N Network Layer Info . installed . Q-N Network Layer Info . installed .
Query Cookie . at . Query Cookie . at .
[Q-N Stack-Proposal . Responding. [Q-N Stack-Proposal . Responding.
Q-N Stack-Config-Data] . node (1) . Q-N Stack-Config-Data] . node .
[NSLP Payload] ............. [NSLP Payload] . (case 1) .
.............
...................................... ......................................
. The responder can use an existing . . The responder can use an existing .
. messaging association if available . . messaging association if available .
. from here onwards to short-circuit . . from here onwards to short-circuit .
. messaging association setup . . messaging association setup .
...................................... ......................................
Response Response
............. <---------------------- ............. <----------------------
. Routing . MRI/SID/NSLPID . Routing . MRI/SID/NSLPID
skipping to change at page 34, line 42 skipping to change at page 36, line 42
. Querying . [R-N Stack-Proposal . Querying . [R-N Stack-Proposal
. node . R-N Stack-Config-Data]] . node . R-N Stack-Config-Data]]
............. [NSLP Payload] ............. [NSLP Payload]
.................................... ....................................
. If a messaging association needs . . If a messaging association needs .
. to be created, it is set up here . . to be created, it is set up here .
. and the Confirm uses it . . and the Confirm uses it .
.................................... ....................................
Confirm Confirm .............
----------------------> ............. ----------------------> . Routing .
MRI/SID/NSLPID . Routing . MRI/SID/NSLPID . state .
Q-N Network Layer Info . state . Q-N Network Layer Info . installed .
[Responder Cookie . installed . [Responder Cookie . at .
[R-N Stack-Proposal . at . [R-N Stack-Proposal . Responding.
[Q-N Stack-Config-Data]]] . Responding. [Q-N Stack-Config-Data]]] . node .
[NSLP Payload] . node (2) . [NSLP Payload] . (case 2) .
............. .............
Figure 4: Message Sequence at State Setup Figure 4: Message Sequence at State Setup
Setup of a new messaging association begins when peer addressing Setup of a new messaging association begins when peer addressing
information is available and a new messaging association is actually information is available and a new messaging association is actually
needed. Any setup MUST take place immediately after the specific needed. Any setup MUST take place immediately after the specific
Query/Response exchange, because the addressing information used may Query/Response exchange, because the addressing information used may
have a limited lifetime, either because it depends on limited have a limited lifetime, either because it depends on limited
lifetime NAT bindings or because it refers to agile destination ports lifetime NAT bindings or because it refers to agile destination ports
skipping to change at page 35, line 40 skipping to change at page 37, line 40
the Confirm has been sent, the Querying node assumes that routing the Confirm has been sent, the Querying node assumes that routing
state has been installed at the responder, and can send normal Data state has been installed at the responder, and can send normal Data
messages for the flow in question; recovery from a lost Confirm is messages for the flow in question; recovery from a lost Confirm is
discussed in Section 5.3.3. If a messaging association is being discussed in Section 5.3.3. If a messaging association is being
used, the Confirm MUST be sent over it before any other messages for 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 the same flow, and it echoes the Responder Cookie and Stack-Proposal
from the Response. The former is used to allow the receiver to from the Response. The former is used to allow the receiver to
validate the contents of the message (see Section 8.5), and the validate the contents of the message (see Section 8.5), and the
latter is to prevent certain bidding-down attacks on messaging latter is to prevent certain bidding-down attacks on messaging
association security (see Section 8.6). This first Confirm on a new association security (see Section 8.6). This first Confirm on a new
association MUST also contain an abbreviated form of the original association MUST also contain a Stack-Configuration-Data object
Stack-Configuration-Data to finalise details of the messaging carrying an MA-Hold-Time value, which supersedes the value given in
association configuration. The association can be used in the the original Query. The association can be used in the upstream
upstream direction for the MRI and NSLPID carried in the Confirm, direction for the MRI and NSLPID carried in the Confirm, after the
after the Confirm has been received. Confirm has been received.
The querying node MUST install the responder address, derived from The querying node MUST install the responder address, derived from
the R-Node Network Layer info, as routing state information after the R-Node Network Layer info, as routing state information after
verifying the Query Cookie in the Response. The responding node MAY verifying the Query Cookie in the Response. The responding node MAY
install the querying address as peer state information at two points install the querying address as peer state information at two points
in time: in time:
1. after the receipt of the initial Query, or Case 1: after the receipt of the initial Query, or
2. after a Confirm containing the Responder Cookie. Case 2: after a Confirm containing the Responder Cookie.
The responding node SHOULD derive the peer address from the Q-Node The responding node SHOULD derive the peer address from the Q-Node
Network Layer Info if this was decoded successfully. Otherwise, it Network Layer Info if this was decoded successfully. Otherwise, it
MAY be derived from the IP source address of the message if the MAY be derived from the IP source address of the message if the
common header flags this as being the signalling source address. The common header flags this as being the signalling source address. The
precise constraints on when state information is installed are a precise constraints on when state information is installed are a
matter of security policy considerations on prevention of denial-of- matter of security policy considerations on prevention of denial-of-
service attacks and state poisoning attacks, which are discussed service attacks and state poisoning attacks, which are discussed
further in Section 8. Because the responding node MAY choose to further in Section 8. Because the responding node MAY choose to
delay state installation as in case (2), the Confirm must contain delay state installation as in case (2), the Confirm must contain
skipping to change at page 36, line 45 skipping to change at page 38, line 45
level flow control rules, and not to attempt to create overload level flow control rules, and not to attempt to create overload
situations. situations.
o Authorised peers are trusted not to send erroneous or malicious o Authorised peers are trusted not to send erroneous or malicious
error messages, for example asserting that routing state has been error messages, for example asserting that routing state has been
lost when it has not. lost when it has not.
This specification models the decision as verification by the This specification models the decision as verification by the
authorising node of the peer's identity against a local list of authorising node of the peer's identity against a local list of
peers, the authorised peer database (APD). The APD is a abstract peers, the authorised peer database (APD). The APD is a abstract
construct, similar to the security policy database of IPsec [39]. construct, similar to the security policy database of IPsec [37].
Implementations MAY provide the associated functionality in any way Implementations MAY provide the associated functionality in any way
they choose. This section defines only the requirements for APD they choose. This section defines only the requirements for APD
administration and the consequences of successfully validating a administration and the consequences of successfully validating a
peer's identity against it. peer's identity against it.
The APD consists of a list of entries. Each entry includes an The APD consists of a list of entries. Each entry includes an
identity, the namespace from which the identity comes (e.g. DNS identity, the namespace from which the identity comes (e.g. DNS
domains), the scope within which the entry is applicable, and whether domains), the scope within which the entry is applicable, and whether
authorisation is allowed or denied. The following are example authorisation is allowed or denied. The following are example
scopes: scopes:
skipping to change at page 38, line 26 skipping to change at page 40, line 26
signalling path to external destinations, and this could be signalling path to external destinations, and this could be
distributed to all hosts inside the network. Regardless of the distributed to all hosts inside the network. Regardless of the
technique, it MUST be ensured that the source data justify the technique, it MUST be ensured that the source data justify the
authorisation decisions listed at the start of this section, and that authorisation decisions listed at the start of this section, and that
the security of the chain of operations on which the APD entry the security of the chain of operations on which the APD entry
depends cannot be compromised. depends cannot be compromised.
4.4.3. Messaging Association Multiplexing 4.4.3. Messaging Association Multiplexing
It is a design goal of GIST that, as far as possible, a single It is a design goal of GIST that, as far as possible, a single
messaging association should be used for multiple flows and sessions, messaging association should be used for multiple flows and sessions
rather than setting up a new MA for each. This re-use of existing between two peers, rather than setting up a new MA for each. This
MAs is referred to as messaging association multiplexing. re-use of existing MAs is referred to as messaging association
Multiplexing ensures that the MA cost scales only with the number of multiplexing. Multiplexing ensures that the MA cost scales only with
peers, and avoids the latency of new MA setup where possible. the number of peers, and avoids the latency of new MA setup where
possible.
However, multiplexing requires the identification of an existing MA However, multiplexing requires the identification of an existing MA
which matches the same routing state and desired properties that which matches the same routing state and desired properties that
would be the result of a full handshake in D-mode, and this would be the result of a full handshake in D-mode, and this
identification must be done as reliably and securely as continuing identification must be done as reliably and securely as continuing
with the full procedure. Note that this requirement is complicated with the full procedure. Note that this requirement is complicated
by the fact that NATs may remap the node addresses in D-mode 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 messages, and also interacts with the fact that some nodes may peer
over multiple interfaces (and thus with different addresses). over multiple interfaces (and thus with different addresses).
skipping to change at page 39, line 33 skipping to change at page 41, line 35
can be either a Query or Response, although the former is more can be either a Query or Response, although the former is more
likely: likely:
o If there is a perfect match to the NLI of an existing association, o If there is a perfect match to the NLI of an existing association,
that association SHOULD be re-used, provided it meets the criteria that association SHOULD be re-used, provided it meets the criteria
on security and transport properties given at the end of on security and transport properties given at the end of
Section 5.7.1. This is indicated by sending the remaining Section 5.7.1. This is indicated by sending the remaining
messages in the handshake over that association. This will lead messages in the handshake over that association. This will lead
to multiplexing on an association to the wrong node if signalling to multiplexing on an association to the wrong node if signalling
nodes have colliding Peer-Identities and one is reachable at the nodes have colliding Peer-Identities and one is reachable at the
same Interface-Address as another. This could be done by an on- same Interface-Address as another. This could be caused by an on-
path attacker; on-path attacks are discussed further in path attacker; on-path attacks are discussed further in
Section 8.7. When multiplexing is done, and the original MA Section 8.7. When multiplexing is done, and the original MA
authorisation was MRI-dependent, the verification steps of authorisation was MRI-dependent, the verification steps of
Section 4.4.2 MUST be repeated for the new flow. Section 4.4.2 MUST be repeated for the new flow.
o In all other cases, the full handshake MUST be executed in D-mode o In all other cases, the full handshake MUST be executed in D-mode
as usual. There are in fact four possibilities: as usual. There are in fact four possibilities:
1. Nothing matches: this is clearly a new peer. 1. Nothing matches: this is clearly a new peer.
skipping to change at page 41, line 10 skipping to change at page 43, line 11
This specification defines precisely only the time at which routing This specification defines precisely only the time at which routing
state expires; it does not define when refresh handshakes should be state expires; it does not define when refresh handshakes should be
initiated. Implementations MUST select timer settings which take at initiated. Implementations MUST select timer settings which take at
least the following into account: least the following into account:
o The transmission latency between source and destination; o The transmission latency between source and destination;
o The need for retransmissions of Query messages; o The need for retransmissions of Query messages;
o The need to avoid network synchronisation of control traffic (cf. o The need to avoid network synchronisation of control traffic (cf.
[41]). [40]).
In most cases, a reasonable policy is to initiate the routing state 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 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 since the last successful refresh. The actual moment MUST be chosen
randomly within this interval to avoid synchronisation effects. randomly within this interval to avoid synchronisation effects.
4.4.5. Messaging Association Maintenance 4.4.5. Messaging Association Maintenance
Unneeded MAs are torn down by GIST, using the teardown mechanisms of Unneeded MAs are torn down by GIST, using the teardown mechanisms of
the underlying transport or security protocols if available, for the underlying transport or security protocols if available, for
example by simply closing a TCP connection. The teardown can be example by simply closing a TCP connection. The teardown can be
initiated by either end. Whether an MA is needed is a combination of initiated by either end. Whether an MA is needed is a combination of
two factors: two factors:
o local policy, which could take into account the cost of keeping o local policy, which could take into account the cost of keeping
the messaging association open, the level of past activity on the the messaging association open, the level of past activity on the
association, and the likelihood of future activity, e.g. if there association, and the likelihood of future activity, e.g. if there
is routing state still in place which might generate messages to is routing state still in place which might generate messages to
use it. use it.
o whether the peer still wants the MA in place. During MA setup, o whether the peer still wants the MA to remain in place. During MA
each node indicates its own MA-Hold-Time as part of the Stack- setup, as part of the Stack-Configuration-Data, each node
Configuration-Data. A node MUST NOT tear down the MA if it has advertises its own MA-Hold-Time, which is the time for which it
received traffic from its peer over that period. A peer which has will retain an MA which is not carrying signalling traffic. A
generated no traffic but still wants the MA retained may use a node MUST NOT tear down an MA if it has received traffic from its
special null message (MA-Hello) to indicate the fact. A default peer over that period. A peer which has generated no traffic but
value for MA-Hold-Time of 30 seconds is RECOMMENDED. Nodes MAY still wants the MA retained can use a special null message (MA-
use shorter times to achieve more rapid peer failure detection, Hello) to indicate the fact. A default value for MA-Hold-Time of
but need to take into account the load on the network created by 30 seconds is RECOMMENDED. Nodes MAY use shorter times to achieve
the MA-Hello messages. Nodes MAY use longer times, but need to more rapid peer failure detection, but need to take into account
take into account the cost of retaining idle MAs for extended the load on the network created by the MA-Hello messages. Nodes
periods. Nodes MAY take signalling application behaviour (e.g. MAY use longer times, but need to take into account the cost of
NSLP refresh times) into account in choosing an appropriate value. retaining idle MAs for extended periods. Nodes MAY take
signalling application behaviour (e.g. NSLP refresh times) into
account in choosing an appropriate value.
Because the Responding node can choose not to create state until a Because the Responding node can choose not to create state until a
Confirm, an abbreviated Stack-Configuration-Data object containing Confirm, an abbreviated Stack-Configuration-Data object containing
just this information MUST be repeated by the Querying node in the just this information MUST be repeated by the Querying node in the
first Confirm sent on a new MA. If the object is missing in the first Confirm sent on a new MA. If the object is missing in the
Confirm, an "Object Type Error" message (Appendix A.4.4.9) with Confirm, an "Object Type Error" message (Appendix A.4.4.9) with
subcode 2 ("Missing Object") MUST be returned. subcode 2 ("Missing Object") MUST be returned.
Messaging associations can always be set up on demand, and messaging Messaging associations can always be set up on demand, and messaging
association status is not made directly visible outside the GIST association status is not made directly visible outside the GIST
skipping to change at page 42, line 29 skipping to change at page 44, line 33
associations expires; it does not define when keepalives should be associations expires; it does not define when keepalives should be
initiated. Implementations MUST select timer settings which take at initiated. Implementations MUST select timer settings which take at
least the following into account: least the following into account:
o The transmission latency between source and destination; o The transmission latency between source and destination;
o The need for retransmissions within the messaging association o The need for retransmissions within the messaging association
protocols; protocols;
o The need to avoid network synchronisation of control traffic (cf. o The need to avoid network synchronisation of control traffic (cf.
[41]). [40]).
In most cases, a reasonable policy is to initiate the MA refresh when 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 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 successful refresh. The actual moment MUST be chosen randomly within
this interval to avoid synchronisation effects. this interval to avoid synchronisation effects.
4.4.6. Routing State Failures 4.4.6. Routing State Failures
A GIST node can receive a message from a GIST peer, which can only be 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 correctly processed in the context of some routing state, but where
skipping to change at page 44, line 11 skipping to change at page 46, line 17
Querying node: The node MUST restart the GIST handshake from the Querying node: The node MUST restart the GIST handshake from the
beginning, with a new Query. beginning, with a new Query.
Responding node: The node MUST delete its own routing state and Responding node: The node MUST delete its own routing state and
SHOULD report an error condition to the local signalling SHOULD report an error condition to the local signalling
application. application.
The rules at the Querying or Responding node make GIST open to The rules at the Querying or Responding node make GIST open to
disruption by randomly injected error messages, similar to blind disruption by randomly injected error messages, similar to blind
reset attacks on TCP (cf. [45]), although because routing state reset attacks on TCP (cf. [44]), although because routing state
matching includes the SID this is mainly limited to on-path matching includes the SID this is mainly limited to on-path
attackers. If a GIST node detects a significant rate of such attackers. If a GIST node detects a significant rate of such
attacks, it MAY adopt a policy of using secured messaging attacks, it MAY adopt a policy of using secured messaging
associations to communicate for the affected MRIs, and only accepting associations to communicate for the affected MRIs, and only accepting
"No Routing State" error messages over such associations. "No Routing State" error messages over such associations.
5. Message Formats and Transport 5. Message Formats and Transport
5.1. GIST Messages 5.1. GIST Messages
All GIST messages begin with a common header, followed by a sequence All GIST messages begin with a common header, followed by a sequence
of type-length-value (TLV) objects. This subsection describes the of type-length-value (TLV) objects. This subsection describes the
various GIST messages and their contents at a high level in ABNF various GIST messages and their contents at a high level in ABNF
[13]; a more detailed description of the header and each object is [12]; a more detailed description of the header and each object is
given in Section 5.2. Note that the NAT traversal mechanism for GIST given in Section 5.2. Note that the NAT traversal mechanism for GIST
involves the insertion of an additional NAT-Traversal-Object in involves the insertion of an additional NAT-Traversal-Object in
Query, Response, and some Data and Error messages; the rules for this Query, Response, and some Data and Error messages; the rules for this
are given in Section 7.2. are given in Section 7.2.
GIST-Message: The primary messages are either one of the stages in GIST-Message: The primary messages are either one of the stages in
the three-way handshake, or a simple message carrying NSLP data. the three-way handshake, or a simple message carrying NSLP data.
Additional types are defined for errors and keeping messaging Additional types are defined for errors and keeping messaging
associations alive. associations alive.
GIST-Message = Query / Response / Confirm / GIST-Message = Query / Response / Confirm /
skipping to change at page 45, line 34 skipping to change at page 47, line 34
The common header includes a version number, message type and size, The common header includes a version number, message type and size,
and NSLPID. It also carries a hop count to prevent infinite message and NSLPID. It also carries a hop count to prevent infinite message
looping and various control flags, including one (the R flag) to looping and various control flags, including one (the R flag) to
indicate if a reply of some sort is requested. The objects following indicate if a reply of some sort is requested. The objects following
the common header MUST be carried in a fixed order, depending on the common header MUST be carried in a fixed order, depending on
message type. Messages with missing, duplicate or invalid objects message type. Messages with missing, duplicate or invalid objects
for the message type MUST be rejected with an "Object Type Error" for the message type MUST be rejected with an "Object Type Error"
message with the appropriate subcode (Appendix A.4.4.9). message with the appropriate subcode (Appendix A.4.4.9).
Query: A Query MUST be sent in D-mode, in fact with the special Query: A Query MUST be sent in D-mode using the special Q-mode
Q-mode encapsulation. In addition to the common header, it contains encapsulation. In addition to the common header, it contains certain
certain mandatory control objects, and MAY contain a signalling mandatory control objects, and MAY contain a signalling application
application payload. A stack proposal and configuration data MUST be payload. A stack proposal and configuration data MUST be included if
included if the message exchange relates to setup of a messaging the message exchange relates to setup of a messaging association.
association. The R flag MUST always be set (R=1) in a Query, since The R flag MUST always be set (R=1) in a Query, since this message
this message always elicits a Response. always elicits a Response.
Query = Common-Header Query = Common-Header
[ NAT-Traversal-Object ] [ NAT-Traversal-Object ]
Message-Routing-Information Message-Routing-Information
Session-Identification Session-Identification
Network-Layer-Information Network-Layer-Information
Query-Cookie Query-Cookie
[ Stack-Proposal Stack-Configuration-Data ] [ Stack-Proposal Stack-Configuration-Data ]
[ NSLP-Data ] [ NSLP-Data ]
Response: A Response MAY be sent in D-mode, or MAY be sent in C-mode Response: A Response MAY be sent in D-mode, or MAY be sent in C-mode
skipping to change at page 46, line 26 skipping to change at page 48, line 26
Session-Identification Session-Identification
Network-Layer-Information Network-Layer-Information
Query-Cookie Query-Cookie
[ Responder-Cookie [ Responder-Cookie
[ Stack-Proposal Stack-Configuration-Data ] ] [ Stack-Proposal Stack-Configuration-Data ] ]
[ NSLP-Data ] [ NSLP-Data ]
Confirm: A Confirm MUST be sent in C-mode if a messaging association 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 is being used for this routing state, and MUST be sent before other
messages for this routing state. If no messaging association is messages for this routing state. If no messaging association is
being use, the Confirm MUST be sent in D-mode. The Confirm MUST echo being used, the Confirm MUST be sent in D-mode. The Confirm MUST
the MRI (with inverted direction), SID, and Responder-Cookie if the echo the MRI (with inverted direction), SID, and Responder-Cookie if
Response carried one. In C-mode, the Confirm MUST also echo the the Response carried one. In C-mode, the Confirm MUST also echo the
Stack-Proposal from the Response so it can be verified that this has Stack-Proposal from the Response so it can be verified that this has
not been tampered with. The first Confirm on a new association MUST not been tampered with. The first Confirm on a new association MUST
also repeat the Stack-Configuration-Data from the original Query in also repeat the Stack-Configuration-Data from the original Query in
an abbreviated form, just containing the MA-Hold-Time. an abbreviated form, just containing the MA-Hold-Time.
Confirm = Common-Header Confirm = Common-Header
Message-Routing-Information Message-Routing-Information
Session-Identification Session-Identification
Network-Layer-Information Network-Layer-Information
[ Responder-Cookie [ Responder-Cookie
[ Stack-Proposal [ Stack-Proposal
skipping to change at page 48, line 32 skipping to change at page 50, line 32
signalling source address. signalling source address.
Response requested: A flag which if set (R=1) indicates that a GIST 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 should be sent in reply to this message. The appropriate
message type for the reply depends on the type of the initial message type for the reply depends on the type of the initial
message. message.
Explicit routing: A flag which if set (E=1) indicates that the Explicit routing: A flag which if set (E=1) indicates that the
message was explicitly routed (see Section 7.1.5). message was explicitly routed (see Section 7.1.5).
Note that in Q-mode Section 5.3.2, there is a 32-bit magic number Note that in D-mode Section 5.3, there is a 32-bit magic number
before the header. However, this is regarded as part of the before the header. However, this is regarded as part of the
encapsulation rather than part of the message itself. encapsulation rather than part of the message itself.
5.2.2. TLV Objects 5.2.2. TLV Objects
All data following the common header is encoded as a sequence of All data following the common header is encoded as a sequence of
type-length-value objects. Currently, each object can occur at most type-length-value objects. Currently, each object can occur at most
once; the set of required and permitted objects is determined by the once; the set of required and permitted objects is determined by the
message type and encapsulation (D-mode or C-mode). message type and encapsulation (D-mode or C-mode).
skipping to change at page 52, line 16 skipping to change at page 54, line 16
or the values of addresses or ports used for it. This allows new or the values of addresses or ports used for it. This allows new
options to be developed in the future to handle particular deployment options to be developed in the future to handle particular deployment
requirements without modifying the overall protocol specification. requirements without modifying the overall protocol specification.
5.3.1. Normal Encapsulation 5.3.1. Normal Encapsulation
Normal encapsulation MUST be used for all D-mode messages where the Normal encapsulation MUST be used for all D-mode messages where the
signalling peer is already known from previous signalling. This signalling peer is already known from previous signalling. This
includes Response and Confirm messages, and Data messages except if includes Response and Confirm messages, and Data messages except if
these are being sent without using local routing state. Normal these are being sent without using local routing state. Normal
encapsulation is simple: the complete set of GIST payloads is encapsulation is simple: the message is carried in a single UDP
concatenated together with the common header, and placed in the data datagram. UDP checksums MUST be enabled. The payload MUST always
field of a UDP datagram. UDP checksums MUST be enabled. The message begin with a 32 bit magic number with value 0x4e04 bda5 in network
is IP addressed directly to the adjacent peer as given by the routing byte order; this is followed by the GIST common header and the
state table. Where the message is a direct reply to a Query and no complete set of payloads. If the magic number is not present, the
routing state exists, the destination address is derived from the message MUST be rejected with a "Common Header Parse Error" message
input message using the same rules as in Section 4.4.1. The UDP port (Appendix A.4.4.1) with subcode 5 ("Missing Magic Number").
numbering MUST be compatible with that used on Query messages (see
below), that is, the same for messages in the same direction and with The message is IP addressed directly to the adjacent peer as given by
source and destination port numbers swapped for messages in the the routing state table. Where the message is a direct reply to a
opposite direction. Normally encapsulated messages MUST be sent with Query and no routing state exists, the destination address is derived
source addressing mode flag S=1 unless the message is a reply to a from the input message using the same rules as in Section 4.4.1. The
message which is known to have passed through a NAT, and the receiver UDP port numbering MUST be compatible with that used on Query
MUST check the IP source address with the interface-address given in messages (see below), that is, the same for messages in the same
the NLI as part of legacy NAT detection. Both these aspects of direction and with source and destination port numbers swapped for
message processing are discussed further in Section 7.2.1. messages in the opposite direction. Normally encapsulated messages
MUST be sent with source addressing mode flag S=1 unless the message
is a reply to a message which is known to have passed through a NAT,
and the receiver MUST check the IP source address with the interface-
address given in the NLI as part of legacy NAT detection. Both these
aspects of message processing are discussed further in Section 7.2.1.
5.3.2. Q-mode Encapsulation 5.3.2. Q-mode Encapsulation
Q-mode encapsulation MUST be used for messages where no routing state Q-mode encapsulation MUST be used for messages where no routing state
is available or where the routing state is being refreshed, in is available or where the routing state is being refreshed, in
particular for Query messages. Q-mode encapsulation is similar to particular for Query messages. Q-mode encapsulation is similar to
normal encapsulation, with changes in IP address selection, IP normal encapsulation, with changes in IP address selection, IP
options, a defined method for selecting UDP ports, and a magic number options, and a defined method for selecting UDP ports.
at the start of the UDP payload.
5.3.2.1. Encapsulation and Interception in IPv4 5.3.2.1. Encapsulation and Interception in IPv4
In general, the IP addresses are derived from information in the MRI; 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 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 addressing mode flag S=1, the receiver MUST check the IP
source address with the interface-address given in the NLI as part of source address with the interface-address given in the NLI as part of
legacy NAT detection, see Section 7.2.1. legacy NAT detection, see Section 7.2.1.
Current MRMs define the use of a Router Alert Option [3] to assist Current MRMs define the use of a Router Alert Option [3] to assist
skipping to change at page 54, line 40 skipping to change at page 56, line 40
these packets from genuine end-to-end data purely on address these packets from genuine end-to-end data purely on address
analysis. Instead, it must be possible to distinguish such GIST analysis. Instead, it must be possible to distinguish such GIST
packets by port analysis; furthermore, the mechanism to do so must packets by port analysis; furthermore, the mechanism to do so must
remain valid even if the destination is GIST-unaware. GIST solves remain valid even if the destination is GIST-unaware. GIST solves
this problem by using a fixed destination UDP port from the "well this problem by using a fixed destination UDP port from the "well
known" space for the Q-mode encapsulation. This port should never be known" space for the Q-mode encapsulation. This port should never be
allocated on a GIST-unaware host, and therefore Q-mode encapsulated allocated on a GIST-unaware host, and therefore Q-mode encapsulated
messages should always be rejected with an ICMP error. messages should always be rejected with an ICMP error.
Within the network, there may be packets using the GIST UDP port but Within the network, there may be packets using the GIST UDP port but
which are not in fact GIST traffic. To avoid misidentification of which are not in fact GIST traffic. Q-mode packets carry the same
such packets, the UDP payload in Q-mode messages MUST always begin magic number as other D-mode packets (see Section 5.3.1). A Q-mode
with a 32 bit magic number which is followed immediately by the packets intercepted within the networ which does not match both the
normal GIST common header; the value of the magic number is 0x4e04 UDP destination port and the magic number MUST be forwarded
bda5 in network byte order. transparently at the IP layer, regardless of any RAO value they
contain. Regardless of the IP level encapsulation, if either the
Packets which do not match both the UDP destination port and the destination port is not the GIST port, or the payload start does not
magic number MUST be forwarded transparently at the IP layer, match the magic number, the packet MUST NOT be identified as a GIST
regardless of any RAO value they contain. Regardless of the IP level Q-mode packet and MUST be processed as a normal IP datagram. If a
encapsulation, if either the destination port is not the GIST port, Q-mode packet is received at an end system (i.e. the at the
or the payload start does not match the magic number, the packet MUST destination address of the IP datagram), if it does not start with
NOT be identified as a GIST Q-mode packet and MUST be processed as a the correct magic number it MUST be rejected as in the D-mode case.
normal IP datagram.
5.3.2.4. IP Option Processing 5.3.2.4. IP Option Processing
For both IPv4 and IPv6, for Q-mode packets with IP options allowed by For both IPv4 and IPv6, for Q-mode packets with IP options allowed by
the above requirements, IP options processing is intended to be the above requirements, IP options processing is intended to be
carried out independently of GIST processing. Note that for the carried out independently of GIST processing. Note that for the
options allowed by the above rules, the options semantics are options allowed by the above rules, the options semantics are
independent of the payload: UDP payload modifications are not independent of the payload: UDP payload modifications are not
prevented by the options and do not affect the options content, and prevented by the options and do not affect the options content, and
conversely the presence of the options does not affect the UDP conversely the presence of the options does not affect the UDP
skipping to change at page 55, line 40 skipping to change at page 57, line 40
signalling traffic. However, some form of messaging reliability is signalling traffic. However, some form of messaging reliability is
required for the GIST control messages themselves, as is rate control required for the GIST control messages themselves, as is rate control
to handle retransmissions and also bursts of unreliable signalling or to handle retransmissions and also bursts of unreliable signalling or
state setup requests from the signalling applications. state setup requests from the signalling applications.
Query messages which do not receive Responses MAY be retransmitted; Query messages which do not receive Responses MAY be retransmitted;
retransmissions MUST use a binary exponential backoff. The initial retransmissions MUST use a binary exponential backoff. The initial
timer value is T1, which the backoff process can increase up to a 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 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 is an estimate of the round-trip time between the querying and
responding nodes. Elements MAY use smaller values of T1 if it is responding nodes. Nodes MAY use smaller values of T1 if it is known
known that the Query should be answered within the local network. T1 that the Query should be answered within the local network. T1 MAY
MAY be chosen larger, and this is RECOMMENDED if it is known in be chosen larger, and this is RECOMMENDED if it is known in advance
advance (such as on high latency access links) that the round-trip (such as on high latency access links) that the round-trip time is
time is larger. The default value of T2 is 64*T1. Note that Queries larger. The default value of T2 is 64*T1. Note that Queries may go
may go unanswered either because of message loss (in either unanswered either because of message loss (in either direction), or
direction), or because there is no reachable GIST peer. Therefore, because there is no reachable GIST peer. Therefore, implementations
implementations MAY trade off reliability (large T2) against MAY trade off reliability (large T2) against promptness of error
promptness of error feedback to applications (small T2). If the NSLP feedback to applications (small T2). If the NSLP has indicated a
has indicated a timeout on the validity of this payload (see timeout on the validity of this payload (see Appendix B.1), T2 MUST
Appendix B.1), T2 MUST be chosen so that the process terminates be chosen so that the process terminates within this timeout.
within this timeout. Retransmitted Queries MUST use different Query- Retransmitted Queries MUST use different Query-Cookie values. If the
Cookie values. If the Query carries NSLP data, it may be delivered Query carries NSLP data, it may be delivered multiple times to the
multiple times to the signalling application. These rules apply signalling application. These rules apply equally to the message
equally to the message that first creates routing state, and those that first creates routing state, and those that refresh it. In all
that refresh it. In all cases, Responses MUST be sent promptly to cases, Responses MUST be sent promptly to avoid spurious
avoid spurious retransmissions. Nodes generating any type of retransmissions. Nodes generating any type of retransmission MUST be
retransmission MUST be prepared to receive and match a reply to any prepared to receive and match a reply to any of them, not just the
of them, not just the one most recently sent. one most recently sent. Although a node SHOULD terminate its
retransmission process when any reply is received, it MUST continue
to process further replies as normal.
This algorithm is sufficient to handle lost Queries and Responses. This algorithm is sufficient to handle lost Queries and Responses.
The case of a lost Confirm is more subtle. The Responding node MAY 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 run a retransmission timer to resend the Response until a Confirm is
received. The problem of an amplification attack stimulated by a received. The problem of an amplification attack stimulated by a
malicious Query is handled by requiring the cookie mechanism to malicious Query is handled by requiring the cookie mechanism to
enable the node receiving the Response to discard it efficiently if enable the node receiving the Response to discard it efficiently if
it does not match a previously sent Query. This approach is only it does not match a previously sent Query. This approach is only
appropriate if the Responding node is prepared to store per-flow appropriate if the Responding node is prepared to store per-flow
state after receiving a single (Query) message, which includes the state after receiving a single (Query) message, which includes the
skipping to change at page 56, line 33 skipping to change at page 58, line 35
error (see Section 4.4.6) which causes the Querying node to restart error (see Section 4.4.6) which causes the Querying node to restart
the handshake. the handshake.
The basic rate-control requirements for D-mode traffic are The basic rate-control requirements for D-mode traffic are
deliberately minimal. A single rate limiter applies to all traffic, deliberately minimal. A single rate limiter applies to all traffic,
for all interfaces and message types. It applies to retransmissions for all interfaces and message types. It applies to retransmissions
as well as new messages, although an implementation MAY choose to as well as new messages, although an implementation MAY choose to
prioritise one over the other. Rate-control applies only to locally prioritise one over the other. Rate-control applies only to locally
generated D-mode messages, not to messages which are being forwarded. generated D-mode messages, not to messages which are being forwarded.
When the rate limiter is in effect, D-mode messages MUST be queued When the rate limiter is in effect, D-mode messages MUST be queued
until transmission is re-enabled, or an error condition MAY be until transmission is re-enabled, or they MAY be dropped with an
indicated back to local signalling applications. The rate limiting error condition indicated back to local signalling applications. In
mechanism is implementation-defined, but it is RECOMMENDED that a either case, the effect of this will be to reduce the rate at which
token bucket limiter as described in [35] be used. The token bucket new transactions can be initiated by signalling applications, thereby
MUST be sized to ensure that a node cannot saturate the network with reducing the load on the network.
D-mode traffic, for example when re-probing the network for multiple
flows after a route change. A suitable approach is to restrict the The rate limiting mechanism is implementation-defined, but it is
token bucket parameters so that the mean output rate is a small RECOMMENDED that a token bucket limiter as described in [34] be used.
fraction, such as 5%, of the node's lowest-speed interface. 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 Section 4.3.3, in
general D-mode SHOULD only be used for Queries and Responses rather
than normal signalling traffic.
5.4. C-mode Transport 5.4. C-mode Transport
It is a requirement of the NTLP defined in [31] that it should be It is a requirement of the NTLP defined in [30] that it should be
able to support bundling of small messages, fragmentation of large able to support bundling of small messages, fragmentation of large
messages, and message boundary delineation. TCP provides both messages, and message boundary delineation. TCP provides both
bundling and fragmentation, but not message boundaries. However, the bundling and fragmentation, but not message boundaries. However, the
length information in the GIST common header allows the message length information in the GIST common header allows the message
boundary to be discovered during parsing. The bundling together of boundary to be discovered during parsing. The bundling together of
small messages can either be done within the transport protocol or small messages can either be done within the transport protocol or
can be carried out by GIST during message construction. Either way, can be carried out by GIST during message construction. Either way,
two approaches can be distinguished: two approaches can be distinguished:
1. As messages arrive for transmission they are gathered into a 1. As messages arrive for transmission they are gathered into a
skipping to change at page 61, line 13 skipping to change at page 63, line 22
The Response always contains a Stack-Proposal and Stack- The Response always contains a Stack-Proposal and Stack-
Configuration-Data object, unless multiplexing (where the Responder Configuration-Data object, unless multiplexing (where the Responder
decides to use an existing association) occurs. For such a Response, decides to use an existing association) occurs. For such a Response,
the security protocols listed in the Stack-Proposal MUST NOT depend the security protocols listed in the Stack-Proposal MUST NOT depend
on the Query. A node MAY make different proposals depending on the on the Query. A node MAY make different proposals depending on the
combination of interface and NSLPID. If multiplexing does occur, combination of interface and NSLPID. If multiplexing does occur,
which is indicated by sending the Response over an existing messaging which is indicated by sending the Response over an existing messaging
association, the following rules apply: association, the following rules apply:
o The re-used messaging association MUST NOT have weaker security o The re-used messaging association MUST NOT have weaker security
properties than would have been offered in the full Response that properties than all of the options that would have been offered in
would have been sent without re-use. the full Response that would have been sent without re-use.
o The re-used messaging association MUST have equivalent or better o The re-used messaging association MUST have equivalent or better
transport and security characteristics as at least one of the transport and security characteristics as at least one of the
protocol configurations that was offered in the Query. protocol configurations that was offered in the Query.
Once the messaging association is set up, the Querying node repeats Once the messaging association is set up, the Querying node repeats
the responder's Stack-Proposal over it in the Confirm. The the responder's Stack-Proposal over it in the Confirm. The
responding node MUST verify that this has not been changed as part of responding node MUST verify that this has not been changed as part of
bidding-down attack prevention. If a difference is detected, the bidding-down attack prevention. If a difference is detected, the
responding node MUST terminate the messaging association and SHOULD responding node MUST terminate the messaging association and SHOULD
skipping to change at page 62, line 13 skipping to change at page 64, line 21
Section 4.1.2. Section 4.1.2.
5.7.3. Protocol Definition: Transport Layer Security 5.7.3. Protocol Definition: Transport Layer Security
This MA-Protocol-ID denotes a basic use of transport layer channel This MA-Protocol-ID denotes a basic use of transport layer channel
security, initially in conjunction with TCP. Support for this security, initially in conjunction with TCP. Support for this
protocol in conjunction with TCP is REQUIRED; associations using it protocol in conjunction with TCP is REQUIRED; associations using it
can carry messages with transfer attributes requesting can carry messages with transfer attributes requesting
confidentiality or integrity protection. The specific TLS version confidentiality or integrity protection. The specific TLS version
will be negotiated within the TLS layer itself, but implementations will be negotiated within the TLS layer itself, but implementations
MUST NOT negotiate to protocol versions prior to TLS1.0 [10] and MUST MUST NOT negotiate to protocol versions prior to TLS1.0 [16] and MUST
use the highest protocol version supported by both peers. use the highest protocol version supported by both peers.
Implementation of TLS1.1 [14] is RECOMMENDED. GIST nodes supporting Implementation of TLS1.1 [13] is RECOMMENDED. GIST nodes supporting
TLS1.0 or TLS1.1 MUST- be able to negotiate the TLS ciphersuite 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_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 TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. They MAY negotiate any
mutually acceptable ciphersuite that provides authentication, mutually acceptable ciphersuite that provides authentication,
integrity, and confidentiality. integrity, and confidentiality.
The default mode of TLS authentication, which applies in particular The default mode of TLS authentication, which applies in particular
to the above ciphersuites, uses a client/server X.509 certificate to the above ciphersuites, uses a client/server X.509 certificate
exchange. The Querying node acts as a TLS client, and the Responding 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 node acts as a TLS server. Where one of the above ciphersuites is
negotiated, the GIST node acting as a server MUST provide a negotiated, the GIST node acting as a server MUST provide a
certificate, and MUST request one from the GIST node acting as a TLS certificate, and MUST request one from the GIST node acting as a TLS
client. This allows either server-only or mutual authentication, client. This allows either server-only or mutual authentication,
depending on the certificates available to the client and the policy depending on the certificates available to the client and the policy
applied at the server. applied at the server.
GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the
negotiation of alternative ciphersuites is used to trigger negotiation of alternative ciphersuites is used to trigger
alternative authentication procedures, such as the use of pre-shared alternative authentication procedures, such as the use of pre-shared
keys [34]. The use of other authentication procedures may require keys [33]. The use of other authentication procedures may require
additional specification work to define how they can be used as part 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 of TLS within the GIST framework, and may or may not require the
definition of additional MA-Protocol-IDs. definition of additional MA-Protocol-IDs.
No MA-protocol-options field is required for this TLS protocol No MA-protocol-options field is required for this TLS protocol
definition. The configuration information for the transport protocol definition. The configuration information for the transport protocol
over which TLS is running (e.g. TCP port number) is provided by the over which TLS is running (e.g. TCP port number) is provided by the
MA-protocol-options for that protocol. MA-protocol-options for that protocol.
5.7.3.1. Identity Checking in TLS 5.7.3.1. Identity Checking in TLS
skipping to change at page 63, line 22 skipping to change at page 65, line 31
insensitive. Also, a "*" wildcard character MAY be used as the left- insensitive. Also, a "*" wildcard character MAY be used as the left-
most name component in the certificate or identity in the APD. For most name component in the certificate or identity in the APD. For
example, *.example.com in the APD would match certificates for example, *.example.com in the APD would match certificates for
a.example.com, foo.example.com, *.example.com, etc., but would not a.example.com, foo.example.com, *.example.com, etc., but would not
match example.com. Similarly, a certificate for *.example.com would match example.com. Similarly, a certificate for *.example.com would
be valid for APD identities of a.example.com, foo.example.com, be valid for APD identities of a.example.com, foo.example.com,
*.example.com, etc., but not example.com. *.example.com, etc., but not example.com.
Additionally, a node MUST verify the binding between the identity of Additionally, a node MUST verify the binding between the identity of
the peer to which it connects and the public key presented by that the peer to which it connects and the public key presented by that
peer. Nodes SHOULD implement the algorithm in Section 6 of [11] for peer. Nodes SHOULD implement the algorithm in Section 6 of [10] for
general certificate validation, but MAY supplement that algorithm general certificate validation, but MAY supplement that algorithm
with other validation methods that achieve equivalent levels of with other validation methods that achieve equivalent levels of
verification (such as comparing the server certificate against a verification (such as comparing the server certificate against a
local store of already-verified certificates and identity bindings). local store of already-verified certificates and identity bindings).
For TLS authentication with pre-shared keys, the identity in the For TLS authentication with pre-shared keys, the identity in the
psk_identity_hint (for the server identity, i.e. the Responding node) psk_identity_hint (for the server identity, i.e. the Responding node)
or psk_identity (for the client identity, i.e. the Querying node) or psk_identity (for the client identity, i.e. the Querying node)
MUST be compared to the identities in the APD. MUST be compared to the identities in the APD.
5.8. Specific Message Routing Methods 5.8. Specific Message Routing Methods
Each message routing method (see Section 3.3) requires the definition Each message routing method (see Section 3.3) requires the definition
of the format of the message routing information (MRI) and Q-mode of the format of the message routing information (MRI) and Q-mode
encapsulation rules. These are given in the following subsections encapsulation rules. These are given in the following subsections
for the various possible MRMs. 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
bere, in order to minimise deployment barriers for new signalling
applications that need them.
5.8.1. The Path-Coupled MRM 5.8.1. The Path-Coupled MRM
5.8.1.1. Message Routing Information 5.8.1.1. Message Routing Information
For the path-coupled MRM, this is conceptually the Flow Identifier as For the path-coupled MRM, this is conceptually the Flow Identifier as
in the NSIS Framework [31]. Minimally, this could just be the flow in the NSIS Framework [30]. Minimally, this could just be the flow
destination address; however, to account for policy based forwarding destination address; however, to account for policy based forwarding
and other issues a more complete set of header fields SHOULD be and other issues a more complete set of header fields SHOULD be
specified if possible (see Section 4.3.4 and Section 7.2 for further specified if possible (see Section 4.3.4 and Section 7.2 for further
discussion). discussion).
MRI = network-layer-version MRI = network-layer-version
source-address prefix-length source-address prefix-length
destination-address prefix-length destination-address prefix-length
IP-protocol IP-protocol
diffserv-codepoint diffserv-codepoint
skipping to change at page 67, line 13 skipping to change at page 69, line 26
The sending GIST implementation SHOULD attempt to send the Query via The sending GIST implementation SHOULD attempt to send the Query via
the same interface and to the same link layer neighbour from which the same interface and to the same link layer neighbour from which
the data packets of the flow are arriving. the data packets of the flow are arriving.
The receiving GIST node MAY apply validation checks to the message The receiving GIST node MAY apply validation checks to the message
and MRI, to reject Query messages which have reached a node at which 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 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 message which has been propagated more than one IP hop, with an
"Invalid IP layer TTL" error message (Appendix A.4.4.11). This can "Invalid IP layer TTL" error message (Appendix A.4.4.11). This can
be determined by examining the received IP layer TTL, similar to the be determined by examining the received IP layer TTL, similar to the
generalised IP TTL security mechanism described in [29]. generalised IP TTL security mechanism described in [28].
Alternatively, receipt of an upstream Query at the flow source MAY be Alternatively, receipt of an upstream Query at the flow source MAY be
used to trigger setup of GIST state in the downstream direction. used to trigger setup of GIST state in the downstream direction.
These restrictions may be relaxed in a future version. These restrictions may be relaxed in a future version.
5.8.2. The Loose-End MRM 5.8.2. The Loose-End MRM
The Loose-End MRM is used to discover GIST nodes with particular The Loose-End MRM is used to discover GIST nodes with particular
properties in the direction of a given address, for example to properties in the direction of a given address, for example to
discover a NAT along the upstream data path as in [36]. discover a NAT along the upstream data path as in [35].
5.8.2.1. Message Routing Information 5.8.2.1. Message Routing Information
For the loose-end MRM, only a simplified version of the Flow For the loose-end MRM, only a simplified version of the Flow
Identifier is needed. Identifier is needed.
MRI = network-layer-version MRI = network-layer-version
source-address source-address
destination-address destination-address
skipping to change at page 69, line 14 skipping to change at page 71, line 14
6. Formal Protocol Specification 6. Formal Protocol Specification
This section provides a more formal specification of the operation of This section provides a more formal specification of the operation of
GIST processing, in terms of rules for transitions between states of GIST processing, in terms of rules for transitions between states of
a set of communicating state machines within a node. The following a set of communicating state machines within a node. The following
description captures only the basic protocol specification; description captures only the basic protocol specification;
additional mechanisms can be used by an implementation to accelerate additional mechanisms can be used by an implementation to accelerate
route change processing, and these are captured in Section 7.1. A route change processing, and these are captured in Section 7.1. A
more detailed description of the GIST protocol operation in state more detailed description of the GIST protocol operation in state
machine syntax can be found in [44]. machine syntax can be found in [43].
Conceptually, GIST processing at a node may be seen in terms of four Conceptually, GIST processing at a node may be seen in terms of four
types of cooperating state machine: types of cooperating state machine:
1. There is a top-level state machine which represents the node 1. There is a top-level state machine which represents the node
itself (Node-SM). It is responsible for the processing of events itself (Node-SM). It is responsible for the processing of events
which cannot be directed towards a more specific state machine, which cannot be directed towards a more specific state machine,
for example, inbound messages for which no routing state for example, inbound messages for which no routing state
currently exists. This machine exists permanently, and is currently exists. This machine exists permanently, and is
responsible for creating per-MRI state machines to manage the responsible for creating per-MRI state machines to manage the
skipping to change at page 83, line 12 skipping to change at page 85, line 12
Figure 8: A Re-Routing Event Figure 8: A Re-Routing Event
Route change management is complicated by the distributed nature of Route change management is complicated by the distributed nature of
the problem. Consider the re-routing event shown in Figure 8. An the problem. Consider the re-routing event shown in Figure 8. An
external observer can tell that the main responsibility for external observer can tell that the main responsibility for
controlling the updates will probably lie with nodes B and F; controlling the updates will probably lie with nodes B and F;
however, E1 is best placed to detect the event quickly at the GIST 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. level, and C1 and D1 could also attempt to initiate the repair.
The NSIS framework [31] makes the assumption that signalling The NSIS framework [30] makes the assumption that signalling
applications are soft-state based and operate end to end. In this applications are soft-state based and operate end to end. In this
case, because GIST also periodically updates its picture of routing case, because GIST also periodically updates its picture of routing
state, route changes will eventually be repaired automatically. The state, route changes will eventually be repaired automatically. The
specification as already given includes this functionality. However, specification as already given includes this functionality. However,
especially if upper layer refresh times are extended to reduce especially if upper layer refresh times are extended to reduce
signalling load, the duration of inconsistent state may be very long signalling load, the duration of inconsistent state may be very long
indeed. Therefore, GIST includes logic to exchange prompt indeed. Therefore, GIST includes logic to exchange prompt
notifications with signalling applications, to allow local repair if notifications with signalling applications, to allow local repair if
possible. The additional mechanisms to achieve this are described in possible. The additional mechanisms to achieve this are described in
the following subsections. To a large extent, these additions can be the following subsections. To a large extent, these additions can be
skipping to change at page 87, line 17 skipping to change at page 89, line 17
7.1.4. Load Splitting and Route Flapping 7.1.4. Load Splitting and Route Flapping
The Q-mode encapsulation rules of Section 5.8 try to ensure that the The Q-mode encapsulation rules of Section 5.8 try to ensure that the
Query messages discovering the path mimic the flow as accurately as Query messages discovering the path mimic the flow as accurately as
possible. However, in environments where there is load balancing possible. However, in environments where there is load balancing
over multiple routes, and this is based on header fields differing 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 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 path discovered by the Query may vary from one handshake to the next
even though the underlying network is stable. This will appear to even though the underlying network is stable. This will appear to
GIST as a route flap; route flapping can also be caused by problems GIST as a route flap; route flapping can also be caused by problems
in the basic network connectivity or routing protocol operation. 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.
This specification does not define mechanisms for GIST to manage This specification does not define mechanisms for GIST to manage
multiple parallel routes or an unstable route. The algorithms multiple parallel routes or an unstable route; instead, GIST MAY
already described always maintain the concept of the current route, expose this to the NSLP, which can then manage it according to
i.e. the latest peer discovered for a particular flow. Instead, GIST signalling application requirements. The algorithms already
allows the use of prior signalling paths for some period while the 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 signalling applications still need them. Since NSLP peers are a
single GIST hop apart, the necessary information to represent a path 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 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 (more generally, anything that uniquely identifies the peer, such as
the NLI, could be used). Rather than requiring GIST to maintain the NLI, could be used). Rather than requiring GIST to maintain
multiple generations of this information, it is provided to the multiple generations of this information, it is provided to the
signalling application in the same node in an opaque form for each signalling application in the same node in an opaque form for each
message that is received from the peer. The signalling application message that is received from the peer. The signalling application
can store it if necessary and provide it back to the GIST layer in 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 case it needs to be used. Because this is a reference to information
skipping to change at page 90, line 26 skipping to change at page 92, line 31
could traverse such NATs safely, with some modifications to the GIST could traverse such NATs safely, with some modifications to the GIST
processing rules. Such modifications could be described in the processing rules. Such modifications could be described in the
documents defining such MRMs.) Legacy NAT handling is covered in documents defining such MRMs.) Legacy NAT handling is covered in
Section 7.2.1 below. A more general solution can be constructed Section 7.2.1 below. A more general solution can be constructed
using GIST-awareness in the NATs themselves; this solution is using GIST-awareness in the NATs themselves; this solution is
outlined in Section 7.2.2 with processing rules in Section 7.2.3. outlined in Section 7.2.2 with processing rules in Section 7.2.3.
In all cases, GIST interaction with the NAT is determined by the way In all cases, GIST interaction with the NAT is determined by the way
the NAT handles the Query/Response messages in the initial GIST the NAT handles the Query/Response messages in the initial GIST
handshake; these messages are UDP datagrams. Best current practice handshake; these messages are UDP datagrams. Best current practice
for NAT treatment of UDP traffic is defined in [28], and the legacy for NAT treatment of UDP traffic is defined in [39], and the legacy
NAT handling defined in this specification is fully consistent with NAT handling defined in this specification is fully consistent with
that document. The GIST-aware NAT traversal technique is equivalent that document. The GIST-aware NAT traversal technique is equivalent
to requiring an Application Layer Gateway in the NAT for a specific to requiring an Application Layer Gateway in the NAT for a specific
class of UDP transactions, namely those where the destination UDP class of UDP transactions, namely those where the destination UDP
port for the initial message is the GIST port (see Section 9). port for the initial message is the GIST port (see Section 9).
7.2.1. Legacy NAT Handling 7.2.1. Legacy NAT Handling
Legacy NAT detection during the GIST handshake depends on analysis of 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 the IP header and S flag in the GIST common header, and the NLI
skipping to change at page 91, line 37 skipping to change at page 93, line 42
MUST send a normal Response with S=1 to an address derived from the 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 Querying node's NLI which will traverse the NAT as normal UDP
traffic. The Querying node MUST check the source address in the IP 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 header with the NLI in the Response, and when it finds a mismatch it
MUST terminate the handshake. MUST terminate the handshake.
Note that in either of the error cases (internal or external Querying Note that in either of the error cases (internal or external Querying
node), an alternative to terminating the handshake could be to invoke node), an alternative to terminating the handshake could be to invoke
some legacy NAT traversal procedure. This specification does not some legacy NAT traversal procedure. This specification does not
define any such procedure, although one possible approach is define any such procedure, although one possible approach is
described in [42]. Any such traversal procedure MUST be incorporated described in [41]. Any such traversal procedure MUST be incorporated
into GIST using the existing GIST extensibility capabilities. into GIST using the existing GIST extensibility capabilities.
7.2.2. GIST-aware NAT Traversal 7.2.2. GIST-aware NAT Traversal
The most robust solution to the NAT traversal problem is to require 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 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 the contents of the MRI. This makes the assumption that NATs only
rewrite the header fields included in this payload, and not other rewrite the header fields included in this payload, and not other
higher layer identifiers. Provided this is done consistently with higher layer identifiers. Provided this is done consistently with
the data flow header translation, signalling messages will be valid the data flow header translation, signalling messages will be valid
skipping to change at page 92, line 44 skipping to change at page 94, line 49
7.2.3. Message Processing Rules 7.2.3. Message Processing Rules
This specification normatively defines the behaviour of a GIST node This specification normatively defines the behaviour of a GIST node
receiving a message containing a NAT-Traversal object. However, it receiving a message containing a NAT-Traversal object. However, it
does not define normative behaviour for a NAT translating GIST does not define normative behaviour for a NAT translating GIST
messages, since much of this will depend on NAT implementation and messages, since much of this will depend on NAT implementation and
policy about allocating bindings. In addition, it is not necessary policy about allocating bindings. In addition, it is not necessary
for a GIST implementation itself. Therefore, those aspects of the for a GIST implementation itself. Therefore, those aspects of the
following description are informative; full details of NAT behaviour following description are informative; full details of NAT behaviour
for handling GIST messages can be found in [43]. for handling GIST messages can be found in [42].
A possible set of operations for a NAT to process a Q-mode A possible set of operations for a NAT to process a Q-mode
encapsulated message is as follows. Note that for a Data message, encapsulated message is as follows. Note that for a Data message,
only a subset of the operations is applicable. only a subset of the operations is applicable.
1. Verify that bindings for any data flow are actually in place. 1. Verify that bindings for any data flow are actually in place.
2. Create a new Message-Routing-Information object with fields 2. Create a new Message-Routing-Information object with fields
modified according to the data flow bindings. modified according to the data flow bindings.
skipping to change at page 95, line 32 skipping to change at page 97, line 36
GIST itself is essentially IP version neutral: version dependencies GIST itself is essentially IP version neutral: version dependencies
are isolated in the formats of the Message-Routing-Information, are isolated in the formats of the Message-Routing-Information,
Network-Layer-Information and Stack-Configuration-Data objects, and Network-Layer-Information and Stack-Configuration-Data objects, and
GIST also depends on the version independence of the protocols that GIST also depends on the version independence of the protocols that
support messaging associations. In mixed environments, GIST support messaging associations. In mixed environments, GIST
operation will be influenced by the IP transition mechanisms in use. operation will be influenced by the IP transition mechanisms in use.
This section provides a high level overview of how GIST is affected, This section provides a high level overview of how GIST is affected,
considering only the currently predominant mechanisms. considering only the currently predominant mechanisms.
Dual Stack: (As described in [38].) In mixed environments, GIST Dual Stack: (As described in [36].) In mixed environments, GIST
MUST use the same IP version for Q-mode encapsulated messages as 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 given by the MRI of the flow it is signalling for, and SHOULD do
so for other signalling also (see Section 5.2.2). Messages with so for other signalling also (see Section 5.2.2). Messages with
mismatching versions MUST be rejected with a "MRI Validation mismatching versions MUST be rejected with a "MRI Validation
Failure" error message (Appendix A.4.4.12) with subcode 1 ("IP Failure" error message (Appendix A.4.4.12) with subcode 1 ("IP
Version Mismatch"). The IP version used in D-mode is closely tied 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 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 impossible for an IPv4-only or IPv6-only GIST node to support
signalling for flows using the other IP version. Hosts which are signalling for flows using the other IP version. Hosts which are
dual stack for applications and routers which are dual stack for dual stack for applications and routers which are dual stack for
skipping to change at page 97, line 9 skipping to change at page 99, line 9
D-mode messages if necessary, but MUST NOT use them in the D-mode messages if necessary, but MUST NOT use them in the
Network-Layer-Information addressing field; unicast addresses MUST Network-Layer-Information addressing field; unicast addresses MUST
be used instead. Note that the addresses from the IP header are 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 not used by GIST in matching requests and replies, so there is no
requirement to use anycast source addresses. requirement to use anycast source addresses.
8. Security Considerations 8. Security Considerations
The security requirement for GIST is to protect the signalling plane The security requirement for GIST is to protect the signalling plane
against identified security threats. For the signalling problem as a against identified security threats. For the signalling problem as a
whole, these threats have been outlined in [32]; the NSIS framework whole, these threats have been outlined in [31]; the NSIS framework
[31] assigns a subset of the responsibilities to the NTLP. The main [30] assigns a subset of the responsibilities to the NTLP. The main
issues to be handled can be summarised as: issues to be handled can be summarised as:
Message Protection: Signalling message content can be protected Message Protection: Signalling message content can be protected
against eavesdropping, modification, injection and replay while in against eavesdropping, modification, injection and replay while in
transit. This applies both to GIST payloads, and GIST should also transit. This applies both to GIST payloads, and GIST should also
provide such protection as a service to signalling applications provide such protection as a service to signalling applications
between adjacent peers. between adjacent peers.
Routing State Integrity Protection: It is important that signalling Routing State Integrity Protection: It is important that signalling
messages are delivered to the correct nodes, and nowhere else. messages are delivered to the correct nodes, and nowhere else.
skipping to change at page 99, line 16 skipping to change at page 101, line 16
routed identically to the data flow described by the MRI, and the 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 routing state table is the GIST view of how these flows are being
routed through the network in the immediate neighbourhood of the routed through the network in the immediate neighbourhood of the
node. Routes are only weakly secured (e.g. there is no cryptographic node. Routes are only weakly secured (e.g. there is no cryptographic
binding of a flow to a route), and there is no authoritative binding of a flow to a route), and there is no authoritative
information about flow routes other than the current state of the information about flow routes other than the current state of the
network itself. Therefore, consistency between GIST and network network itself. Therefore, consistency between GIST and network
routing state has to be ensured by directly interacting with the IP routing state has to be ensured by directly interacting with the IP
routing mechanisms to ensure that the signalling peers are the routing mechanisms to ensure that the signalling peers are the
appropriate ones for any given flow. An overview of security issues appropriate ones for any given flow. An overview of security issues
and techniques in this context is provided in [40]. and techniques in this context is provided in [38].
In one direction, peer identification is installed and refreshed only In one direction, peer identification is installed and refreshed only
on receiving a Response (compare Figure 4). This MUST echo the on receiving a Response (compare Figure 4). This MUST echo the
cookie from a previous Query, which will have been sent along 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. 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 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 generate such a message, provided freshness of the cookie can be
checked at the querying node. checked at the querying node.
In the other direction, peer identification MAY be installed directly In the other direction, peer identification MAY be installed directly
skipping to change at page 103, line 5 skipping to change at page 105, line 5
installed. To prevent use with different routing state e.g. in a installed. To prevent use with different routing state e.g. in a
modified Confirm. The routing state here includes the NLI of the modified Confirm. The routing state here includes the NLI of the
Query, the MRI/NSLPID for the messaging, and the interface on Query, the MRI/NSLPID for the messaging, and the interface on
which the Query was received. which the Query was received.
A suitable implementation for the Q-Cookie is a cryptographically A suitable implementation for the Q-Cookie is a cryptographically
strong random number which is unique for this routing state machine strong random number which is unique for this routing state machine
handshake. A node MUST implement this or an equivalently strong handshake. A node MUST implement this or an equivalently strong
mechanism. Guidance on random number generation can be found in mechanism. Guidance on random number generation can be found in
[33]. [32].
A suitable implementation for the R-Cookie is as follows: A suitable implementation for the R-Cookie is as follows:
R-Cookie = liveness data + hash (locally known secret, R-Cookie = liveness data + hash (locally known secret,
Q-Node NLI, MRI, NSLPID, Q-Node NLI, MRI, NSLPID,
reception interface, reception interface,
liveness data) liveness data)
A node MUST implement this or an equivalently strong mechanism. A node MUST implement this or an equivalently strong mechanism.
There are several alternatives for the liveness data. One is to use There are several alternatives for the liveness data. One is to use
skipping to change at page 105, line 22 skipping to change at page 107, line 22
correctness of routing along the signalling chain. The NSLP at the correctness of routing along the signalling chain. The NSLP at the
querying node can have good assurance that it is communicating with 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 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 on the security protection provided by GIST. However, it has no
assurance that the node beyond the responder is also on-path, or that 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 the MRI (in particular) is not being modified by the responder to
refer to a different flow. Therefore, if it sends signalling refer to a different flow. Therefore, if it sends signalling
messages with payloads (e.g. authorisation tokens) which are valuable 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 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 the appropriate chain of trust exists. This could be achieved using
higher layer security protection such as CMS [30]. higher layer security protection such as CMS [29].
There is a further residual attack by a node which is not on the path 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 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 Response from one handshake to interfere with another. The attacker
modifies the Response to cause the Querying node to form an adjacency modifies the Response to cause the Querying node to form an adjacency
with it rather than the true peer. In principle, this attack could with it rather than the true peer. In principle, this attack could
be prevented by including an additional cryptographic object in the be prevented by including an additional cryptographic object in the
Response which ties the Response to the initial Query and the routing Response which ties the Response to the initial Query and the routing
state and can be verified by the Querying node. state and can be verified by the Querying node.
skipping to change at page 106, line 14 skipping to change at page 108, line 14
9. IANA Considerations 9. IANA Considerations
This section defines the registries and initial codepoint assignments This section defines the registries and initial codepoint assignments
for GIST. It also defines the procedural requirements to be followed for GIST. It also defines the procedural requirements to be followed
by IANA in allocating new codepoints. Note that the guidelines on by IANA in allocating new codepoints. Note that the guidelines on
the technical criteria to be followed in evaluating requests for new the technical criteria to be followed in evaluating requests for new
codepoint assignments are covered normatively in a separate document codepoint assignments are covered normatively in a separate document
which considers the NSIS protocol suite in a unified way. That which considers the NSIS protocol suite in a unified way. That
document discusses the general issue of NSIS extensibility, as well document discusses the general issue of NSIS extensibility, as well
as the technical criteria for particular registries; see [15] for as the technical criteria for particular registries; see [14] for
further details. further details.
The registry definitions that follow leave large blocks of codes The registry definitions that follow leave large blocks of codes
marked "Reserved - not to be allocated". This is to allow a future marked "Reserved - not to be allocated". This is to allow a future
revision of this specification or another Standards Track document to revision of this specification or another Standards Track document to
modify the relative space given to different allocation policies modify the relative space given to different allocation policies
without having to change the initial rules retrospectively if they without having to change the initial rules retrospectively if they
turn out to have been inappropriate, e.g. if the space for one turn out to have been inappropriate, e.g. if the space for one
particular policy is exhausted too quickly. particular policy is exhausted too quickly.
The allocation policies used in this section follow the guidance The allocation policies used in this section follow the guidance
given in [6]. In addition, for a number of the GIST registries, this given in [6]. In addition, for a number of the GIST registries, this
specification also defines private/experimental ranges as discussed specification also defines private/experimental ranges as discussed
in [12]. Note that the only environment in which these codepoints in [11]. Note that the only environment in which these codepoints
can validly be used is a closed one in which the experimenter knows can validly be used is a closed one in which the experimenter knows
all the experiments in progress. all the experiments in progress.
This specification allocates the following codepoints in existing This specification allocates the following codepoints in existing
registries: registries:
Well-known UDP port XXX as the destination port for Q-mode Well-known UDP port XXX as the destination port for Q-mode
encapsulated GIST messages (Section 5.3). encapsulated GIST messages (Section 5.3).
This specification creates the following registries with the This specification creates the following registries with the
skipping to change at page 110, line 31 skipping to change at page 112, line 31
integrate the functionality described in Section 3.9 with the rest integrate the functionality described in Section 3.9 with the rest
of GIST operation. If the new MA-Protocol-ID can be used in of GIST operation. If the new MA-Protocol-ID can be used in
conjunction with existing ones (for example, a new transport conjunction with existing ones (for example, a new transport
protocol option which could be used with Transport Layer protocol option which could be used with Transport Layer
Security), the specification MUST define the interaction between Security), the specification MUST define the interaction between
the two. the two.
Error Codes/Subcodes: There is a 2 byte error code and 1 byte Error Codes/Subcodes: There is a 2 byte error code and 1 byte
subcode in the Value field of the Error object (Appendix A.4.1). subcode in the Value field of the Error object (Appendix A.4.1).
Error codes 1-12 are defined in Appendix A.4.4 together with Error codes 1-12 are defined in Appendix A.4.4 together with
subcodes 0-4 (code 1), 0-5 (code 9), 0-5 (code 10), and 0-2 (code subcodes 0-5 (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, 12). Additional codes and subcodes are allocated on a first-come,
first-served basis. When a new code/subcode combination is first-served basis. When a new code/subcode combination is
allocated, the following information MUST be provided: allocated, the following information MUST be provided:
Error case: textual name of error Error case: textual name of error
Error class: from the categories given in Appendix A.4.3 Error class: from the categories given in Appendix A.4.3
Error code: allocated by IANA, if a new code is required Error code: allocated by IANA, if a new code is required
skipping to change at page 111, line 13 skipping to change at page 113, line 13
first-served basis. first-served basis.
10. Acknowledgements 10. Acknowledgements
This document is based on the discussions within the IETF NSIS This document is based on the discussions within the IETF NSIS
working group. It has been informed by prior work and formal and working group. It has been informed by prior work and formal and
informal inputs from: Cedric Aoun, Attila Bader, Roland Bless, Bob informal inputs from: Cedric Aoun, Attila Bader, Roland Bless, Bob
Braden, Marcus Brunner, Benoit Campedel, Yoshiko Chong, Luis Braden, Marcus Brunner, Benoit Campedel, Yoshiko Chong, Luis
Cordeiro, Elwyn Davies, Christian Dickmann, Pasi Eronen, Alan Ford, Cordeiro, Elwyn Davies, Christian Dickmann, Pasi Eronen, Alan Ford,
Xiaoming Fu, Bo Gao, Ruediger Geib, Eleanor Hepworth, Thomas Herzog, Xiaoming Fu, Bo Gao, Ruediger Geib, Eleanor Hepworth, Thomas Herzog,
Cheng Hong, Jia Jia, Cornelia Kappler, Georgios Karagiannis, Ruud Cheng Hong, Teemu Huovila, Jia Jia, Cornelia Kappler, Georgios
Klaver, Chris Lang, John Loughney, Allison Mankin, Jukka Manner, Pete Karagiannis, Ruud Klaver, Chris Lang, John Loughney, Allison Mankin,
McCann, Andrew McDonald, Glenn Morrow, Dave Oran, Andreas Pashalidis, Jukka Manner, Pete McCann, Andrew McDonald, Glenn Morrow, Dave Oran,
Henning Peters, Tom Phelan, Akbar Rahman, Takako Sanda, Charles Shen, Andreas Pashalidis, Henning Peters, Tom Phelan, Akbar Rahman, Takako
Melinda Shore, Martin Stiemerling, Martijn Swanink, Mike Thomas, Sanda, Charles Shen, Melinda Shore, Martin Stiemerling, Martijn
Hannes Tschofenig, Sven van den Bosch, Michael Welzl, Lars Westberg, Swanink, Mike Thomas, Hannes Tschofenig, Sven van den Bosch, Michael
and Mayi Zoumaro-djayoon. Parts of the TLS usage description Welzl, Lars Westberg, and Mayi Zoumaro-djayoon. Parts of the TLS
(Section 5.7.3) were derived from the Diameter base protocol usage description (Section 5.7.3) were derived from the Diameter base
specification, RFC3588. In addition, Hannes Tschofenig provided a protocol specification, RFC3588. In addition, Hannes Tschofenig
detailed set of review comments on the security section, and Andrew provided a detailed set of review comments on the security section,
McDonald provided the formal description for the initial packet and Andrew McDonald provided the formal description for the initial
formats and the name matching algorithm for TLS. Chris Lang's packet formats and the name matching algorithm for TLS. Chris Lang's
implementation work provided objective feedback on the clarity and implementation work provided objective feedback on the clarity and
feasibility of the specification, and he also provided the state feasibility of the specification, and he also provided the state
machine description and the initial error catalogue and formats. machine description and the initial error catalogue and formats.
Magnus Westerlund carried out a detailed AD review which identified a Magnus Westerlund carried out a detailed AD review which identified a
number of issues and led to significant clarifications, which was number of issues and led to significant clarifications, which was
followed by an even more detailed IESG review, with comments from followed by an even more detailed IESG review, with comments from
Ross Callon, Brian Carpenter, Lisa Dusseault, Lars Eggert, Ted Jari Arkko, Ross Callon, Brian Carpenter, Lisa Dusseault, Lars
Hardie, Sam Hartman, Russ Housley, Cullen Jennings, and a very Eggert, Ted Hardie, Sam Hartman, Russ Housley, Cullen Jennings, and a
detailed analysis by Adrian Farrel from the Routing Area directorate. very detailed analysis by Adrian Farrel from the Routing Area
directorate.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Braden, R., "Requirements for Internet Hosts - Communication [1] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989. Layers", STD 3, RFC 1122, October 1989.
[2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, [2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995. June 1995.
skipping to change at page 112, line 37 skipping to change at page 114, line 37
[7] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of [7] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998. IPv6 Headers", RFC 2474, December 1998.
[8] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [8] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999. RFC 2711, October 1999.
[9] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", [9] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC 2765, February 2000. RFC 2765, February 2000.
[10] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [10] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
RFC 2246, January 1999.
[11] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002. Revocation List (CRL) Profile", RFC 3280, April 2002.
[12] Narten, T., "Assigning Experimental and Testing Numbers [11] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004. Considered Useful", BCP 82, RFC 3692, January 2004.
[13] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [12] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [13] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006. Protocol Version 1.1", RFC 4346, April 2006.
[15] Loughney, J., "NSIS Extensibility Model", [14] Loughney, J., "NSIS Extensibility Model",
draft-loughney-nsis-ext-02 (work in progress), March 2006. draft-loughney-nsis-ext-02 (work in progress), March 2006.
11.2. Informative References 11.2. Informative References
[16] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, [15] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997. Specification", RFC 2205, September 1997.
[16] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[17] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [17] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[18] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP [18] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
Operation Over IP Tunnels", RFC 2746, January 2000. Operation Over IP Tunnels", RFC 2746, January 2000.
[19] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - [19] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000. Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[20] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [20] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
skipping to change at page 113, line 49 skipping to change at page 115, line 49
[25] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. [25] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
Haukka, "Security Mechanism Agreement for the Session Haukka, "Security Mechanism Agreement for the Session
Initiation Protocol (SIP)", RFC 3329, January 2003. Initiation Protocol (SIP)", RFC 3329, January 2003.
[26] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN [26] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through - Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003. Network Address Translators (NATs)", RFC 3489, March 2003.
[27] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal [27] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in Underneath NAT (STUN)", draft-ietf-behave-turn-03 (work in
progress), October 2006. progress), March 2007.
[28] Audet, F. and C. Jennings, "NAT Behavioral Requirements for
Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress),
October 2006.
[29] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL [28] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004. Security Mechanism (GTSM)", RFC 3682, February 2004.
[30] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, [29] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004. July 2004.
[31] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [30] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
June 2005. June 2005.
[32] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next [31] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
Steps in Signaling (NSIS)", RFC 4081, June 2005. Steps in Signaling (NSIS)", RFC 4081, June 2005.
[33] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [32] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[34] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for [33] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for
Transport Layer Security (TLS)", RFC 4279, December 2005. Transport Layer Security (TLS)", RFC 4279, December 2005.
[35] Conta, A., Deering, S., and M. Gupta, "Internet Control Message [34] Conta, A., Deering, S., and M. Gupta, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 4443, March 2006. Specification", RFC 4443, March 2006.
[36] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol [35] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-13 (work in progress), (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in progress),
October 2006. March 2007.
[37] Manner, J., "NSLP for Quality-of-Service Signaling",
draft-ietf-nsis-qos-nslp-12 (work in progress), October 2006.
[38] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for [36] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", RFC 4213, October 2005. IPv6 Hosts and Routers", RFC 4213, October 2005.
[39] Kent, S. and K. Seo, "Security Architecture for the Internet [37] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
[40] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [38] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005. Design Background", RFC 4225, December 2005.
[41] Floyd, S. and V. Jacobson, "The Synchronisation of Periodic [39] Audet, F. and C. Jennings, "Network Address Translation (NAT)
Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787,
January 2007.
[40] Floyd, S. and V. Jacobson, "The Synchronisation of Periodic
Routing Messages", SIGCOMM Symposium on Communications Routing Messages", SIGCOMM Symposium on Communications
Architectures and Protocols pp. 33--44, September 1993. Architectures and Protocols pp. 33--44, September 1993.
[42] Pashalidis, A. and H. Tschofenig, "GIST Legacy NAT Traversal", [41] Pashalidis, A. and H. Tschofenig, "GIST Legacy NAT Traversal",
draft-pashalidis-nsis-gist-legacynats-00 (work in progress), draft-pashalidis-nsis-gist-legacynats-01 (work in progress),
July 2006. March 2007.
[43] Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal", [42] Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal",
draft-pashalidis-nsis-gimps-nattraversal-03 (work in progress), draft-pashalidis-nsis-gimps-nattraversal-04 (work in progress),
June 2006. March 2007.
[44] Tschofenig, H., "GIST State Machine", [43] Tschofenig, H., "GIST State Machine",
draft-ietf-nsis-ntlp-statemachine-02 (work in progress), draft-ietf-nsis-ntlp-statemachine-03 (work in progress),
June 2006. March 2007.
[45] Ramaiah, A., "Improving TCP's Robustness to Blind In-Window [44] Ramaiah, A., "Improving TCP's Robustness to Blind In-Window
Attacks", draft-ietf-tcpm-tcpsecure-07 (work in progress), Attacks", draft-ietf-tcpm-tcpsecure-07 (work in progress),
February 2007. February 2007.
Appendix A. Bit-Level Formats and Error Messages Appendix A. Bit-Level Formats and Error Messages
This appendix provides formats for the various component parts of the This appendix provides formats for the various component parts of the
GIST messages defined abstractly in Section 5.2. The whole of this GIST messages defined abstractly in Section 5.2. The whole of this
appendix is normative. appendix is normative.
Each GIST message consists of a header and a sequence of objects. Each GIST message consists of a header and a sequence of objects.
skipping to change at page 120, line 37 skipping to change at page 122, line 37
F flag: F=1 means that flow label is present and is significant. F F flag: F=1 means that flow label is present and is significant. F
MUST NOT be set if IP-Ver is not 6. MUST NOT be set if IP-Ver is not 6.
Flow Label (20 bits): The flow label; only present if F=1. If F=0, 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. the entire 32 bit word containing the Flow Label is absent.
S flag: S=1 means that the SPI field is present and is significant. 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. The S flag MUST be 0 if the P flag is 0.
SPI field (32 bits): The SPI field; see [39]. If S=0, the entire 32 SPI field (32 bits): The SPI field; see [37]. If S=0, the entire 32
bit word containing the SPI is absent. bit word containing the SPI is absent.
A/B flags: These can only be set if P=1. If either is set, the port 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 fields are also present. If P=0, the A/B flags MUST both be zero
and the word containing the port numbers is absent. and the word containing the port numbers is absent.
Source/Destination Port (each 16 bits): If either of A (source), B Source/Destination Port (each 16 bits): If either of A (source), B
(destination) is set the word containing the port numbers is (destination) is set the word containing the port numbers is
included in the object. However, the contents of each field is included in the object. However, the contents of each field is
only significant if the corresponding flag is set; otherwise, the only significant if the corresponding flag is set; otherwise, the
skipping to change at page 123, line 21 skipping to change at page 125, line 21
0 1 2 3 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 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 | | Prof-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile 1 // // Profile 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile 2 // // Profile N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prof-Count (8 bits): The number of profiles listed. MUST be > 0. Prof-Count (8 bits): The number of profiles listed. MUST be > 0.
Each profile is itself a sequence of protocol layers, and the profile Each profile is itself a sequence of protocol layers, and the profile
is formatted as a list as follows: is formatted as a list as follows:
o The first byte is a count of the number of layers in the profile. o The first byte is a count of the number of layers in the profile.
MUST be > 0. MUST be > 0.
o This is followed by a sequence of 1-byte MA-Protocol-IDs as o This is followed by a sequence of 1-byte MA-Protocol-IDs as
skipping to change at page 132, line 11 skipping to change at page 134, line 11
2: Invalid R-flag: The R flag in the header is inconsistent with the 2: Invalid R-flag: The R flag in the header is inconsistent with the
message type. message type.
3: Incorrect Message Length: The overall message length is not 3: Incorrect Message Length: The overall message length is not
consistent with the set of objects carried. consistent with the set of objects carried.
4: Invalid E-flag: The E flag is set in the header but this is not a 4: Invalid E-flag: The E flag is set in the header but this is not a
Data message. Data message.
5: Missing Magic Number A D-mode message directly addressed to this
node (with the normal or Q-mode encapsulation) did not begin with
the correct magic number.
A.4.4.2. Hop Limit Exceeded A.4.4.2. Hop Limit Exceeded
Class: Permanent-Failure Class: Permanent-Failure
Code: 2 Code: 2
Additional Info: None Additional Info: None
This message is sent if a GIST node receives a message with a GIST 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 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 its GIST hop count has been decremented to zero on reception. This
message indicates either a routing loop or too small an initial hop message indicates either a routing loop or too small an initial hop
skipping to change at page 141, line 36 skipping to change at page 143, line 36
in the GIST state). in the GIST state).
B.6. InvalidateRoutingState B.6. InvalidateRoutingState
This primitive is passed from a signalling application to GIST. It This primitive is passed from a signalling application to GIST. It
indicates that the signalling application has knowledge that the next indicates that the signalling application has knowledge that the next
signalling hop known to GIST may no longer be valid, either because signalling hop known to GIST may no longer be valid, either because
of changes in the network routing or the processing capabilities of of changes in the network routing or the processing capabilities of
signalling application nodes. See Section 7.1. signalling application nodes. See Section 7.1.
InvalidateRoutingState ( NSLPID, MRI, Status, Urgent ) InvalidateRoutingState ( NSLPID, MRI, Status, NSLP-Data,
NSLP-Data-Size, Urgent )
NSLPID: The NSLP originating the message. May be null (in which NSLPID: The NSLP originating the message. May be null (in which
case the invalidation applies to all signalling applications). case the invalidation applies to all signalling applications).
MRI: The flow for which routing state should be invalidated; MRI: The flow for which routing state should be invalidated;
includes the direction of the change (in the D flag). includes the direction of the change (in the D flag).
Status: The new status that should be assumed for the routing state, Status: The new status that should be assumed for the routing state,
one of Bad or Tentative (see Section 7.1.3). one of Bad or Tentative (see Section 7.1.3).
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 Section 4.3.2). The payload will
be transmitted without security protection.
Urgent: A hint as to whether rediscovery should take place Urgent: A hint as to whether rediscovery should take place
immediately, or only with the next signalling message. immediately, or only with the next signalling message.
Appendix C. Deployment Issues with Router Alert Options Appendix C. Deployment Issues with Router Alert Options
The GIST peer discovery handshake (Section 4.4.1) depends on the The GIST peer discovery handshake (Section 4.4.1) depends on the
interception of Q-mode encapsulated IP packets (Section 4.3.1 and interception of Q-mode encapsulated IP packets (Section 4.3.1 and
Section 5.3.2) by routers. There are two fundamental requirements on Section 5.3.2) by routers. There are two fundamental requirements on
the process: the process:
skipping to change at page 146, line 23 skipping to change at page 149, line 23
MRI(MRM=Path-Coupled; Flow=F; Direction=down) MRI(MRM=Path-Coupled; Flow=F; Direction=down)
SessionID(0x1234) NLI(Peer='string1'; IA=IP#B) SessionID(0x1234) NLI(Peer='string1'; IA=IP#B)
QueryCookie(0x139471239471923526) QueryCookie(0x139471239471923526)
StackProposal(#Proposals=3;1=TLS/TCP; 2=TLS/SCTP; 3=TCP) StackProposal(#Proposals=3;1=TLS/TCP; 2=TLS/SCTP; 3=TCP)
StackConfigurationData(HoldTime=300; #MPO=2; StackConfigurationData(HoldTime=300; #MPO=2;
TCP(Applicable: all; Data: null) TCP(Applicable: all; Data: null)
SCTP(Applicable: all; Data: null))) SCTP(Applicable: all; Data: null)))
<---------------------- Response ---------------------------- <---------------------- Response ----------------------------
IP(Src=IP#D; Dst=IP#B); UDP(Src=GIST; Dst=6789) 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) GIST(Header(Type=Response; NSLPID=NSLP2; R=1; S=1)
MRI(MRM=Path-Coupled; Flow=F; Direction=up) MRI(MRM=Path-Coupled; Flow=F; Direction=up)
SessionID(0x1234) NLI(Peer='stringr2', IA=IP#D) SessionID(0x1234) NLI(Peer='stringr2', IA=IP#D)
QueryCookie(0x139471239471923526) QueryCookie(0x139471239471923526)
ResponderCookie(0xacdefedcdfaeeeded) ResponderCookie(0xacdefedcdfaeeeded)
StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP) StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)
StackConfigurationData(HoldTime=200; #MPO=3; StackConfigurationData(HoldTime=200; #MPO=3;
TCP(Applicable: 3; Data: port=6123) TCP(Applicable: 3; Data: port=6123)
TCP(Applicable: 1; Data: port=5438) TCP(Applicable: 1; Data: port=5438)
SCTP(Applicable: all; Data: port=3333))) SCTP(Applicable: all; Data: port=3333)))
skipping to change at page 147, line 10 skipping to change at page 150, line 10
StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP) StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)
StackConfigurationData(HoldTime=300)) StackConfigurationData(HoldTime=300))
Figure 10: GIST Handshake Message Sequence Figure 10: GIST Handshake Message Sequence
Appendix E. Change History Appendix E. Change History
Note to the RFC Editor: this appendix to be removed before Note to the RFC Editor: this appendix to be removed before
publication as an RFC. publication as an RFC.
E.1. Changes in Version -12 E.1. Changes in Version -13
The following changes were made in version 13. Some are further
follow ups to IESG review comments.
1. Changed the C-mode/D-mode selection rules in Section 4.3.3 to
make the use of C-mode a SHOULD unless capacity can be
explicitly engineered. Also added a reference to this fact in
the rate control section, Section 5.3.3, and an explanation of
the effect this has on signalling application behaviour. [Lars
Eggert]
2. Amended the message size limit text in Section 4.3.3 to include
a check on the first-hop MTU as well as the path MTU and 576
byte limit. [Lars Eggert]
3. Added 2119 text at the start of Section 5.8 to define the level
of support required for particular MRMs.
4. Added a note at the end of the first paragraph of Section 7.1.4
to point out the applicability to mobile environments.
5. Added the possibility for the InvalidateRoutingState call
(Appendix B.6) to provide an NSLP payload to support conditional
peering.
6. Clarified the text in Section 4.4.1 to state that the MA-Hold-
Time in the Confirm overrides that in the Query, and also
rewrote part of Section 4.4.5 to make more precise that the MA-
Hold-Time is the time that a node will keep an MA open, rather
than the time it requires the peer to keep it open.
7. Modified the text on MA multiplexing in Section 5.7.1 to make it
clear that re-use is allowed if the candidate MA has equivalent
or better (transport and security) performance as any of the
options offered in the Query, not that it has to be equivalent
to all of them.
8. Extended the rules about message transmission at the end of
Section 4.3.3, to point out that absence of routing state may be
used as trigger for a handshake.
9. Made the reference to TLS1.0 informational to satisfy nit
processing rules.
10. Added text in Section 5.3.3 to clarify that a node should stop
its retransmission process on receiving a response to any of its
messages.
11. Modified the magic number so that it is carried in all D-mode
message (normal and otherwise), with changes in Section 3.6,
Section 5.2.1, and Section 5.3 and a new error subcode in
Appendix A.4.4.1.
E.2. Changes in Version -12
The following changes were made in response to IESG review. The The following changes were made in response to IESG review. The
changes have been classified into three categories: protocol changes changes have been classified into three categories: protocol changes
(things which would directly affect, technical clarifications, and (things which would directly affect, technical clarifications, and
editorial issues. The name of the reviewer is included with each editorial issues. The name of the reviewer is included with each
change. change.
Protocol changes: Protocol changes:
1. Modified the processing rules for the GIST hop count. An 1. Modified the processing rules for the GIST hop count. An
skipping to change at page 150, line 29 skipping to change at page 154, line 37
requirement is to have a Query received within the timeout requirement is to have a Query received within the timeout
period (rather than just to send it), and to provide more period (rather than just to send it), and to provide more
detailed guidance on how to adapt the timer value if rate detailed guidance on how to adapt the timer value if rate
limiting is impacting the number of Queries that can be sent. limiting is impacting the number of Queries that can be sent.
[Adrian Farrel] [Adrian Farrel]
12. Moved the text on SID selection from Section 3.7 to a new 12. Moved the text on SID selection from Section 3.7 to a new
Section 4.1.3 where it is more reasonable for it to be normative Section 4.1.3 where it is more reasonable for it to be normative
(as a requirement on the API). Also added text on residual (as a requirement on the API). Also added text on residual
threats in Section 8.7 explaining how GIST depends on the NSLP threats in Section 8.7 explaining how GIST depends on the NSLP
to follow the rules here.[Sam Hartman] to follow the rules here. [Sam Hartman]
13. Totally restructured the description of Q-mode encapsulation in 13. Totally restructured the description of Q-mode encapsulation in
Section 5.3.2, to provide more detailed rules for IP-level Section 5.3.2, to provide more detailed rules for IP-level
interception and UDP encapsulation, including a description of interception and UDP encapsulation, including a description of
what IP-layer options are allowed (and how they should be what IP-layer options are allowed (and how they should be
handled) and what additional encapsulation layers are not handled) and what additional encapsulation layers are not
allowed. [Sam Hartman] allowed. [Sam Hartman]
14. Added discussion of overload protection mechanisms mainly in 14. Added discussion of overload protection mechanisms mainly in
Section 8.4, with supporting text in Section 4.1.1 and Section 8.4, with supporting text in Section 4.1.1 and
skipping to change at page 156, line 17 skipping to change at page 160, line 25
54. Modified the labelling in Figure 4 to avoid the label 'Q-node' 54. Modified the labelling in Figure 4 to avoid the label 'Q-node'
etc. (could cause confusion with Q-mode). [Lisa Dusseault] etc. (could cause confusion with Q-mode). [Lisa Dusseault]
55. Split the old section on state maintenance into Section 4.4.4 55. Split the old section on state maintenance into Section 4.4.4
and Section 4.4.5 to avoid confusion between the two types of and Section 4.4.5 to avoid confusion between the two types of
operation. [Lisa Dusseault] operation. [Lisa Dusseault]
Various other minor editorial corrections have also been made. Various other minor editorial corrections have also been made.
E.2. Changes In Version -11 E.3. Changes In Version -11
1. Added some text in Section 1 to clarify the scope of GIST 1. Added some text in Section 1 to clarify the scope of GIST
applicability with non-path-coupled message routing methods. applicability with non-path-coupled message routing methods.
2. Loosened the text about the Query encapsulation to indicate that 2. Loosened the text about the Query encapsulation to indicate that
a Router Alert Option is needed for all the current message a Router Alert Option is needed for all the current message
routing methods but not necessarily for future ones. routing methods but not necessarily for future ones.
3. Clarified the rules for deriving protocol encapsulation 3. Clarified the rules for deriving protocol encapsulation
addresses for the Response and other messages in Section 4.4.1 addresses for the Response and other messages in Section 4.4.1
skipping to change at page 157, line 14 skipping to change at page 161, line 22
9. Clarified the units (bytes, 32-bit words) for all length fields 9. Clarified the units (bytes, 32-bit words) for all length fields
in Appendix A. in Appendix A.
10. Clarified that the restriction on the D flag value for the 10. Clarified that the restriction on the D flag value for the
loose-end MRM applies only to Q-mode messages in loose-end MRM applies only to Q-mode messages in
Appendix A.3.1.2. Appendix A.3.1.2.
11. Added the Hold Time to the example in Appendix D. 11. Added the Hold Time to the example in Appendix D.
E.3. Changes In Version -10 E.4. Changes In Version -10
1. Added further guidance on parameter setting for initial backoff 1. Added further guidance on parameter setting for initial backoff
and rate control for D-mode to Section 5.3.3 [AD review comment and rate control for D-mode to Section 5.3.3 [AD review comment
M1]. M1].
2. Rephrased the end of Section 8.6 to highlight the threat left 2. Rephrased the end of Section 8.6 to highlight the threat left
open when the Querying node does not apply a strong security open when the Querying node does not apply a strong security
policy to offered Stack-Proposal [AD review comment M2]. policy to offered Stack-Proposal [AD review comment M2].
3. Clarified in Section 7.2 that although NAT behaviour is only 3. Clarified in Section 7.2 that although NAT behaviour is only
skipping to change at page 161, line 11 skipping to change at page 165, line 15
L4: Direct use of PMTUD by GIST. L4: Direct use of PMTUD by GIST.
L13: Use of TLS 1.0 rather than 1.1. L13: Use of TLS 1.0 rather than 1.1.
L17: Guidance on NSLP behaviour during rerouting, L17: Guidance on NSLP behaviour during rerouting,
L18: Behaviour of GIST-unaware NATs. L18: Behaviour of GIST-unaware NATs.
N3: Node state machine logic. N3: Node state machine logic.
E.4. Changes In Version -09 E.5. Changes In Version -09
1. Added a new Section 3.8 clarifying the relationship between 1. Added a new Section 3.8 clarifying the relationship between
signalling applications and NSLPIDs; modified terminology in the signalling applications and NSLPIDs; modified terminology in the
remainder of the document likewise. remainder of the document likewise.
2. Added a new Section 8.6 explaining the rationale behind the 2. Added a new Section 8.6 explaining the rationale behind the
downgrade attack prevention mechanism. downgrade attack prevention mechanism.
3. Re-wrote parts of Section 4.3.2, Section 6.1 and Appendix B.2 to 3. Re-wrote parts of Section 4.3.2, Section 6.1 and Appendix B.2 to
clarify the way that GIST is assumed to interact with signalling clarify the way that GIST is assumed to interact with signalling
skipping to change at page 162, line 5 skipping to change at page 166, line 9
8. Clarified that the Stack-Proposal lists protocols in top-to- 8. Clarified that the Stack-Proposal lists protocols in top-to-
bottom order (see Section 5.7.1). bottom order (see Section 5.7.1).
9. Enhanced the definition of TLS usage in Section 5.7.3 with 9. Enhanced the definition of TLS usage in Section 5.7.3 with
details on ciphersuite requirements and authentication methods. details on ciphersuite requirements and authentication methods.
10. Tidied up terminology and discussion of how protocol options 10. Tidied up terminology and discussion of how protocol options
data is carried in the SCD; renamed higher-layer-addressing to data is carried in the SCD; renamed higher-layer-addressing to
MA-protocol-options. MA-protocol-options.
E.5. Changes In Version -08 E.6. Changes In Version -08
1. Changed the protocol name from GIMPS to GIST (everywhere). 1. Changed the protocol name from GIMPS to GIST (everywhere).
2. Inserted RFC2119 language (MUST etc.) in the appropriate places. 2. Inserted RFC2119 language (MUST etc.) in the appropriate places.
3. Added references to the actions to be taken in various error 3. Added references to the actions to be taken in various error
conditions, including the error messages to be send conditions, including the error messages to be send
(throughout). (throughout).
4. Added legacy NAT traversal to the list of excluded functions in 4. Added legacy NAT traversal to the list of excluded functions in
skipping to change at page 163, line 30 skipping to change at page 167, line 35
(Section 7.3). (Section 7.3).
17. Formalised the IANA considerations (Section 9). 17. Formalised the IANA considerations (Section 9).
18. Extended the routing state example (Appendix D) to include a 18. Extended the routing state example (Appendix D) to include a
message sequence for association setup. message sequence for association setup.
19. Re-arranged the sequence of sections, including placing this 19. Re-arranged the sequence of sections, including placing this
change history at the end. change history at the end.
E.6. Changes In Version -07 E.7. Changes In Version -07
1. The open issues section has finally been removed in favour of the 1. The open issues section has finally been removed in favour of the
authoritative list of open issues in an online issue tracker at h authoritative list of open issues in an online issue tracker at h
ttp://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index. ttp://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index.
2. Clarified terminology on peering and adjacencies that there may 2. Clarified terminology on peering and adjacencies that there may
be NSIS nodes between GIMPS peers that do some message be NSIS nodes between GIMPS peers that do some message
processing, but that are not explicitly visible in the peer state processing, but that are not explicitly visible in the peer state
tables. tables.
skipping to change at page 164, line 23 skipping to change at page 168, line 26
message catalogue in Appendix A.4, including a modified format message catalogue in Appendix A.4, including a modified format
for the overall GIMPS-Error message and the GIMPS-Error-Data for the overall GIMPS-Error message and the GIMPS-Error-Data
object. object.
8. Removed the old section 5.3.3 on NSLPID/RAO setting on the 8. Removed the old section 5.3.3 on NSLPID/RAO setting on the
assumption that this will be covered in the extensibility assumption that this will be covered in the extensibility
document. document.
9. Included a number of other minor corrections and clarifications. 9. Included a number of other minor corrections and clarifications.
E.7. Changes In Version -06 E.8. Changes In Version -06
Version -06 does not introduce any major structural changes to the Version -06 does not introduce any major structural changes to the
protocol definition, although it does clarify a number of details and protocol definition, although it does clarify a number of details and
resolve some outstanding open issues. The primary changes are as resolve some outstanding open issues. The primary changes are as
follows: follows:
1. Added a new high level Section 3.3 which gathers together the 1. Added a new high level Section 3.3 which gathers together the
various aspects of the message routing method concept. various aspects of the message routing method concept.
2. Added a new high level Section 3.7 which explains the concept 2. Added a new high level Section 3.7 which explains the concept
skipping to change at page 165, line 28 skipping to change at page 169, line 30
9. Added a new Section 5.5 explaining the possible relationships 9. Added a new Section 5.5 explaining the possible relationships
between message types and encapsulation formats. between message types and encapsulation formats.
10. Added a new Section 6 in outline form, to capture the formal 10. Added a new Section 6 in outline form, to capture the formal
specification of the protocol operation. specification of the protocol operation.
11. Added new security sections on cookie requirements (Section 8.5) 11. Added new security sections on cookie requirements (Section 8.5)
and residual threats (Section 8.7). and residual threats (Section 8.7).
E.8. Changes In Version -05 E.9. Changes In Version -05
Version -05 reformulates the specification, to describe routing state Version -05 reformulates the specification, to describe routing state
maintenance in terms of exchanging explicitly identified Query/ maintenance in terms of exchanging explicitly identified Query/
Response/Confirm messages, leaving the upstream/downstream Response/Confirm messages, leaving the upstream/downstream
distinction as a specific detail of how Query messages are distinction as a specific detail of how Query messages are
encapsulated. This necessitated widespread changes in the encapsulated. This necessitated widespread changes in the
specification text, especially Section 4.2.1, Section 4.4, specification text, especially Section 4.2.1, Section 4.4,
Section 5.1 and Section 5.3 (although the actual message sequences Section 5.1 and Section 5.3 (although the actual message sequences
are unchanged). A number of other issues, especially in the area of are unchanged). A number of other issues, especially in the area of
message encapsulation, have also been closed. The main changes are message encapsulation, have also been closed. The main changes are
skipping to change at page 166, line 31 skipping to change at page 170, line 35
choice of timer-based retransmission of the Response, or an choice of timer-based retransmission of the Response, or an
error message from the responding node which causes the error message from the responding node which causes the
retransmission of the Confirm (see Section 5.3.3). retransmission of the Confirm (see Section 5.3.3).
9. Closed the open issue on support for message scoping (this is 9. Closed the open issue on support for message scoping (this is
now assumed to be a NSLP function). now assumed to be a NSLP function).
10. Moved the authoritative text for most of the remaining open 10. Moved the authoritative text for most of the remaining open
issues to an online issue tracker. issues to an online issue tracker.
E.9. Changes In Version -04 E.10. Changes In Version -04
Version -04 includes mainly clarifications of detail and extensions Version -04 includes mainly clarifications of detail and extensions
in particular technical areas, in part to support ongoing in particular technical areas, in part to support ongoing
implementation work. The main details are as follows: implementation work. The main details are as follows:
1. Substantially updated Section 4, in particular clarifying the 1. Substantially updated Section 4, in particular clarifying the
rules on what messages are sent when and with what payloads rules on what messages are sent when and with what payloads
during routing and messaging association setup, and also adding during routing and messaging association setup, and also adding
some further text on message transfer attributes. some further text on message transfer attributes.
skipping to change at page 167, line 43 skipping to change at page 171, line 46
9. The description of the D-mode transport in Section 5.3 has been 9. The description of the D-mode transport in Section 5.3 has been
updated. The encapsulation rules (covering IP addressing and updated. The encapsulation rules (covering IP addressing and
UDP port allocation) have been corrected, and a new subsection UDP port allocation) have been corrected, and a new subsection
on message retransmission and rate limiting has been added, on message retransmission and rate limiting has been added,
superseding the old open issue on the same subject (section superseding the old open issue on the same subject (section
8.10). 8.10).
10. A new open issue on IP TTL measurement to detect non-GIMPS 10. A new open issue on IP TTL measurement to detect non-GIMPS
capable hops has been added (old section 9.5). capable hops has been added (old section 9.5).
E.10. Changes In Version -03 E.11. Changes In Version -03
Version -03 includes a number of minor clarifications and extensions Version -03 includes a number of minor clarifications and extensions
compared to version -02, including more details of the GIMPS API and compared to version -02, including more details of the GIMPS API and
messaging association setup and the node addressing object. The full messaging association setup and the node addressing object. The full
list of changes is as follows: list of changes is as follows:
1. Added a new section pinning down more formally the interaction 1. Added a new section pinning down more formally the interaction
between GIMPS and signalling applications (Section 4.1), in between GIMPS and signalling applications (Section 4.1), in
particular the message transfer attributes that signalling particular the message transfer attributes that signalling
applications can use to control GIMPS (Section 4.1.2). applications can use to control GIMPS (Section 4.1.2).
skipping to change at page 168, line 36 skipping to change at page 172, line 39
7. Added more detail on the bundling possibilities and appropriate 7. Added more detail on the bundling possibilities and appropriate
configurations for various transport protocols in Section 5.4. configurations for various transport protocols in Section 5.4.
8. Included some more details on NAT traversal in Section 7.2, 8. Included some more details on NAT traversal in Section 7.2,
including a new object to carry the untranslated address-bearing including a new object to carry the untranslated address-bearing
payloads, the NAT-Traversal object. payloads, the NAT-Traversal object.
9. Expanded the open issue discussion in old section 9.3 to include 9. Expanded the open issue discussion in old section 9.3 to include
an outline set of extensibility flags. an outline set of extensibility flags.
E.11. Changes In Version -02 E.12. Changes In Version -02
Version -02 does not represent any radical change in design or Version -02 does not represent any radical change in design or
structure from version -01; the emphasis has been on adding details structure from version -01; the emphasis has been on adding details
in some specific areas and incorporation of comments, including early in some specific areas and incorporation of comments, including early
review comments. The full list of changes is as follows: review comments. The full list of changes is as follows:
1. Added a new section 1.1 (since removed in version 12) which 1. Added a new section 1.1 (since removed in version 12) which
summarises restrictions on scope and applicability; some summarises restrictions on scope and applicability; some
corresponding changes in terminology in Section 2. corresponding changes in terminology in Section 2.
skipping to change at page 170, line 5 skipping to change at page 174, line 5
changes in Section 4.4 and the various sections on message changes in Section 4.4 and the various sections on message
formats. formats.
10. Removed the open issue on whether storing reverse routing state 10. Removed the open issue on whether storing reverse routing state
is mandatory or optional. This is now explicit in the API is mandatory or optional. This is now explicit in the API
(under the control of the local NSLP). (under the control of the local NSLP).
11. Added an informative annex describing an abstract API between 11. Added an informative annex describing an abstract API between
GIMPS and NSLPs in Appendix B. GIMPS and NSLPs in Appendix B.
E.12. Changes In Version -01 E.13. Changes In Version -01
The major change in version -01 is the elimination of The major change in version -01 is the elimination of
'intermediaries', i.e. imposing the constraint that signalling 'intermediaries', i.e. imposing the constraint that signalling
application peers are also GIMPS peers. This has the consequence application peers are also GIMPS peers. This has the consequence
that if a signalling application wishes to use two classes of that if a signalling application wishes to use two classes of
signalling transport for a given flow, maybe reaching different signalling transport for a given flow, maybe reaching different
subsets of nodes, it must do so by running different signalling subsets of nodes, it must do so by running different signalling
sessions; and it also means that signalling adaptations for passing sessions; and it also means that signalling adaptations for passing
through NATs which are not signalling application aware must be through NATs which are not signalling application aware must be
carried out in D-mode. On the other hand, it allows the elimination carried out in D-mode. On the other hand, it allows the elimination
 End of changes. 130 change blocks. 
389 lines changed or deleted 481 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/