< draft-ietf-nsis-ntlp-08.txt   draft-ietf-nsis-ntlp-09.txt >
Next Steps in Signaling H. Schulzrinne Next Steps in Signaling H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Expires: March 31, 2006 R. Hancock Expires: August 13, 2006 R. Hancock
Siemens/RMR Siemens/RMR
September 27, 2005 February 9, 2006
GIST: General Internet Signaling Transport GIST: General Internet Signaling Transport
draft-ietf-nsis-ntlp-08 draft-ietf-nsis-ntlp-09
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 March 31, 2006. This Internet-Draft will expire on August 13, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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 signaling messages along the path taken by that flow of per-flow signaling 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
protocols under a common messaging layer, the General Internet protocols under a common messaging layer, the General Internet
Signaling Transport (GIST), which provides a universal service for Signaling Transport (GIST), which provides a universal service for
diverse signaling applications. GIST does not handle signaling diverse signaling applications. GIST does not handle signaling
application state itself, but manages its own internal state and the application state itself, but manages its own internal state and the
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Restrictions on Scope . . . . . . . . . . . . . . . . . . 5 1.1. Restrictions on Scope . . . . . . . . . . . . . . . . . . 5
2. Requirements Notation and Terminology . . . . . . . . . . . . 6 2. Requirements Notation and Terminology . . . . . . . . . . . . 6
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 8 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 8 3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 8
3.2. Modes and Messaging Associations . . . . . . . . . . . . 9 3.2. Modes and Messaging Associations . . . . . . . . . . . . 9
3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 10 3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 10
3.4. Signaling Sessions . . . . . . . . . . . . . . . . . . . 12 3.4. Signaling Sessions . . . . . . . . . . . . . . . . . . . 12
3.5. Example of Operation . . . . . . . . . . . . . . . . . . 13 3.5. Signaling Applications and NSLPIDs . . . . . . . . . . . 13
3.6. Example of Operation . . . . . . . . . . . . . . . . . . 14
4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 16 4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 16
4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 16 4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 16
4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Basic Message Processing . . . . . . . . . . . . . . . . 19 4.3. Basic Message Processing . . . . . . . . . . . . . . . . 19
4.4. Routing State and Messaging Association Maintenance . . . 25 4.4. Routing State and Messaging Association Maintenance . . . 25
5. Message Formats and Transport . . . . . . . . . . . . . . . . 31 5. Message Formats and Transport . . . . . . . . . . . . . . . . 32
5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 31 5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 32
5.2. Information Elements . . . . . . . . . . . . . . . . . . 33 5.2. Information Elements . . . . . . . . . . . . . . . . . . 34
5.3. Datagram Mode Transport . . . . . . . . . . . . . . . . . 37 5.3. Datagram Mode Transport . . . . . . . . . . . . . . . . . 38
5.4. Connection Mode Transport . . . . . . . . . . . . . . . . 39 5.4. Connection Mode Transport . . . . . . . . . . . . . . . . 40
5.5. Message Type/Encapsulation Relationships . . . . . . . . 41 5.5. Message Type/Encapsulation Relationships . . . . . . . . 42
5.6. Error Message Processing . . . . . . . . . . . . . . . . 42 5.6. Error Message Processing . . . . . . . . . . . . . . . . 43
5.7. Messaging Association Setup . . . . . . . . . . . . . . . 43 5.7. Messaging Association Setup . . . . . . . . . . . . . . . 44
5.8. Specific Message Routing Methods . . . . . . . . . . . . 45 5.8. Specific Message Routing Methods . . . . . . . . . . . . 47
6. Formal Protocol Specification . . . . . . . . . . . . . . . . 51 6. Formal Protocol Specification . . . . . . . . . . . . . . . . 52
6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 52 6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 53
6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 54 6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 55
6.3. Responder Node Processing . . . . . . . . . . . . . . . . 57 6.3. Responder Node Processing . . . . . . . . . . . . . . . . 58
6.4. Messaging Association Processing . . . . . . . . . . . . 60 6.4. Messaging Association Processing . . . . . . . . . . . . 62
7. Advanced Protocol Features . . . . . . . . . . . . . . . . . 63 7. Advanced Protocol Features . . . . . . . . . . . . . . . . . 65
7.1. Route Changes and Local Repair . . . . . . . . . . . . . 63 7.1. Route Changes and Local Repair . . . . . . . . . . . . . 65
7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 69 7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 71
7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 72 7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 74
7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 73 7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 75
8. Security Considerations . . . . . . . . . . . . . . . . . . . 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 77
8.1. Message Confidentiality and Integrity . . . . . . . . . . 75 8.1. Message Confidentiality and Integrity . . . . . . . . . . 77
8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 76 8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 78
8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 76 8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 78
8.4. Denial of Service Prevention . . . . . . . . . . . . . . 78 8.4. Denial of Service Prevention . . . . . . . . . . . . . . 80
8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 79 8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 81
8.6. Residual Threats . . . . . . . . . . . . . . . . . . . . 80 8.6. Security Protocol Selection Policy . . . . . . . . . . . 83
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 8.7. Residual Threats . . . . . . . . . . . . . . . . . . . . 84
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91
11.1. Normative References . . . . . . . . . . . . . . . . . . 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 92
11.2. Informative References . . . . . . . . . . . . . . . . . 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 92
Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 91 11.2. Informative References . . . . . . . . . . . . . . . . . 92
A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 91 Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 95
A.2. General Object Format . . . . . . . . . . . . . . . . . . 92 A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 95
A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 93 A.2. General Object Format . . . . . . . . . . . . . . . . . . 96
A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 100 A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 97
Appendix B. API between GIST and NSLP . . . . . . . . . . . . . 108 A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 104
B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 108 Appendix B. API between GIST and Signaling Applications . . . . 112
B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 109 B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 112
B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 111 B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 113
B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 111 B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 115
B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 112 B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 115
B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 112 B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 116
B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 116
Appendix C. Example Routing State Table and Handshake Message Appendix C. Example Routing State Table and Handshake Message
Sequence . . . . . . . . . . . . . . . . . . . . . . 113 Sequence . . . . . . . . . . . . . . . . . . . . . . 118
Appendix D. Change History . . . . . . . . . . . . . . . . . . . 115 Appendix D. Change History . . . . . . . . . . . . . . . . . . . 120
D.1. Changes In Version -08 . . . . . . . . . . . . . . . . . 115 D.1. Changes In Version -09 . . . . . . . . . . . . . . . . . 120
D.2. Changes In Version -07 . . . . . . . . . . . . . . . . . 116 D.2. Changes In Version -08 . . . . . . . . . . . . . . . . . 120
D.3. Changes In Version -06 . . . . . . . . . . . . . . . . . 117 D.3. Changes In Version -07 . . . . . . . . . . . . . . . . . 122
D.4. Changes In Version -05 . . . . . . . . . . . . . . . . . 118 D.4. Changes In Version -06 . . . . . . . . . . . . . . . . . 123
D.5. Changes In Version -04 . . . . . . . . . . . . . . . . . 119 D.5. Changes In Version -05 . . . . . . . . . . . . . . . . . 124
D.6. Changes In Version -03 . . . . . . . . . . . . . . . . . 120 D.6. Changes In Version -04 . . . . . . . . . . . . . . . . . 125
D.7. Changes In Version -02 . . . . . . . . . . . . . . . . . 121 D.7. Changes In Version -03 . . . . . . . . . . . . . . . . . 126
D.8. Changes In Version -01 . . . . . . . . . . . . . . . . . 122 D.8. Changes In Version -02 . . . . . . . . . . . . . . . . . 127
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125 D.9. Changes In Version -01 . . . . . . . . . . . . . . . . . 128
Intellectual Property and Copyright Statements . . . . . . . . . 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 131
Intellectual Property and Copyright Statements . . . . . . . . . 132
1. Introduction 1. Introduction
Signaling involves the manipulation of state held in network Signaling 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 on "path-coupled" signaling, which This specification concentrates on "path-coupled" signaling, which
involves network elements which are located on the path taken by a involves network elements which are located on the path taken by a
skipping to change at page 4, line 35 skipping to change at page 4, line 35
reservation"), firewall configuration, and state used in active reservation"), firewall configuration, and state used in active
networking; examples of state monitoring are the discovery of networking; examples of state monitoring are the discovery of
instantaneous path properties (such as available bandwidth, or instantaneous path properties (such as available bandwidth, or
cumulative queuing delay). Each of these different uses of path- cumulative queuing delay). Each of these different uses of path-
coupled signaling is referred to as a signaling application. coupled signaling is referred to as a signaling application.
Every signaling application requires a set of state management rules, Every signaling application requires a set of state management rules,
as well as protocol support to exchange messages along the data path. as well as protocol support to exchange messages along the data path.
Several aspects of this protocol support are common to all or a large Several aspects of this protocol support are common to all or a large
number of signaling applications, and hence can be developed as a number of signaling applications, and hence can be developed as a
common protocol. The NSIS framework given in [24] provides a common protocol. The NSIS framework given in [22] provides a
rationale for a function split between the common and application rationale for a function split between the common and application
specific protocols, and gives outline requirements for the former, specific protocols, and gives outline requirements for the former,
the 'NSIS Transport Layer Protocol' (NTLP). the 'NSIS Transport Layer Protocol' (NTLP). The application specific
protocols are referred to as 'NSIS Signaling Layer Protocols'
(NSLPs), and are defined in separate documents.
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 Signaling Transport common messaging layer, the General Internet Signaling Transport
(GIST). GIST does not handle signaling application state itself; in (GIST). GIST does not handle signaling application state itself; in
that crucial respect, it differs from application signaling protocols that crucial respect, it differs from application signaling protocols
such as SIP, RTSP, and the control component of FTP. Instead, GIST such as SIP, RTSP, and the control component of FTP. Instead, GIST
manages its own internal state and the configuration of the manages its own internal state and the configuration of the
underlying transport and security protocols to ensure the transfer of underlying transport and security protocols to ensure the transfer of
signaling messages on behalf of signaling applications in both signaling messages on behalf of signaling applications in both
directions along the flow path. directions along the flow path.
The structure of this specification is as follows. Section 2 defines The structure of this specification is as follows. Section 2 defines
terminology, and Section 3 gives an informal overview of the protocol terminology, and Section 3 gives an informal overview of the protocol
design principles and operation. The normative specification is design principles and operation. The normative specification is
contained mainly in Section 4 to Section 8. Section 3 describes the contained mainly in Section 4 to Section 8. Section 4 describes the
message sequences and Section 5 their format and contents (note that message sequences and Section 5 their format and contents (note that
the detailed bit formats are given in Appendix A). The protocol the detailed bit formats are given in Appendix A). The protocol
operation is captured in the form of state machine language in operation is captured in the form of state machine language in
Section 6. Section 7 describes some particular more advanced Section 6. Section 7 describes some more advanced protocol features
protocol features and security considerations are contained in and security considerations are contained in Section 8. In addition,
Section 8. In addition, Section 9 gives the IANA considerations, Section 9 gives the IANA considerations, Appendix B describes an
Appendix C an example message flow, and Appendix B describes an
abstract API for the service which GIST provides to signaling abstract API for the service which GIST provides to signaling
applications. applications, and Appendix C provides an example message flow.
1.1. Restrictions on Scope 1.1. Restrictions on Scope
This section briefly lists some important restrictions on GIST This section briefly lists some important restrictions on GIST
applicability and functionality. In some cases, these are implicit applicability and functionality. In some cases, these are implicit
consequences of the functionality split developed in the NSIS consequences of the functionality split developed in the NSIS
framework; in others, they are restrictions on the types of scenario framework; in others, they are restrictions on the types of scenario
in which GIST can operate correctly. in which GIST can operate correctly.
Flow splitting: In some cases, e.g. where packet-level load sharing Flow splitting: In some cases, e.g. where packet-level load sharing
skipping to change at page 5, line 40 skipping to change at page 5, line 42
Multicast: GIST does not handle multicast flows. This includes Multicast: GIST does not handle multicast flows. This includes
'classical' IP multicast and any of the 'small group multicast' 'classical' IP multicast and any of the 'small group multicast'
schemes recently proposed. schemes recently proposed.
Legacy NATs: GIST messages will generally pass through NATs, but Legacy NATs: GIST messages will generally pass through NATs, but
unless the NAT is GIST-aware, any addressing data carried in the unless the NAT is GIST-aware, any addressing data carried in the
payload will not be handled correctly. There is a dual problem of payload will not be handled correctly. There is a dual problem of
whether the GIST peers either side of the boundary can work out whether the GIST peers either side of the boundary can work out
how to address each other, and whether they can work out what how to address each other, and whether they can work out what
translation to apply to their payloads what is done to the translation to apply to the signaling packet payloads. The
signaling packet headers. The fundamental problem is that GIST fundamental problem is that GIST messages contain 3 or 4
messages contain 3 or 4 interdependent addresses which all have to interdependent addresses which all have to be consistently
be consistently translated, and existing generic NAT traversal translated, and existing generic NAT traversal techniques such as
techniques such as STUN [22] or TURN can process only two. STUN [19] or TURN [20] can process only two. (Appropriate
(Appropriate behaviour for a GIST-aware NAT is discussed in behaviour for a GIST-aware NAT is discussed in Section 7.2.)
Section 7.2.)
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 [2]. document are to be interpreted as described in [2].
The terminology used in this specification is fully defined in this The terminology used in this specification is fully defined in this
section. The basic entities relevant at the GIST level are shown in section. The basic entities relevant at the GIST level are shown in
Figure 1. Figure 1.
skipping to change at page 7, line 43 skipping to change at page 7, line 43
Messaging Association: A single connection between two explicitly Messaging Association: A single connection between two explicitly
identified GIST adjacent peers, i.e. between a given signaling identified GIST adjacent peers, i.e. between a given signaling
source and destination address. A messaging association may use a source and destination address. A messaging association may use a
specific transport protocol and known ports. If security specific transport protocol and known ports. If security
protection is required, it may use a specific network layer protection is required, it may use a specific network layer
security association, or use a transport layer security security association, or use a transport layer security
association internally. A messaging association is bidirectional; association internally. A messaging association is bidirectional;
signaling messages can be sent over it in either direction, and signaling messages can be sent over it in either direction, and
can refer to flows of either direction. can refer to flows of either direction.
Message Routing Method: Even in the path-coupled case, there can be Message Routing Method: There can be different algorithms for
different algorithms for discovering the route that signaling discovering the route that signaling messages should take. These
messages should take. These are referred to as message routing are referred to as message routing methods, and GIST supports
methods, and GIST supports alternatives within a common protocol alternatives within a common protocol framework. See Section 3.3.
framework. See Section 3.3.
Transfer Attributes: A description of the requirements which a Transfer Attributes: A description of the requirements which a
signaling application has for the delivery of a particular signaling 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.
3. Design Overview 3. Design Overview
3.1. Overall Design Approach 3.1. Overall Design Approach
The generic requirements identified in the NSIS framework [24] for The generic requirements identified in the NSIS framework [22] for
transport of path-coupled signaling messages are essentially two- transport of path-coupled signaling messages are essentially two-
fold: fold:
"Routing": Determine how to reach the adjacent signaling node along "Routing": Determine how to reach the adjacent signaling 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 signaling information to that peer. "Transport": Deliver the signaling 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
use local routing state information to determine the identity of the use local routing state information to determine the identity of the
GIST peer explicitly. GIST defines a 3-way handshake (Query/ GIST peer explicitly. GIST defines a 3-way handshake (Query/
Response/optional Confirm) which sets up the necessary routing state Response/optional Confirm) which sets up the necessary routing state
between adjacent peers, during which signaling application data can between adjacent peers, during which signaling applications can also
also be exchanged; the Query message is encapsulated in a special exchange data; the Query message is encapsulated in a special way,
way, depending on the message routing method, in order to probe the depending on the message routing method, in order to probe the
network infrastructure so that the correct peer will intercept it. network infrastructure so that the correct peer will intercept it.
If the routing state does not exist, it may be possible for GIST to If the routing state does not exist, GIST may be able to send a
send a message anyway, with the same encapsulation as used for a message anyway, with the same encapsulation as for a Query message.
Query message.
Once the routing decision has been made, the node has to select a Once the routing decision has been made, the node has to select a
mechanism for transport of the message to the peer. GIST divides the mechanism for transport of the message to the peer. GIST divides the
transport problems into two categories, the easy and the difficult. transport problems into two categories, the easy and the difficult.
It handles the easy cases internally, and uses well-understood It handles the easy cases internally, and uses well-understood
transport protocols for the harder cases. Here, with details transport protocols for the harder cases. Here, with details
discussed later, "easy" messages are those that are sized well below discussed later, "easy" messages are those that are sized well below
the lowest MTU along a path, are infrequent enough not to cause the lowest MTU along a path, are infrequent enough not to cause
concerns about congestion and flow control, and do not need security concerns about congestion and flow control, and do not need security
protection or guaranteed delivery. protection or guaranteed delivery.
In [24] all of these routing and transport requirements are assigned In [22] 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, as a specialised GIST 'messaging' layered structure for the NTLP, of a specialised GIST 'messaging'
layer running over standard transport and security protocols, as layer running over standard transport and security protocols, as
shown in Figure 2. This also shows GIST offering its services to shown in Figure 2. This also shows GIST offering its services to
upper layers at an abstract interface, the GIST API, further upper layers at an abstract interface, the GIST API, further
discussed in Section 4.1. discussed in Section 4.1.
^^ +-------------+ ^^ +-------------+
|| | Signaling | || | Signaling |
NSIS +------------|Application 2| NSIS +------------|Application 2|
Signaling | Signaling +-------------+ Signaling | Signaling +-------------+
Application |Application 1| | Application |Application 1| |
Level +-------------+ | Level +-------------+ |
|| | | || | |
VV | | VV | |
=========|===================|===== <-- GIST API ========|===================|===== <-- GIST API
| | | |
^^ +------------------------------------------------+ ^^ +------------------------------------------------+
|| |+-----------------------+ +--------------+ | || |+-----------------------+ +--------------+ |
|| || GIST | | GIST State | | || || GIST | | GIST State | |
|| || Encapsulation |<<<>>>| Maintenance | | || || Encapsulation |<<<>>>| Maintenance | |
|| |+-----------------------+ +--------------+ | || |+-----------------------+ +--------------+ |
|| | GIST: Messaging Layer | || | GIST: Messaging Layer |
|| +------------------------------------------------+ || +------------------------------------------------+
NSIS | | | | NSIS | | | |
Transport ............................. Transport .............................
Level . Transport Layer Security . Level . Transport Layer Security .
("NTLP") ............................. ("NTLP") .............................
|| | | | | || | | | |
|| +----+ +----+ +----+ +----+ || +----+ +----+ +----+ +----+
|| |UDP | |TCP | |SCTP| |DCCP|.... || |UDP | |TCP | |SCTP| |DCCP| ... other
|| +----+ +----+ +----+ +----+ || +----+ +----+ +----+ +----+ protocols
|| | | | | || | | | |
|| ............................. || .............................
|| . IP Layer Security . || . IP Layer Security .
|| ............................. || .............................
VV | | | | VV | | | |
=========================|=======|=======|=======|=============== ========================|=======|=======|=======|===============
| | | | | | | |
+----------------------------------------------+ +----------------------------------------------+
| IP | | IP |
+----------------------------------------------+ +----------------------------------------------+
Figure 2: Protocol Stacks for Signaling Transport Figure 2: Protocol Stacks for Signaling Transport
3.2. Modes and Messaging Associations 3.2. Modes and Messaging Associations
Internally, GIST has two modes of operation: Internally, GIST has two modes of operation:
Datagram mode ('D mode') is used for small, infrequent messages with Datagram mode ('D mode') is used for small, infrequent messages with
modest delay constraints; it is also used at least for the Query modest delay constraints; it is also used at least for the Query
message of the 3-way handshake. message of the 3-way handshake.
skipping to change at page 11, line 11 skipping to change at page 11, line 11
3.3. Message Routing Methods 3.3. Message Routing Methods
The baseline message routing functionality in GIST is that signaling The baseline message routing functionality in GIST is that signaling
messages follow a route defined by an existing flow in the network, messages follow a route defined by an existing flow in the network,
visiting a subset of the nodes through which it passes. This is the visiting a subset of the nodes through which it passes. This is the
appropriate behaviour for application scenarios where the purpose of appropriate behaviour for application scenarios where the purpose of
the signaling is to manipulate resources for that flow. However, the signaling is to manipulate resources for that flow. However,
there are scenarios for which other behaviours are applicable. Two there are scenarios for which other behaviours are applicable. Two
examples are: examples are:
Predictive Routing: Here, the intent is to send signaling along a Predictive Routing: Here, the intent is to signal along a path that
path that the data flow may or will follow in the future. the data flow may follow in the future. Possible cases are pre-
Possible cases are pre-installation of state on the backup path installation of state on the backup path that would be used in the
that would be used in the event of a link failure; and predictive event of a link failure; and predictive installation of state on
installation of state on the path that will be used after a mobile the path that will be used after a mobile node handover.
node handover.
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 Most of the details of GIST operation are independent of which
alternative is being used. Therefore, the GIST design encapsulates alternative is being used. Therefore, the GIST design encapsulates
the routing-dependent details as a message routing method (MRM), and the routing-dependent details as a message routing method (MRM), and
skipping to change at page 12, line 19 skipping to change at page 12, line 18
default case for any MRM is soft-state refresh, but additional default case for any MRM is soft-state refresh, but additional
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 almost certainly In addition, it should be noted that NAT traversal almost certainly
requires transformation of the MRI field in GIST messages (see requires transformation of the MRI field in GIST messages (see
Section 7.2). Although the transformation does not have to be Section 7.2). Although the transformation does not have to be
defined as part of the standard, the impact on existing GIST-aware defined as part of the standard, the impact on existing GIST-aware
NAT implementations should be considered. NAT implementations should be considered.
The MRI is passed explicitly between signaling applications and GIST; The MRI is passed explicitly between signaling applications and GIST;
therefore, NSLP specifications must define which MRMs they require therefore, signaling application specifications must define which
(they may use more than one, e.g. depending on the type of message). MRMs they require (they may use more than one, e.g. depending on the
NSLPs may use fields in the MRI in their packet classifiers; if they type of message). Signaling applications may use fields in the MRI
use additional information for packet classification, this would be in their packet classifiers; if they use additional information for
carried at the NSLP level and so would be invisible to GIST. Any packet classification, this would be carried at the NSLP level and so
node hosting a particular signaling application MUST use a GIST would be invisible to GIST. Any node hosting a particular signaling
implementation that supports the corresponding MRMs. The GIST application MUST use a GIST implementation that supports the
processing rules enforce that nodes which do not host the NSLP are corresponding MRMs. The GIST processing rules enforce that nodes
not forced to handle messages for it at the GIST level, so it does which do not host the signaling application are not forced to handle
not matter if they support the MRM or not. messages for it at the GIST level, so it does not matter if they
support the MRM or not.
3.4. Signaling Sessions 3.4. Signaling Sessions
GIST allows signaling applications to associate each message with a GIST allows signaling applications to associate each message with a
"signaling session". Informally, given an application layer exchange "signaling session". Informally, given an application layer exchange
of information for which some network control state information is to of information for which some network control state information is to
be manipulated or monitored, the corresponding signaling messages be manipulated or monitored, the corresponding signaling messages
should be associated with the same session. Signaling applications should be associated with the same session. Signaling applications
provide the session identifier (SID) whenever they wish to send a provide the session identifier (SID) whenever they wish to send a
message, and GIST reports the SID when a message is received. message, and GIST reports the SID when a message is received.
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 NSLPID. There are several (defined by the MRI, see above) and signaling application (given by
possible relationships between flows and sessions, for example: the NSLPID, see below). There are several possible relationships
between flows and sessions, for example:
o The simplest case is that all messages for the same flow have the o The simplest case is that all messages for the same flow have the
same SID. 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 signaling applications. from independently operating NSLPIDs.
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 signaling applications map between flows and validation on how signaling applications map between flows and
sessions, nor does it perform any validation on the properties of the sessions, nor does it perform any validation on the properties of the
SID itself. In particular, when a new SID is needed, logically it SID itself. In particular, when a new SID is needed, logically it
should be generated by the NSLP. (NSIS implementations could provide should be generated by the signaling application. (NSIS
common functionality to generate SIDs for use by any NSLP, but this implementations could provide common functionality to generate SIDs
is not part of GIST.) GIST only defines the syntax of the SID as an for use by any signaling application, but this is not part of GIST.)
opaque 128-bit number. GIST only defines the syntax of the SID as an opaque 128-bit
identifier.
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 to be delivered reliably between the o Messages with the same SID to be delivered reliably between the
same GIST peers are delivered in order. same GIST peers are delivered in order.
o All other messagse 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, NSLPID, SID). the triplet (MRI, NSLPID, SID).
Strictly, the routing state should not depend on the SID. However, Strictly, the routing state should not depend on the SID. However,
if the routing state is keyed only by (MRI, NSLPID) there is a if the routing state is keyed only by (MRI, NSLPID) there is a
trivial denial of service attack (see Section 8.3) where a malicious trivial denial of service attack (see Section 8.3) where a malicious
off-path node asserts that it is the peer for a particular flow. off-path node asserts that it is the peer for a particular flow.
Instead, the routing state is also segregated between different SIDs, Instead, the routing state is also segregated between different SIDs,
which means that the attacking node can only disrupt a signaling which means that the attacking node can only disrupt a signaling
session if it can guess the corresponding SID. A consequence of this session if it can guess the corresponding SID. A consequence of this
design is that signaling applications should choose SIDs so that they design is that signaling applications should 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 unless strictly necessary, to avoid additional load from same flow unless strictly necessary, to avoid additional load from
routing state maintenance. routing state maintenance.
3.5. Example of Operation 3.5. Signaling Applications and NSLPIDs
The functionality for signaling applications is supported by NSIS
signaling layer protocols (NSLPs). Each NSLP is identified by a 16
bit NSLPID, assigned by IANA (Section 9). A single signaling
application (e.g. "resource reservation") may define a family of
NSLPs to implement its functionality, for example to carry out
signaling operations at different levels in a hierarchy (cf. [15]).
However, the interactions between the different NSLPs (for example,
to relate aggregation levels or aggregation region boundaries in the
resource management case) are handled at the signaling application
level; the NSLPID is the only information visible to GIST about the
signaling application being used.
3.6. 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) signaling scenario, to illustrate its main (in particular, NAT-free) signaling scenario, to illustrate its main
features. features.
Consider the case of an RSVP-like signaling application which Consider the case of an RSVP-like signaling application which
allocates resources for a single unicast flow. We will consider how allocates resources for a single unicast flow. We will consider how
GIST transfers messages between two adjacent peers along the path, GIST transfers messages between two adjacent peers along the path,
GN1 and GN2 (see Figure 1). In this example, the end-to-end exchange GN1 and GN2 (see Figure 1). In this example, the end-to-end exchange
is initiated by the signaling application instance in the sender; we is initiated by the signaling application instance in the sender; we
skipping to change at page 14, line 20 skipping to change at page 14, line 34
on the path that the flow will take. on the path that the flow will take.
2. The message payload is passed to the GIST layer in GN1, along 2. The message payload is passed to the GIST layer in GN1, along
with a definition of the flow and description of the message with a definition of the flow and description of the message
transfer attributes {unsecured, unreliable}. GIST determines transfer attributes {unsecured, unreliable}. GIST determines
that this particular message does not require fragmentation and that this particular message does not require fragmentation and
that it has no knowledge of the next peer for this flow and that it has no knowledge of the next peer for this flow and
signaling application; however, it also determines that this signaling application; however, it also determines that this
application is likely to require secured upstream and downstream application is likely to require secured upstream and downstream
transport of large messages in the future. This determination is transport of large messages in the future. This determination is
a function of node-local policy; see Appendix B for some a function of node-local policy interactions between GIST and the
additional discussion. signaling application.
3. GN1 therefore constructs a GIST-Query message, which is a UDP 3. GN1 therefore constructs a GIST-Query message, a UDP datagram
datagram carrying the signaling application payload and carrying the NSLP payload and additional payloads at the GIST
additional payloads at the GIST level to be used to initiate the level to be used to initiate a messaging association. The Query
setup of a messaging association. The Query is injected into the is injected into the network, addressed towards the flow
network, addressed towards the flow destination and with a Router destination and with a Router Alert Option included.
Alert Option included.
4. The Query message passes through the network towards the flow 4. The Query message passes through the network towards the flow
receiver, and is seen by each router in turn. GIST-unaware receiver, and is seen by each router in turn. GIST-unaware
routers will not recognise the RAO value and will forward the routers will not recognise the RAO value and will forward the
message unchanged; GIST-aware routers which do not support the message unchanged; GIST-aware routers which do not support the
signaling application in question will also forward the message NSLP in question will also forward the message basically
basically unchanged, although they may need to process more of unchanged, although they may need to process more of the message
the message to decide this. to decide this.
5. The message is intercepted at GN2. The GIST layer identifies the 5. The message is intercepted at GN2. The GIST layer identifies the
message as relevant to a local signaling application, and passes message as relevant to a local signaling application, and passes
the signaling application payload and flow description upwards to the NSLP payload and flow description upwards to it. The
it. The signaling application in GN2 indicates to GIST that it signaling application in GN2 indicates to GIST that it will peer
will peer with GN1 and so GIST should proceed to set up any with GN1 and so GIST should proceed to set up any routing state.
routing state. In addition, the signaling application continues In addition, the signaling application continues to process the
to process the message as in GN1 (compare step 1), and this will message as in GN1 (compare step 1), and this will eventually
eventually result in the message reaching the flow receiver. result in the message reaching the flow receiver.
6. In parallel, the GIST instance in GN2 now knows that it should 6. In parallel, the GIST instance in GN2 now knows that it should
maintain routing state and a messaging association for future maintain routing state and a messaging association for future
signaling with GN1. This is recognised because the message is a signaling with GN1. This is recognised because the message is a
GIST-Query, and because the local signaling application has GIST-Query, and because the local signaling application has
indicated that it will peer with GN1. There are two basic indicated that it will peer with GN1. There are two basic
possible cases for sending back the necessary GIST-Response: possible cases for sending back the necessary GIST-Response:
A. GN1 and GN2 already have an appropriate messaging A. GN1 and GN2 already have an appropriate messaging
association. GN2 simply records the identity of GN1 as its association. GN2 simply records the identity of GN1 as its
upstream peer for that flow and signaling application, and upstream peer for that flow and NSLP, and sends a GIST-
sends a GIST-Response back to GN1 over the association Response back to GN1 over the association identifying itself
identifying itself as the peer for this flow. as the peer for this flow.
B. No messaging association exists. GN2 sends the GIST-Response B. No messaging association exists. GN2 sends the GIST-Response
in D mode directly to GN1, identifying itself and agreeing to in D mode directly to GN1, identifying itself and agreeing to
the association setup. The protocol exchanges needed to the association setup. The protocol exchanges needed to
complete this will proceed in the background. complete this will proceed in the background.
7. Eventually, another signaling application message works its way 7. Eventually, another NSLP message works its way upstream from the
upstream from the receiver to GN2. This message contains a receiver to GN2. This message contains a description of the
description of the actual resources requested, along with actual resources requested, along with authorisation and other
authorisation and other security information. The signaling security information. The signaling application in GN2 passes
application in GN2 passes this payload to the GIST level, along this payload to the GIST level, along with the flow definition
with the flow definition and transfer attributes {secured, and transfer attributes {secured, reliable}.
reliable}.
8. The GIST layer in GN2 identifies the upstream peer for this flow 8. The GIST layer in GN2 identifies the upstream peer for this flow
and signaling application as GN1, and determines that it has a and NSLP as GN1, and determines that it has a messaging
messaging association with the appropriate properties. The association with the appropriate properties. The message is
message is queued on the association for transmission (this may queued on the association for transmission (this may mean some
mean some delay if the procedures begun in step 6.B have not yet delay if the procedures begun in step 6.B have not yet
completed). completed).
Further messages can be passed in each direction in the same way. Further messages can be passed in each direction in the same way.
The GIST layer in each node can in parallel carry out maintenance The GIST layer in each node can in parallel carry out maintenance
operations such as route change detection (this can be done by operations such as route change detection (see Section 7.1).
sending additional GIST-Query messages, see Section 7.1 for more
details).
It should be understood that several of these details of GIST It should be understood that several of these details of GIST
operations can be varied, either by local policy or according to operations can be varied, either by local policy or according to
signaling application requirements. The authoritative details are signaling application requirements. The authoritative details are
contained in the remainder of this document. contained in the remainder of this document.
4. GIST Processing Overview 4. GIST Processing Overview
This section defines the basic structure and operation of GIST. This section defines the basic structure and operation of GIST.
Section 4.1 describes the way in which GIST interacts with (local) Section 4.1 describes the way in which GIST interacts with (local)
skipping to change at page 16, line 30 skipping to change at page 16, line 30
This section defines the service interface that GIST presents to This section defines the service interface that GIST presents to
signaling applications in terms of abstract properties of the message signaling applications in terms of abstract properties of the message
transfer. Note that the same service interface is presented at every transfer. Note that the same service interface is presented at every
GIST node; however, applications may invoke it differently at GIST node; however, applications may invoke it differently at
different nodes (e.g. depending on local policy). In addition, the different nodes (e.g. depending on local policy). In addition, the
service interface is defined independently of any specific transport service interface is defined independently of any specific transport
protocol, or even the distinction between datagram and connection protocol, or even the distinction between datagram and connection
mode. The initial version of this specification defines how to mode. The initial version of this specification defines how to
support the service interface using a connection mode based on TCP; support the service interface using a connection mode based on TCP;
if additional transport protocol support is added, this will support if additional protocol support is added, this will support the same
the same interface and so be invisible to applications (except as a interface and so the change will be invisible to applications (except
possible performance improvement). A more detailed description of as a possible performance improvement). A more detailed description
this service interface is given in Appendix B. of this service interface is given in 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 signaling applications: individual messages are service for use by signaling applications: individual messages are
sent, and individual messages are received. At the service sent, and individual messages are received. At the service
interface, the signaling application payload (which is opaque to interface, the NSLP payload (which is opaque to GIST) is accompanied
GIST) is accompanied by control information expressing the by control information expressing the application's requirements
application's requirements about how the message should be routed, about how the message should be routed, and the application also
and the application also provides the session identifier (see provides the session identifier (see Section 3.4). Additional
Section 3.4). Additional message transfer attributes control the message transfer attributes control the specific transport and
specific transport and security properties that the signaling security properties that the signaling application desires for the
application desires for the message. message.
The distinction between GIST connection and datagram modes is not The distinction between GIST connection and datagram modes is not
visible at the service interface. In addition, the invocation of visible at the service interface. In addition, the invocation of
GIST functionality to handle fragmentation and reassembly, bundling GIST functionality to handle fragmentation and reassembly, bundling
together of small messages (for efficiency), and congestion control together of small messages (for efficiency), and congestion control
is not directly visible at the service interface; GIST will take is not directly visible at the service interface; GIST will take
whatever action is necessary based on the properties of the messages whatever action is necessary based on the properties of the messages
and local node state. and local node state.
4.1.2. Message Transfer Attributes 4.1.2. Message Transfer Attributes
skipping to change at page 18, line 24 skipping to change at page 18, line 24
information about how the message is to be routed, the session being information about how the message is to be routed, the session being
signalled for, and the signaling application itself: signalled for, and the signaling application itself:
Message Routing Information (MRI): This defines the method to be used Message Routing Information (MRI): This defines the method to be used
to route the message, the direction in which to send the message, to route the message, the direction in which to send the message,
and any associated addressing information; see Section 3.3. and any associated addressing information; see Section 3.3.
Session Identification (SID): The signaling session with which this Session Identification (SID): The signaling session with which this
message should be associated; see Section 3.4. message should be associated; see Section 3.4.
Signaling Application Identification (NSLPID): This is an IANA NSLP Identification (NSLPID): This is an IANA assigned identifier
assigned identifier of the signaling application which is associated with the NSLP which is generating messages for this
generating messages for this flow. The inclusion of this flow. The inclusion of this identifier allows the routing state
identifier allows the routing state to be different for different to be different for different NSLPs (e.g. because of different
signaling applications (e.g. because of different adjacencies). adjacencies).
The information for a given key consists of the routing state to The information for a given key consists of the routing state to
reach the peer in the direction given by the MRI. For any flow, reach the peer in the direction given by the MRI. For any flow,
their will usually be two entries (for the upstream and downstream there will usually be two entries (for the upstream and downstream
MRI). The routing state includes information about the peer identity MRI). The routing state includes information about the peer identity
(see Section 4.4.2), and a UDP port number (for datagram mode) or a (see Section 4.4.2), and a UDP port number (for datagram mode) or a
reference to one or more messaging associations (for connection reference to one or more messaging associations (for connection
mode). All of this information is learned from prior GIST exchanges. mode). All of this information is learned from prior GIST exchanges.
It is also possible for the state information for either direction to It is also possible for the state information for either direction to
be null. There are several possible cases: be null. There are several possible cases:
o The signaling application has indicated that no messages will o The signaling application has indicated that no messages will
actually be sent in that direction. actually be sent in that direction.
o The node is a flow endpoint, so there can be no signaling peer in o The node is a flow endpoint, so there can be no signaling peer in
one or other direction. one or other direction.
o The node is the endpoint of the signaling path (for example, o The node is the endpoint of the signaling path (for example,
because it is acting as a proxy, or because it has determined because it is acting as a proxy, or because it has determined
explicitly that there are no further signaling nodes in that explicitly that there are no further signaling nodes in that
direction). direction).
o The node can use other techniques to route the message. For o The node is using other techniques to route the message. For
example, it can encapsulate it the same way as a Query message and example, it can encapsulate it the same way as a Query message and
rely on the peer to intercept it. rely on the peer to intercept it.
Each item of routing state has an associated validity timer for how Each item of routing state has an associated validity timer for how
long it can be considered accurate; when this timer expires, it MUST long it can be considered accurate; when this timer expires, it MUST
be purged if it has not been refreshed. Installation and maintenance be purged if it has not been refreshed. Installation and maintenance
of routing state is described in more detail in Section 4.4. of routing state is described in more detail in Section 4.4.
Note also that the routing state is described as a table of flows, Note also that the routing state is described as a table of flows,
but that there is no implied constraint on how the information is but that there is no implied constraint on how the information is
skipping to change at page 19, line 49 skipping to change at page 19, line 49
are not directly visible to GIST, and they do not affect the rest of are not directly visible to GIST, and they do not affect the rest of
the protocol description. the protocol description.
4.3. Basic Message Processing 4.3. Basic Message Processing
This section describes how signaling application messages are This section describes how signaling application messages are
processed in the case where any necessary messaging associations and processed in the case where any necessary messaging associations and
routing state are already in place. The description is divided into routing state are already in place. The description is divided into
several parts. Firstly, message reception, local processing and several parts. Firstly, message reception, local processing and
message transmission are described for the case where the node hosts message transmission are described for the case where the node hosts
the NSLPID in the message. Secondly, the case where the message is the NSLPID identified in the message. Secondly, the case where the
handled directly in the IP or GIST layer (because there is no message is handled directly in the IP or GIST layer (because there is
matching signaling application on the node) is given. An overview is no matching signaling application on the node) is given. An overview
given in Figure 3. is given in Figure 3.
+---------------------------------------------------------+ +---------------------------------------------------------+
| >> Signaling Application Processing >> | | >> Signaling Application Processing >> |
| | | |
+--------^---------------------------------------V--------+ +--------^---------------------------------------V--------+
^ V ^ V
^ NSLP Payloads V ^ NSLP Payloads V
^ V ^ V
+--------^---------------------------------------V--------+ +--------^---------------------------------------V--------+
| >> GIST >> | | >> GIST >> |
skipping to change at page 20, line 37 skipping to change at page 20, line 37
|IP Host | | RAO | alert) level | RAO | |IP Host | |IP Host | | RAO | alert) level | RAO | |IP Host |
|Handling| |Handling| |Handling| |Handling| |Handling| |Handling| |Handling| |Handling|
+--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+ +--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+
x N Q Q N x x N Q Q N x
+--x--N-----------Q--+ +--Q-----------N--x--+ +--x--N-----------Q--+ +--Q-----------N--x--+
| IP Layer | | IP Layer | | IP Layer | | IP Layer |
| (Receive Side) | | (Transmit Side) | | (Receive Side) | | (Transmit Side) |
+--x--N-----------Q--+ +--Q-----------N--x--+ +--x--N-----------Q--+ +--Q-----------N--x--+
x N Q Q N x x N Q Q N x
x N Q Q N x x N Q Q N x
x N Q Q N x
NNNNNNNNNNNNNN = 'Normal' datagram mode messages NNNNNNNNNNNNNN = 'Normal' datagram mode messages
QQQQQQQQQQQQQQ = Datagram mode messages which QQQQQQQQQQQQQQ = Datagram mode messages which
are Queries or likewise encapsulated are Queries or likewise encapsulated
xxxxxxxxxxxxxx = connection mode messages xxxxxxxxxxxxxx = connection mode messages
RAO = Router Alert Option RAO = Router Alert Option
Figure 3: Message Paths through a GIST Node Figure 3: Message Paths through a GIST Node
4.3.1. Message Reception 4.3.1. Message Reception
Messages can be received in connection or datagram mode, and in the Messages can be received in connection or datagram mode, and in the
latter case with two types of message encapsulation. latter case with two types of message encapsulation.
Reception in connection mode is simple: incoming packets undergo the Reception in connection mode is simple: incoming packets undergo the
security and transport treatment associated with the messaging security and transport treatment associated with the messaging
association, and the messaging association provides complete messages association, and the messaging association provides complete messages
to the GIST layer for further processing. Unless the message is to the GIST layer for further processing.
protected by a query/response cookie exchange (see Section 4.4.1) or
has been explicitly routed (see Section 7.1.4), the routing state
table MUST be checked to ensure that this messaging association is
associated with the MRI/NSLPID/SID combination given in the message,
or else a "Incorrectly Delivered Message" error message
(Appendix A.4.4.4) MUST be returned.
Reception in datagram mode depends on the message type. 'Normal' Reception in datagram mode depends on the message type. 'Normal'
messages arrive UDP encapsulated and addressed directly to the messages arrive UDP encapsulated and addressed directly to the
receiving signaling node, at an address and port learned previously. receiving signaling node, at an address and port learned previously.
Each datagram contains a single complete message which is passed to Each datagram contains a single message which is passed to the GIST
the GIST layer for further processing, just as in the connection mode layer for further processing, just as in the connection mode case.
case.
Where GIST is sending messages to be intercepted by the appropriate Where GIST is sending messages to be intercepted by the appropriate
peer rather than directly addressed to it (in particular, Query peer rather than directly addressed to it (in particular, Query
messages), these are UDP encapsulated with an IP router alert option. messages), these are UDP encapsulated with an IP router alert option.
Each signaling node will therefore 'see' all such messages. The case Each signaling node will therefore 'see' all such messages. The case
where the NSLPID does not match a local signaling application at all where the NSLPID does not match a local signaling application at all
is considered below in Section 4.3.4; otherwise, it is again passed is considered below in Section 4.3.4; otherwise, it is again passed
up to the GIST layer for further processing. up to the GIST layer for further processing.
4.3.2. Local Processing 4.3.2. Local Processing and Validation
Once a message has been received, by any method, it is processed Once a message has been received, it is processed locally within the
locally within the GIST layer. The GIST processing to be done GIST layer. The GIST hop count MUST be decremented immediately the
depends on the message type and payloads carried; most of the GIST- message has been received. Further processing depends on the message
internal payloads are associated with state maintenance and are type and payloads carried; most of the GIST payloads are associated
covered in Section 4.4. There is also a hop count to prevent message with state maintenance and details are covered in Section 4.4.
looping and this MUST be decremented immediately the message has been
received.
The remainder of the GIST message consists of an NSLP payload. This In the case of a GIST-Query, there is an interaction with signaling
is delivered locally to the signaling application identified at the application policy to determine which of two courses to follow:
GIST level; the format of the NSLP payload is not constrained by
GIST, and the content is not interpreted.
Even when a message relates to a local signaling application, an 1. The signaling application wishes to become a signaling peer with
adjacency MAY be required based on signaling application policy, and the Querying node. GIST MUST continue with the handshake process
the application of this policy MAY depend on the NSLP payload. to set up message routing state, as described in Section 4.4.1.
Therefore, when this decision has to be made, the NSLP payload is The application MAY provide an NSLP payload for the same NSLPID,
delivered and the signaling application has two options: which GIST will transfer in the GIST-Response.
o to proceed setting up the adjacency. The application MAY provide 2. The signaling application does not wish to set up state with the
an NSLP payload (which will be used in any GIST-Response). Querying node and become its peer. GIST MUST propagate the
Query, similar to the case described in Section 4.3.4. No
message is sent back to the Querying node. The application MAY
provide an updated NSLP payload for the same NSLPID (which will
be used in the Query message forwarded by GIST).
o to bypass the message and drop out of the signaling path. The This interaction with the signaling application, including the
application MAY provide an updated NSLP payload (which will be generation or update of an NSLP payload, SHOULD take place
used in the message which is then forwarded by GIST). synchronously as part of the Query message processing . In terms of
the GIST service interface, this can be implemented by providing
appropriate return values for the primitive that is triggered when
such a message is received; see Appendix B.2 for further discussion.
Signaling applications can generate their messages for transmission, For all other message types, the GIST payloads are processed as
either asynchronously, or in response to an input message, and GIST described in Section 4.4. The remainder of the GIST message consists
can also generate messages autonomously. Regardless of the source, of an NSLP payload, which is delivered locally to the signaling
outgoing messages are passed downwards for message transmission. application identified by the NSLPID. The format of the payload is
not constrained by GIST, and the content is not interpreted.
Delivery is subject to the following validation checks:
o if the message was explicitly routed (see Section 7.1.4) or is a
Data message delivered without routing state (see Section 5.3.2),
the payload is delivered but flagged to the receiving NSLP to
indicate that routing state was not validated;
o else, if there is no routing state for the MRI/SID/NSLPID the
message MUST be rejected with a "No Routing State" error message
(Appendix A.4.4.5);
o else, if the message arrived on an association which is not
associated with the MRI/NSLPID/SID combination given in the
message, the message MUST be rejected with an "Incorrectly
Delivered Message" error message (Appendix A.4.4.4);
o else, the payload is delivered as normal.
4.3.3. Message Transmission 4.3.3. Message Transmission
When a message is available for transmission, GIST uses internal Signaling applications can generate their messages for transmission,
policy and the stored routing state to determine how to handle it. either asynchronously, or in response to a normal input message, and
The following processing applies equally to locally generated GIST can also generate messages autonomously. Regardless of the
messages and messages forwarded from within the GIST or signaling source, outgoing messages are passed downwards for message
application levels. (However, note that special rules apply to the transmission. When a message is available for transmission, GIST
transmission of error messages generated by GIST. These are given in uses internal policy and the stored routing state to determine how to
Section 5.6.) handle it. The following processing applies equally to locally
generated messages and messages forwarded from within the GIST or
signaling application levels. (However, see Section 5.6 for special
rules applying to the transmission of error messages by GIST.)
The main decision is whether the message must be sent in connection The main decision is whether the message must be sent in connection
mode or datagram mode. Reasons for using the former are: mode or datagram mode. Reasons for using the former are:
o NSLP requirements: for example, the signaling application has o signaling application requirements: for example, it has requested
requested channel secured delivery, or reliable delivery; channel secured delivery, or reliable delivery;
o protocol specification: a message that requires fragmentation MUST o protocol specification: a message that requires fragmentation MUST
be sent over a messaging association; be sent over a messaging association;
o local GIST policy: for example, a node MAY prefer to send messages o local policy: for example, a node MAY send messages over a
over a messaging association to benefit from adaptive congestion messaging association to benefit from adaptive congestion control.
control.
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. different transport or security attributes.
If the use of a messaging association is selected, the message is If the use of a messaging association is selected, the message is
queued on the association found from the routing state table, and queued on the association found from the routing state table, and
further output processing is carried out according to the details of further output processing is carried out according to the details of
the protocol stacks used. If no appropriate association exists, the the protocol stacks used. If no appropriate association exists, the
message is queued while one is created (see Section 4.4). If no message is queued while one is created (see Section 4.4.1). If no
association can be created, this is an error condition, and should be association can be created, this is an error condition, and should be
indicated back to the local NSLP. indicated back to the local signaling 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
datagram mode. The processing in this case depends on the message datagram mode. The processing in this case depends on the message
type and whether routing state exists or not. type and whether routing state exists or not.
o If the message is not a Query, and routing state exists, it is UDP o If the message is not a Query, and routing state exists, it is UDP
encapsulated and sent directly to the address from the routing encapsulated and sent directly to the address from the routing
state table. state table.
o If the message is a Query, then it is UDP encapsulated with IP o If the message is a Query, then it is UDP encapsulated with IP
address and router alert option determined from the MRI and NSLPID address and router alert option determined from the MRI and NSLPID
(further details depend on the message routing method). (further details depend on the message routing method).
o If no routing state exists, GIST can attempt to use the same IP/ o If no routing state exists, GIST can attempt to use the same
UDP encapsulation as in the Query case. If this is not possible encapsulation as in the Query case. If this is not possible (e.g.
(e.g. because the encapsulation algorithm for the message routing because the encapsulation for the message routing method is only
method is only defined valid for one message direction), then this defined for one message direction), then this is an error
is an error condition which is reported back to the local NSLP. condition which is reported back to the local signaling
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 signaling application A node may receive messages where it has no signaling 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 Query-encapsulated message contains an RAO value which is 1. A Query-encapsulated message contains an RAO value which is
relevant to NSIS but not to the specific node, but the IP layer relevant to NSIS but not to the specific node, but the IP layer
is unable to recognise whether it needs to be passed to GIST for is unable to recognise whether it needs to be passed to GIST for
further processing or whether the packet should be forwarded just further processing or whether the packet should be forwarded just
like a normal IP datagram. like a normal IP datagram.
2. A Query-encapsulated message contains an RAO value which is 2. A Query-encapsulated message contains an RAO value which is
relevant to the node, but the specific signaling application for relevant to the node, but the specific signaling application
the actual NSLPID in the message is not processed there. functionality for the actual NSLPID in the message is not
processed there.
3. A directly addressed message (in datagram or connection mode) is 3. A directly addressed message (in datagram or connection mode) is
delivered to a node for which there is no corresponding signaling delivered to a node for which there is no corresponding signaling
application. (With the current specification, this should never application. (With the current specification, this should never
happen. While future versions might find a use for such a happen. While future versions might find a use for such a
feature, currently this MUST cause an "Unknown NSLPID" error feature, currently this MUST cause an "Unknown NSLPID" error
message, Appendix A.4.4.6.) message, Appendix A.4.4.6.)
4. A Query-encapsulated message arrives at the end-system which does 4. A Query-encapsulated message arrives at the end-system which does
not handle the NSLP. This is possible in normal operation, and not handle the signaling application. This is possible in normal
MUST be notified to the sender with an "Endpoint Found" operation, and MUST be notified to the sender with an "Endpoint
informational message (Appendix A.4.4.7). The end-system Found" informational message (Appendix A.4.4.7). The end-system
includes the MRI and SID from the original message in the error includes the MRI and SID from the original message in the error
message without interpreting them. message without interpreting them.
5. The node is GIST-aware NAT. See Section 7.2.
In cases (1) and (2), the role of GIST is to forward the message In cases (1) and (2), the role of GIST is to forward the message
essentially unchanged, and it will not become a peer to the node essentially unchanged, and it will not become a peer to the node
sending the message. (Forwarding with modified signaling application sending the message. (Forwarding with modified NSLP payloads is
payloads is covered above in Section 4.3.2.) However, a GIST covered above in Section 4.3.2.) However, a GIST implementation must
implementation must ensure that the IP TTL field and GIST hop count ensure that the IP TTL field and GIST hop count are managed correctly
are managed correctly to prevent message looping, and this should be to prevent message looping, and this should be done consistently
done consistently independently of whether the processing (e.g. for independently of whether the processing (e.g. for case (1)) takes
case (1)) takes place on the fast path or in GIST-specific code. The place on the fast path or in GIST-specific code. The rules are that
rules are that in cases (1) and (2), the IP TTL MUST be decremented in cases (1) and (2), the IP TTL MUST be decremented just as if the
just as if the message was a normal IP forwarded packet; in case (2) message was a normal IP forwarded packet; in case (2) the GIST hop
the GIST hop count MUST be decremented as in the case of normal input count MUST be decremented as in the case of normal input processing,
processing, which indeed applies to cases (3) and (4). which indeed applies to cases (3) and (4).
A GIST node processing Query-encapsulated messages in this way SHOULD A GIST node processing Query-encapsulated messages in this way SHOULD
make the routing decision based on the full contents of the MRI and make the routing decision based on the full contents of the MRI and
not only the IP destination address. It MAY also apply a restricted not only the IP destination address. It MAY also apply a restricted
set of sanity checks and under certain conditions return an error set of sanity checks and under certain conditions return an error
message rather than forwarding the message. These conditions are: message rather than forwarding the message. These conditions are:
1. The message is so large that it would be fragmented on downstream 1. The message is so large that it would be fragmented on downstream
links (e.g. because the downstream MTU is very small). The error links (e.g. because the downstream MTU is very small). The error
"Message Too Large" (Appendix A.4.4.8) SHOULD be returned to the "Message Too Large" (Appendix A.4.4.8) SHOULD be returned to the
sender, which SHOULD begin messaging association setup. sender, which SHOULD begin messaging association setup.
2. The GIST hop count has been exceeded. The error "Hop Limit 2. The GIST hop count has been exceeded. The error "Hop Limit
Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender, Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender,
which MAY retry with a larger initial hop count if it is clear which MAY retry with a larger initial hop count if it is clear
that a loop has not been formed. that a loop has not been formed.
3. The MRI represents a flow definition which is too general to be 3. The MRI represents a flow definition which is too general to be
forwarded along a unique path (e.g. the destination address forwarded along a unique path (e.g. the destination address
prefix is too short). The error "MRI Too Wild" prefix is too short). The error "MRI Validation Failure"
(Appendix A.4.4.12) SHOULD be returned to the sender, which MAY (Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be
retry with restricted MRIs, possibly starting additional returned to the sender, which MAY retry with restricted MRIs,
signaling sessions to do so. If the GIST node does not possibly starting additional signaling sessions to do so. If the
understand the MRM in question it MUST NOT apply this check, GIST node does not understand the MRM in question it MUST NOT
instead forwarding the message transparently. apply this check, instead forwarding the message transparently.
In the first two cases, only the common header is examined; in the In the first two cases, only the common header is examined; in the
third case, the MRI is also examined. The rest of the message MUST third case, the MRI is also examined. The rest of the message MUST
never be inspected or modified. never be inspected or modified.
Note that the hop count is only intended to prevent message looping Note that the hop count is only intended to prevent message looping
at the GIST level, and by default NSLPs must take their own measures at the GIST level, and by default NSLPs must take their own measures
to prevent looping at the application level. However, the GIST API to prevent looping at the application level. However, the GIST API
(Appendix B) allows NSLPs to find the GIST hop count on incoming (Appendix B) provides the incoming hop count to the NSLPs, which can
messages and preserve it in outgoing messages which are being preserve it on outgoing messages as they are forwarded further along
forwarded further along the path. This provides a lightweight loop- the path. This provides a lightweight loop-prevention mechanism for
prevention mechanism for NSLPs which do not define anything more NSLPs which do not define anything more sophisticated.
sophisticated.
4.4. Routing State and Messaging Association Maintenance 4.4. Routing State and Messaging Association Maintenance
The main responsibility of GIST is to manage the routing state and The main responsibility of GIST is to manage the routing state and
messaging associations which are used in the basic message processing messaging associations which are used in the message processing
described above. Routing state is installed and maintained by described above. Routing state is installed and maintained by
specific GIST messages. Messaging associations are dependent on the specific GIST messages. Messaging associations depend on the
existence of routing state, but are actually set up by the normal existence of routing state, but are actually set up by the normal
procedures of the transport and security protocols that comprise procedures of the transport and security protocols that comprise
them. Timers control routing state and messaging association refresh them. Timers control routing state and messaging association refresh
and expiration. and expiration.
There are two different cases for state installation and refresh: There are two different cases for state installation and refresh:
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
skipping to change at page 25, line 35 skipping to change at page 26, line 5
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. State Setup
The complete sequence of possible messages for state setup between The complete sequence of possible messages for state setup between
adjacent peers is shown in Figure 4 and described in detail in the adjacent peers is shown in Figure 4 and described in detail in the
following text. A concrete example is given in Appendix C. following text. A concrete example is given in Appendix C.
The initial message in any routing state maintenance operation is a
GIST-Query message, sent from the querying node and intercepted at
the responding node. This message has addressing and other
identifiers appropriate for the flow and signaling application that
state maintenance is being done for, addressing information about the
node itself, and it MAY contain an NSLP payload. It also includes a
Query Cookie, and optionally capability information about messaging
association protocol stacks. The role of the cookies in this and
subsequent messages is to protect against certain denial of service
attacks and to correlate the various events in the message sequence.
+----------+ +----------+ +----------+ +----------+
| Querying | |Responding| | Querying | |Responding|
| Node | | Node | | Node | | Node |
+----------+ +----------+ +----------+ +----------+
GIST-Query GIST-Query
----------------------> ............. ----------------------> .............
Router Alert Option . Routing . Router Alert Option . Routing .
MRI/SID/NSLPID . state . MRI/SID/NSLPID . state .
Q-Node Network Layer Info . installed . Q-Node Network Layer Info . installed .
Query Cookie . at . Query Cookie . at .
skipping to change at page 26, line 41 skipping to change at page 26, line 41
. at . [Responder Cookie . at . [Responder Cookie
. Q-Node . [R-Node Stack-Proposal . Q-Node . [R-Node Stack-Proposal
............. R-Node Stack-Config-Data]] ............. R-Node 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 .
.................................... ....................................
GIST-Confirm GIST-Confirm
----------------------> ---------------------->
MRI/SID/NSLPID ............. MRI/SID/NSLPID .............
Q-Node Network Layer Info . Routing . Q-Node Network Layer Info . Routing .
[Responder Cookie . state . [Responder Cookie . state .
[R-Node Stack-Proposal]] . installed . [R-Node Stack-Proposal . installed .
[NSLP Payload] . at . [Q-Node Stack-Config-Data]]] . at .
. R-node(2) . [NSLP Payload] . R-node(2) .
............. .............
Figure 4: Message Sequence at State Setup Figure 4: Message Sequence at State Setup
Reception of a GIST-Query MUST elicit a GIST-Response message. This The initial message in any routing state maintenance operation is a
is a 'normally' encapsulated datagram mode message with additional GIST-Query message, sent from the querying node and intercepted at
payloads. It contains network layer information about the responding the responding node. This message has addressing and other
node, echoes the Query Cookie, and MAY contain an NSLP payload identifiers appropriate for the flow and signaling application that
(possibly a response to the NSLP payload in the initial message). In state maintenance is being done for, addressing information about the
case a messaging association was requested, it MUST also contain a node itself, and it MAY contain an NSLP payload. It also includes a
Responder Cookie and its own capability information about messaging Query Cookie, and optionally capability information about messaging
association protocol stacks. Even if a messaging association is not association protocol stacks. The role of the cookies in this and
requested, the Response MAY still include a Responder Cookie if the subsequent messages is to protect against certain denial of service
node's routing state setup policy requires it (see below). attacks and to correlate the various events in the message sequence.
Provided that the signaling application has indicated that message
routing state should be set up (see Section 4.3.2), reception of a
GIST-Query MUST elicit a GIST-Response message. This is a 'normally'
encapsulated datagram mode message with additional payloads. It
contains network layer information about the responding node, echoes
the Query Cookie, and MAY contain an NSLP payload (possibly a
response to the NSLP payload in the initial message). In case a
messaging association was requested, it MUST also contain a Responder
Cookie and its own capability information about messaging association
protocol stacks. Even if a messaging association is not requested,
the Response MAY still include a Responder Cookie if the node's
routing state setup policy requires it (see below).
Setup of a new messaging association begins when peer addressing 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. The setup MUST be contemporaneous with a specific GIST- needed. The setup MUST be contemporaneous with a specific GIST-
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 lifetime NAT bindings, or because it refers to agile destination
ports for the transport protocols). The Stack-Proposal and Stack- ports for the transport protocols). The Stack-Proposal and Stack-
Configuration-Data objects carried in the exchange carry capability Configuration-Data objects carried in the exchange carry capability
information about what messaging association protocols can be used, information about what messaging association protocols can be used,
and the processing of these objects is described in more detail in and the processing of these objects is described in more detail in
Section 5.7. With the protocol options currently defined, setup of Section 5.7. With the protocol options currently defined, setup of
the messaging association always starts from the Querying node, the messaging association always starts from the Querying node,
although more flexible configurations are possible within the overall although more flexible configurations are possible within the overall
GIST design. In any case, once set up the association itself can be GIST design. In any case, once set up the association itself can be
used equally in both directions. used equally in both directions.
Finally, a GIST-Confirm MUST be sent if the GIST-Response requested Finally, a GIST-Confirm MUST be sent if the GIST-Response requested
it. If a messaging association is being used, the GIST-Confirm MUST it. If a messaging association is being used, the GIST-Confirm MUST
be sent over it before any other messages for the same flow, and it be sent over it before any other messages for the same flow, and it
echoes the Responder Cookie and Stack Proposal from the GIST- echoes the Responder Cookie and Stack-Proposal from the GIST-
Response. The former is used to allow the receiver to validate the Response. The former is used to allow the receiver to validate the
contents of the message (see Section 8.5), and the latter is to contents of the message (see Section 8.5), and the latter is to
prevent certain bidding-down attacks on messaging association prevent certain bidding-down attacks on messaging association
security. The association can be used in the upstream direction for security. The Confirm MAY also contain an abbreviated form of the
that flow and NSLPID after the Confirm has been received. original Stack-Configuration-Data to finalise details of the
messaging association configuration. The association can be used in
the upstream direction for that MRI and NSLPID after the Confirm has
been received.
The querying node MUST install the responder address as routing state The querying node MUST install the responder address as routing state
information after verifying the Query Cookie in the GIST-Response. information after verifying the Query Cookie in the GIST-Response.
The responding node MAY install the querying address as peer state The responding node MAY install the querying address as peer state
information at two points in time: information at two points in time:
1. after the receipt of the initial GIST-Query, or 1. after the receipt of the initial GIST-Query, or
2. after a GIST-Confirm message containing the Responder Cookie. 2. after a GIST-Confirm message containing the Responder Cookie.
skipping to change at page 28, line 34 skipping to change at page 29, line 6
continuing with the full procedure. Note that this requirement is continuing with the full procedure. Note that this requirement is
complicated by the fact that NATs may remap the node addresses in complicated by the fact that NATs may remap the node addresses in
D-mode messages, and also interacts with the fact that some nodes may D-mode messages, and also interacts with the fact that some nodes may
peer over multiple interfaces (and so with different addresses). peer over multiple interfaces (and so with different addresses).
Association re-use is controlled by the Network-Layer-Information Association re-use is controlled by the Network-Layer-Information
(NLI) object, which is carried in GIST-Query/Confirm and optionally (NLI) object, which is carried in GIST-Query/Confirm and optionally
GIST-Response messages. The NLI object includes: GIST-Response messages. The NLI object includes:
Peer-Identity: For a given node, this is an interface independent Peer-Identity: For a given node, this is an interface independent
with opaque syntax. It MUST be chosen so as to have a high value with opaque syntax. It MUST be chosen so as to have a high
probability of uniqueness between peers, and SHOULD be stable (at probability of uniqueness between peers, and SHOULD be stable (at
least between restarts). Note that there is no cryptographic least between restarts). Note that there is no cryptographic
protection of this identity (attempting to provide this would protection of this identity (attempting to provide this would
essentially duplicate the functionality in the messaging essentially duplicate the functionality in the messaging
association security protocols). association security protocols).
Interface-Address: This is an IP address through which the signaling Interface-Address: This is an IP address through which the signaling
node can be reached. There may be several choices available for node can be reached. There may be several choices available for
the Interface-Address, and further discussion of this is contained the Interface-Address, and further discussion of this is contained
in Section 5.2.2. in Section 5.2.2.
skipping to change at page 29, line 26 skipping to change at page 29, line 46
o In all other cases, the full handshake MUST be executed in o In all other cases, the full handshake MUST be executed in
datagram mode as usual. There are in fact four possibilities: datagram mode 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.
2. Only the Peer-Identity matches: this may be either a new 2. Only the Peer-Identity matches: this may be either a new
interface on an existing peer, or a changed address mapping interface on an existing peer, or a changed address mapping
behind a NAT, or an attacker attempting to hijack the Peer- behind a NAT, or an attacker attempting to hijack the Peer-
Identity. These should be rare events, so the expense of a Identity. These should be rare events, so the expense of a
new association setup is acceptable. If the authenticated new association setup is acceptable.
peer identities match after association setup, the two
Interface-Addresses MAY be bound to the association.
3. Only the Interface-Address matches: this is probably a new 3. Only the Interface-Address matches: this is probably a new
peer behind the same NAT as an existing one. A new peer behind the same NAT as an existing one. A new
association setup is required. association setup is required.
4. The full NLI object matches: this is a degenerate case, where 4. The full NLI object matches: this is a degenerate case, where
one node recognises an existing peer, but wishes to allow the one node recognises an existing peer, but wishes to allow the
option to set up a new association in any case (for example to option to set up a new association in any case (for example to
create an association with different properties). create an association with different properties).
skipping to change at page 30, line 5 skipping to change at page 30, line 24
Each item of routing state expires after a validity lifetime which is Each item of routing state expires after a validity lifetime which is
negotiated during the Query/Response/Confirm handshake. The NLI negotiated during the Query/Response/Confirm handshake. The NLI
object in the Query contains a proposal for the lifetime value, and object in the Query contains a proposal for the lifetime value, and
the NLI in the Response contains the value the Responding node the NLI in the Response contains the value the Responding node
requires. The Querying node MUST generate a GIST-Query message requires. The Querying node MUST generate a GIST-Query message
before this timer expires, if it believes that the flow is still before this timer expires, if it believes that the flow is still
active; otherwise, the Responding node MAY delete the state. Receipt active; otherwise, the Responding node MAY delete the state. Receipt
of the message at the Responding node will refresh peer addressing of the message at the Responding node will refresh peer addressing
state for one direction, and receipt of a GIST-Response at the state for one direction, and receipt of a GIST-Response at the
querying node will refresh it for the other. There is no mechanism querying node will refresh it for the other. There is no mechanism
at the GIST level for explicit teardown of routing state. at the GIST level for explicit teardown of routing state. However,
GIST MUST NOT refresh routing state if a flow is known to be
inactive, either because upstream state has expired, or because the
signaling application has indicated via the GIST API (Appendix B.5)
that the state is no longer required, because this would prevent
correct state repair in the case of network rerouting.
Unneeded messaging associations are torn down by GIST, using the Unneeded messaging associations are torn down by GIST, using the
teardown mechanisms of the underlying transport or security protocols teardown mechanisms of the underlying transport or security protocols
if available (for example, simply by closing a TCP connection). The if available (for example, simply by closing a TCP connection). The
teardown can be initiated by either end. Whether an association is teardown can be initiated by either end. Whether an association is
needed is a combination of two factors: needed is a combination of 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 association in place. During o whether the peer still wants the association in place. During
messaging association setup, each node indicates its own MA-hold- messaging association setup, each node indicates its own MA-Hold-
time as part of the Stack-Configuration-Data; the node MUST not Time as part of the Stack-Configuration-Data. (Because the
tear down the association if it has received traffic from its peer Responding node can choose not to retain state until a Confirm
over that period. A peer which has generated no traffic but still message, an abbreviated Stack-Configuration-Data object containing
wants the association retained SHOULD use a special 'null' message just this information MUST be repeated by the Querying node in the
(GIST-MA-Hello) to indicate the fact. first Confirm sent on a new messaging association.) A node MUST
NOT tear down the association if it has received traffic from its
peer over that period. A peer which has generated no traffic but
still wants the association retained SHOULD use a special 'null'
message (GIST-MA-Hello) to indicate the fact.
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
layer. Therefore, even if GIST tears down and later re-establishes a layer. Therefore, even if GIST tears down and later re-establishes a
messaging association, signaling applications cannot distinguish this messaging association, signaling applications cannot distinguish this
from the case where the association is kept permanently open. To from the case where the association is kept permanently open. To
maintain the transport semantics described in Section 4.1, GIST MUST maintain the transport semantics described in Section 4.1, GIST MUST
close transport connections carrying reliable messages gracefully or close transport connections carrying reliable messages gracefully or
report an error condition, and MUST NOT open a new association for a report an error condition, and MUST NOT open a new association for a
given session and peer while messages on a previous association may given session and peer while messages on a previous association may
still be outstanding. still be outstanding.
This specification defines precisely only the time at which state or
messaging associations expire; it does not define when refresh
transactions should be initiated. Implementations SHOULD select
timer settings which take at least the following into account:
o The transmission latency between source and destination;
o The need for retransmissions (either explicitly or within the
messaging association protocols);
o The need to avoid network synchronisation of control traffic (cf.
[34]).
In most cases, a reasonable policy is (for example) to initiate the
refresh process when between 1/2 and 3/4 of the appropriate validity
time has elapsed since the last successful refresh. The actual
moment is chosen randomly within this interval to avoid
synchronisation effects.
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
possible GIST messages and their contents at a high level; a more various GIST messages and their contents at a high level; a more
detailed description of the header and each object is given in detailed description of the header and each object is given in
Section 5.2. Section 5.2.
The common header includes a version number, message type and size, The common header includes a version number, message type and size,
and signaling application ID. It also carries a hop count to prevent and NSLPID. It also carries a hop count to prevent message looping
message looping and a R (Reply) flag to indicate if a reply of some and various control flags, including one to indicate if a reply of
sort is requested. The objects following the common header MUST be some sort is requested. The objects following the common header MUST
carried in a fixed order, depending on message type. Messages with be carried in a fixed order, depending on message type. Messages
missing, duplicate or invalid objects for the message type MUST be with missing, duplicate or invalid objects for the message type MUST
rejected with a "Object Type Error" error message with the be rejected with an "Object Type Error" error message with the
appropriate subcode (Appendix A.4.4.9). appropriate subcode (Appendix A.4.4.9).
The following gives the basic syntax of GIST messages in ABNF [3]. The following gives the basic syntax of GIST messages in ABNF [7].
Note that the NAT traversal mechanism for GIST involves the insertion Note that the NAT traversal mechanism for GIST involves the insertion
of an additional NAT-Traversal object in certain messages; the rules of an additional NAT-Traversal object in certain messages; the rules
for this are given in Section 7.2. for this are given in Section 7.2.
GIST-Message: The main messages are either one of the stages in the GIST-Message: The main messages are either one of the stages in the
3-way handshake, or a simple message carrying NSLP data. Additional 3-way handshake, or a simple message carrying NSLP data. Additional
types are allocated for errors and messaging association keepalive. types are allocated for errors and messaging association keepalive.
GIST-Message = GIST-Query / GIST-Response / GIST-Message = GIST-Query / GIST-Response /
GIST-Confirm / GIST-Data / GIST-Confirm / GIST-Data /
skipping to change at page 32, line 5 skipping to change at page 33, line 5
GIST-Query = Common-Header GIST-Query = Common-Header
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 ]
GIST-Response: A GIST-Response may be sent in datagram or connection GIST-Response: A GIST-Response may be sent in datagram or connection
mode (if a messaging association is being re-used). It MUST echo the mode (if a messaging association is being re-used). It MUST echo the
MRI (with inverted D flag), SID and Query-Cookie of the Query, and in MRI (with inverted direction), SID and Query-Cookie of the Query, and
D-mode carries its own Network-Layer-Information; if the message in D-mode carries its own Network-Layer-Information; if the message
exchange relates to setup of a messaging association (which can only exchange relates to setup of a messaging association (which can only
take place in datagram mode), a Responder cookie MUST be included, as take place in datagram mode), a Responder cookie MUST be included, as
well as its own stack proposal and configuration data. The R flag well as its own stack proposal and configuration data. The R flag
MUST be set (R=1) if a Responder cookie is present but otherwise is MUST be set (R=1) if a Responder cookie is present but otherwise is
optional; the R flag controls whether a Confirm is sent. optional; if the R flag is set, a Confirm MUST be sent as a reply.
GIST-Response = Common-Header GIST-Response = Common-Header
Message-Routing-Information Message-Routing-Information
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 ]
GIST-Confirm: A GIST-Confirm may be sent in datagram or connection GIST-Confirm: A GIST-Confirm may be sent in datagram or connection
mode (if a messaging association has been re-used). It MUST echo the mode (if a messaging association has been re-used). It MUST echo the
MRI (with inverted D flag), SID, and Responder-Cookie if the Response MRI (with inverted direction), SID, and Responder-Cookie if the
carried one; if the message exchange relates to setup of a new Response carried one; if the message exchange relates to setup of a
messaging association or reuse of an existing one (which can only new messaging association or reuse of an existing one (which can only
take place in connection mode), the message MUST also echo the Stack- take place in connection mode), the message MUST also echo the Stack-
Proposal from the GIST-Response so it can be verified that this has Proposal from the GIST-Response so it can be verified that this has
not been tampered with. not been tampered with. The first message on an association MUST
also repeat the Stack-Configuration-Data from the original Query in
an abbreviated form (just containing the MA-Hold-Time).
GIST-Confirm = Common-Header GIST-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
[ Stack-Configuration-Data ] ] ]
[ NSLP-Data ] [ NSLP-Data ]
GIST-Data: A plain data message contains no control objects, but only GIST-Data: A plain data message contains no control objects, but only
the MRI and SID associated with the NSLP data being transferred. the MRI and SID associated with the NSLP data being transferred.
Network-Layer-Information MUST be carried in the datagram mode case Network-Layer-Information MUST be carried in the datagram mode case
and not otherwise. and not otherwise.
GIST-Data = Common-Header GIST-Data = Common-Header
Message-Routing-Information Message-Routing-Information
Session-Identification Session-Identification
skipping to change at page 33, line 26 skipping to change at page 34, line 29
only the common header, with a null NSLPID. The R flag MAY be set only the common header, with a null NSLPID. The R flag MAY be set
(R=1) to indicate that a reply is requested, thus allowing a node to (R=1) to indicate that a reply is requested, thus allowing a node to
test the liveness of the peer. test the liveness of the peer.
GIST-MA-Hello = Common-Header GIST-MA-Hello = Common-Header
5.2. Information Elements 5.2. Information Elements
This section describes the content of the various objects that can be This section describes the content of the various objects that can be
present in each GIST message, both the common header, and the present in each GIST message, both the common header, and the
individual TLVs. The bit patterns are provided in Appendix A. individual TLVs. The bit formats are provided in Appendix A.
5.2.1. The Common Header 5.2.1. The Common Header
Each message begins with a fixed format common header, which contains Each message begins with a fixed format common header, which contains
the following information: the following information:
Version: The version number of the GIST protocol. Version: The version number of the GIST protocol.
Length: The number of 32 bit words in the message following the Length: The number of 32 bit words in the message following the
common header. common header.
Signaling application identifier (NSLPID): This describes the Upper layer identifier (NSLPID): This gives the specific NSLP that
specific signaling application, such as resource reservation or this message is used for.
firewall control.
GIST hop counter: A hop counter to prevent a message from looping. GIST hop counter: A hop counter to prevent a message from looping.
Message type: The message type (Query, Response, etc.) Message type: The message type (Query, Response, etc.)
Source addressing mode: If set (S=1), this indicates that the IP Source addressing mode: If set (S=1), this indicates that the IP
source address of the message is the same as the signaling source source address of the message is the same as the signaling source
address, in which case replies to this message can be sent safely address, in which case replies to this message can be sent safely
to this address. It is cleared (S=0) if the IP source address was to this address. It is cleared (S=0) if the IP source address was
derived from the message routing information in the payload and derived from the message routing information in the payload and
skipping to change at page 35, line 49 skipping to change at page 37, line 4
the one stored with the routing state for that flow, after it has the one stored with the routing state for that flow, after it has
been updated (if appropriate) from processing the message in been updated (if appropriate) from processing the message in
question. question.
Stack-Proposal: This field contains information about which Stack-Proposal: This field contains information about which
combinations of transport and security protocols are available for combinations of transport and security protocols are available for
use in messaging associations, and is also discussed further in use in messaging associations, and is also discussed further in
Section 5.7. Section 5.7.
Stack-Proposal = 1*stack-profile Stack-Proposal = 1*stack-profile
stack-profile = 1*protocol-layer stack-profile = 1*protocol-layer
Each protocol-layer field identifies a protocol with a unique tag; Each protocol-layer field identifies a protocol with a unique tag;
any address-related (mutable) information associated with the any additional data (e.g. higher-layer addressing or other options
protocol will be carried in a higher-layer-addressing field in the data) associated with the protocol will be carried in a MA-
Stack-Configuration-Data TLV (see below). protocol-options field in the Stack-Configuration-Data TLV (see
below).
Stack-Configuration-Data: This object carries information about the Stack-Configuration-Data: This object carries information about the
overall configuration of a messaging association. overall configuration of a messaging association.
Stack-Configuration-Data = MA-hold-time Stack-Configuration-Data = MA-Hold-Time
0*higher-layer-addressing 0*MA-protocol-options
The MA-hold-time field indicates how long a node will hold open an The MA-Hold-Time field indicates how long a node will hold open an
inactive association; see Section 4.4.3 for more discussion. The inactive association; see Section 4.4.3 for more discussion. The
higher-layer-addressing fields give the configuration of the MA-protocol-options fields give the configuration of the protocols
protocols to be used for new messaging associations, and they are to be used for new messaging associations, and they are described
described in more detail in Section 5.7. in more detail in Section 5.7.
Query-Cookie/Responder-Cookie: A Query-Cookie is contained in a GIST- Query-Cookie/Responder-Cookie: A Query-Cookie is contained in a GIST-
Query message and MUST be echoed in a GIST-Response; a Response- Query message and MUST be echoed in a GIST-Response; a Responder-
Cookie MAY be sent in a GIST-Response message, and if present MUST Cookie MAY be sent in a GIST-Response message, and if present MUST
be echoed in the following GIST-Confirm message. Cookies are be echoed in the following GIST-Confirm message. Cookies are
variable length (chosen by the cookie generator). See Section 8.5 variable length (chosen by the cookie generator). See Section 8.5
for further details on requirements and mechanisms for cookie for further details on requirements and mechanisms for cookie
generation. generation.
NSLP-Data: The NSLP payload to be delivered to the signaling NSLP-Data: The NSLP payload to be delivered to the signaling
application. GIST does not interpret the payload content. application. GIST does not interpret the payload content.
GIST-Error-Data: This contains all the information to determine the GIST-Error-Data: This contains all the information to determine the
skipping to change at page 37, line 42 skipping to change at page 38, line 44
5.3.2. Query Encapsulation 5.3.2. Query Encapsulation
Query encapsulation MUST be used for messages where no routing state Query 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 GIST-Query messages. Query encapsulation is similar particular for GIST-Query messages. Query encapsulation is similar
to normal encapsulation, with changes in IP address selection, IP to normal encapsulation, with changes in IP address selection, IP
options, and a defined method for selecting UDP ports. options, and a defined method for selecting UDP ports.
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 message routing method. In addition, the exact rules depend on the message routing method. In addition,
the IP header is given a Router Alert Option to assist the peer in the IP header is given a Router Alert Option ([1] and [4]) to assist
intercepting the message depending on the NSLPID. Each NSLPID the peer in intercepting the message depending on the NSLPID. Each
corresponds to a unique RAO value, but not necessarily vice versa; NSLPID corresponds to a unique RAO value, but not necessarily vice
further details are discussed in [36]. versa; further details are discussed in [36].
The source UDP port is selected by the message sender as the port at The source UDP port is selected by the message sender as the port at
which it is prepared to receive UDP messages in reply, and a which it is prepared to receive UDP messages in reply, and a
destination UDP port is allocated by IANA (see Section 9). Note that destination UDP port is allocated by IANA (see Section 9). Note that
GIST may send messages addressed as {flow sender, flow receiver} GIST may send messages addressed as {flow sender, flow receiver}
which could make their way to the flow receiver even if that receiver which could make their way to the flow receiver even if that receiver
were GIST-unaware. These should be rejected (with an ICMP message) were GIST-unaware. These should be rejected (with an ICMP message)
rather than delivered to the user application (which would be unable rather than delivered to the user application (which would be unable
to use the source address to identify it as not being part of the to use the source address to identify it as not being part of the
normal data flow). Therefore, a "well-known" port is required. normal data flow). Therefore, a "well-known" port is required.
skipping to change at page 38, line 22 skipping to change at page 39, line 25
reliability should be serviced using C-mode, which should also carry reliability should be serviced using C-mode, which should also carry
the bulk of signaling traffic. However, some form of messaging the bulk of signaling traffic. However, some form of messaging
reliability is required for the GIST control messages themselves, as reliability is required for the GIST control messages themselves, as
is rate control to handle retransmissions and also bursts of is rate control to handle retransmissions and also bursts of
unreliable signaling or state setup requests from the signaling unreliable signaling or state setup requests from the signaling
applications. 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, with an retransmissions MUST use a binary exponential backoff, with an
initial timeout of T1 up to a maximum of T2 seconds. Retransmitted initial timeout of T1 up to a maximum of T2 seconds. Retransmitted
Queries MUST use different Query-Cookie values. The values of T1 and Queries MUST use different Query-Cookie values. These rules apply
T2 are implementation defined. Note that Queries may go unanswered equally to the message that first creates routing state, and those
either because of message loss (in either direction), or because that refresh it. The values of T1 and T2 are implementation defined.
there is no reachable GIST peer. Therefore, implementations should Note that Queries may go unanswered either because of message loss
trade off reliability (large T2) against promptness of error feedback (in either direction), or because there is no reachable GIST peer.
to applications (small T2). If either message carries NSLP data, it Therefore, implementations should trade off reliability (large T2)
may be delivered multiple times to the signaling application. against promptness of error feedback to applications (small T2). If
the Query message carries NSLP data, it may be delivered multiple
times to the signaling application. If the NSLP has indicated a
timeout on the validity of this payload (see Appendix B.1), T2 SHOULD
be chosen to be less than this value.
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. Notionally, we can The case of a lost Confirm is more subtle. Notionally, we can
distinguish between two cases: distinguish between two cases:
1. Where the Responding node is already prepared to store per-flow 1. Where the Responding node is already prepared to store per-flow
state after receiving a single (Query) message. This would state after receiving a single (Query) message. This would
include any cases where the node has NSLP data queued to send. include any cases where the node has NSLP data queued to send.
Here, the Responding node MAY run a retransmission timer to Here, the Responding node MAY run a retransmission timer to
resend the Response message until a Confirm is received, since resend the Response message until a Confirm is received, since
skipping to change at page 39, line 34 skipping to change at page 40, line 41
The basic rate-control requirements for datagram mode traffic are The basic rate-control requirements for datagram 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 (for all interfaces and message types). It applies to
retransmissions as well as new messages, although an implementation retransmissions as well as new messages, although an implementation
MAY choose to prioritise one over the other. When the rate limiter MAY choose to prioritise one over the other. When the rate limiter
is in effect, datagram mode messages are queued until transmission is is in effect, datagram mode messages are queued until transmission is
re-enabled, or an error condition MAY be indicated back to local re-enabled, or an error condition MAY be indicated back to local
signaling applications. The rate limiting mechanism is signaling applications. The rate limiting mechanism is
implementation defined, but it is RECOMMENDED that a token bucket implementation defined, but it is RECOMMENDED that a token bucket
limiter as described in [27] be used. limiter as described in [26] be used.
5.4. Connection Mode Transport 5.4. Connection Mode Transport
Encapsulation in connection mode is more complex, because of the Encapsulation in connection mode is more complex, because of the
variation in available transport functionality. This issue is variation in available transport functionality. This issue is
treated in Section 5.4.1. The actual encapsulation is given in treated in Section 5.4.1. The actual encapsulation is given in
Section 5.4.2. Section 5.4.2.
5.4.1. Choice of Transport Protocol 5.4.1. Choice of Transport Protocol
It is a general requirement of the NTLP defined in [24] that it It is a general requirement of the NTLP defined in [22] that it
should be able to support bundling (of small messages), fragmentation should be able to support bundling (of small messages), fragmentation
(of large messages), and message boundary delineation. Not all (of large messages), and message boundary delineation. Not all
transport protocols natively support all these features. transport protocols natively support all these features.
TCP provides both bundling and fragmentation, but not message TCP provides both bundling and fragmentation, but not message
boundaries. However, the length information in the common header boundaries. However, the length information in the common header
allows the message boundary to be discovered during parsing. allows the message boundary to be discovered during parsing.
SCTP [14] satisfies all requirements. SCTP [12] satisfies all requirements.
DCCP [26] is message based but does not provide bundling or DCCP [25] is message based but does not provide bundling or
fragmentation. Bundling can be carried out by the GIST layer fragmentation. Bundling can be carried out by the GIST layer
sending multiple messages in a single datagram; because the common sending multiple messages in a single datagram; because the common
header includes length information, the message boundaries within header includes length information, the message boundaries within
the datagram can be discovered during parsing. Fragmentation of the datagram can be discovered during parsing. Fragmentation of
GIST messages over multiple datagrams should be avoided, because GIST messages over multiple datagrams should be avoided, because
of amplification of message loss rates that this would cause. of amplification of message loss rates that this would cause.
The bundling together of small messages is either built into the The bundling together of small messages is either built into the
transport protocol or can be carried out by the GIST layer during transport protocol or can be carried out by the GIST layer during
message construction. Either way, two approaches can be message construction. Either way, two approaches can be
skipping to change at page 41, line 34 skipping to change at page 42, line 40
. message boundary . . . . security . message boundary . . . . security
. . V V V mechanism . . V V V mechanism
. . V V V in use) . . V V V in use)
Figure 5: Connection Mode Encapsulation Figure 5: Connection Mode Encapsulation
5.5. Message Type/Encapsulation Relationships 5.5. Message Type/Encapsulation Relationships
GIST has four primary message types (Query/Response/Confirm/Data) and GIST has four primary message types (Query/Response/Confirm/Data) and
three possible encapsulation methods (D-Mode Normal/D-Mode Query/ three possible encapsulation methods (D-Mode Normal/D-Mode Query/
C-Mode). For information, the allowed combinations of message type C-Mode). For information, the possible combinations of message type
and encapsulation are given in the table below. If a message arrives and encapsulation are given in the table below. In some cases there
with an invalid encapsulation (e.g. a Query arrives over a messaging are several possible choices, depending on the existence of routing
association), this MUST be rejected with an "Incorrect Encapsulation" state or messaging associations. The rules governing GIST policy,
error message (Appendix A.4.4.3). However, it should be noted that including whether or not to create such state to handle a message,
the processing of the message at the receiver is not otherwise are described normatively in the other sections of this
affected by the encapsulation method used, with the exception that specification. If a message arrives with an invalid encapsulation
the decapsulation process may provide additional information (e.g. (e.g. a Query arrives over a messaging association), this MUST be
translated addresses or IP hop count) which is used in the subsequent rejected with an "Incorrect Encapsulation" error message
message processing. (Appendix A.4.4.3). However, it should be noted that the processing
of the message at the receiver is not otherwise affected by the
encapsulation method used, with the exception that the decapsulation
process may provide additional information (e.g. translated addresses
or IP hop count) which is used in the subsequent message processing.
+---------------+----------------+-------------------+--------------+ +---------------+---------------+-------------------+---------------+
| Message | D-Mode Normal | D-Mode Query | C-Mode | | Message | D-Mode Normal | D-Mode Query | C-Mode |
+---------------+----------------+-------------------+--------------+ +---------------+---------------+-------------------+---------------+
| GIST-Query | Never | Always | Never | | GIST-Query | Never | Always | Never |
| | | | | | | | | |
| GIST-Response | Unless a | Never | If a | | GIST-Response | Unless a | Never | If a |
| | messaging | | messaging | | | messaging | | messaging |
| | association is | | association | | | association | | association |
| | being re-used | | is being | | | is being | | is being |
| | | | re-used | | | re-used | | re-used |
| | | | | | | | | |
| GIST-Confirm | Unless a | Never | If a | | GIST-Confirm | Unless a | Never | If a |
| | messaging | | messaging | | | messaging | | messaging |
| | association | | association | | | association | | association |
| | has been set | | has been set | | | has been set | | has been set |
| | up or is being | | up or is | | | up or is | | up or is |
| | re-used | | being | | | being re-used | | being re-used |
| | | | re-used | | | | | |
| | | | | | GIST-Data | If routing | If no routing | If a |
| GIST-Data | If routing | If no routing | If a | | | state exists | state exists and | messaging |
| | state exists | state exists and | messaging | | | for the flow | the MRI can be | association |
| | for the flow | the MRI can be | association | | | but no | used to derive | exists |
| | but no | used to derive | exists | | | messaging | the query | |
| | appropriate | the query | | | | association | encapsulation | |
| | messaging | encapsulation | | +---------------+---------------+-------------------+---------------+
| | association | | |
+---------------+----------------+-------------------+--------------+
5.6. Error Message Processing 5.6. Error Message Processing
Special rules apply to the encapsulation and transmission of error Special rules apply to the encapsulation and transmission of error
messages. messages.
GIST only generates error messages in response to incoming messages. GIST only generates error messages in response to incoming messages.
(Error messages MUST NOT be generated in response to incoming error (Error messages MUST NOT be generated in response to incoming error
messages.) The routing and encapsulation of the error message is messages.) The routing and encapsulation of the error message is
derived from that of the message that caused the error; in derived from that of the message that caused the error; in
skipping to change at page 43, line 25 skipping to change at page 44, line 25
5.7.1. Overview 5.7.1. Overview
A key attribute of GIST is that it is flexible in its ability to use A key attribute of GIST is that it is flexible in its ability to use
existing transport and security protocols. Different transport existing transport and security protocols. Different transport
protocols may have performance attributes appropriate to different protocols may have performance attributes appropriate to different
environments; different security protocols may fit appropriately with environments; different security protocols may fit appropriately with
different authentication infrastructures. Even given an initial different authentication infrastructures. Even given an initial
default mandatory protocol set for GIST, the need to support new default mandatory protocol set for GIST, the need to support new
protocols in the future cannot be ruled out, and secure feature protocols in the future cannot be ruled out, and secure feature
negotation cannot be added to an existing protocol in a backwards- negotiation cannot be added to an existing protocol in a backwards-
compatible way. Therefore, some sort of capability discovery is compatible way. Therefore, some sort of capability discovery is
required. required.
Capability discovery is carried out in GIST-Query/Response messages, Capability discovery is carried out in GIST-Query/Response messages,
using Stack-Proposal and Stack-Configuration-Data objects. If a new using Stack-Proposal and Stack-Configuration-Data objects. If a new
messaging association is required it is then set up, followed by a messaging association is required it is then set up, followed by a
GIST-Confirm. Messaging association re-use is achieved by short- GIST-Confirm. Messaging association re-use is achieved by short-
circuiting this exchange by sending the GIST-Response or GIST-Confirm circuiting this exchange by sending the GIST-Response or GIST-Confirm
messages on an existing association (Section 4.4.2); whether to do messages on an existing association (Section 4.4.2); whether to do
this is a matter of local policy. The end result of this process is this is a matter of local policy. The end result of this process is
a messaging association which is a stack of protocols. If multiple a messaging association which is a stack of protocols. If multiple
associations exist, it is a matter of local policy how to distribute associations exist, it is a matter of local policy how to distribute
messages over them, subject to respecting the transfer attributes messages over them, subject to respecting the transfer attributes
requested for each message. requested for each message.
Every possible protocol for a messaging association has the following Every possible protocol for a messaging association has the following
attributes: attributes:
o MA-Protocol-ID, a 1-byte IANA assigned value. o MA-Protocol-ID, a 1-byte IANA assigned value (see Section 9).
o A specification of the (non-negotiable) policies about how the o A specification of the (non-negotiable) policies about how the
protocol should be used (for example, in which direction a protocol should be used (for example, in which direction a
connection should be opened). connection should be opened).
o Optionally, formats for carrying the protocol addressing and other o [Depending on the specific protocol:] Formats for an MA-protocol-
configuration information in higher-layer-addressing information options field to carry the protocol addressing and other
elements in the Stack-Configuration-Data object. (Some protocols configuration information in the Stack-Configuration-Data object.
do not require such higher-layer-addressing information.) There The format may differ depending on whether the field is present in
are different formats depending on whether the information is the Query or Response. Some protocols do not require the
carried in the Query or Response. definition of such additional data, in which case no corresponding
MA-protocol-options field will occur in the SCD object.
A Stack-Proposal object is simply a list of profiles; each profile is A Stack-Proposal object is simply a list of profiles; each profile is
a sequence of MA-Protocol-IDs. A Stack-Proposal is generally a sequence of MA-Protocol-IDs. A profile lists the protocols in 'top
accompanied by a Stack-Configuration-Data object which can carry to bottom' order (e.g. TLS over TCP, or TCP over IPsec, etc.) A
higher-layer-addressing information elements for any protocol listed Stack-Proposal is generally accompanied by a Stack-Configuration-Data
in the Stack-Proposal which needs it. A higher-layer-addressing object which carries an MA-protocol-options field for any protocol
information element may apply globally (to all instances of the listed in the Stack-Proposal which needs it. An MA-protocol-options
protocol in the Stack-Proposal) or be tagged as applying to a field may apply globally (to all instances of the protocol in the
specific instance; for example, this can be used to carry different Stack-Proposal) or be tagged as applying to a specific instance; for
port numbers for TCP depending on whether it is to be used with or example, this can be used to carry different port numbers for TCP
without TLS. A higher-layer-addressing information element may also depending on whether it is to be used with or without TLS. An MA-
be flagged as 'not usable'; for example, a NAT which could not handle protocol-options field may also be flagged as 'not usable'; for
SCTP would set this in higher-layer-addressing about SCTP. A example, a NAT which could not handle SCTP would set this in an MA-
protocol flagged this way MUST NOT be used for a messaging protocol-options field about SCTP. A protocol flagged this way MUST
association. If the Stack-Proposal and Stack-Configuration-Data are NOT be used for a messaging association. If the Stack-Proposal and
both present but not consistent (e.g. they refer to different Stack-Configuration-Data are both present but not consistent (e.g.
protocols, or a higher-layer-addressing element refers to a non- they refer to different protocols, or an MA-protocol-options field
existent profile), a "Object Value Error" error message refers to a non-existent profile), an "Object Value Error" error
(Appendix A.4.4.10) with subcode 5 ("SP-SCD Mismatch") MUST be message (Appendix A.4.4.10) with subcode 5 ("SP-SCD Mismatch") MUST
returned and the message dropped. be returned and the message dropped.
A node generating a Stack-Configuration-Data object MUST honour the A node generating a Stack-Configuration-Data object MUST honour the
implied protocol configurations for the period during which a implied protocol configurations for the period during which a
messaging association might be set up; in particular, it MUST be messaging association might be set up; in particular, it MUST be
immediately prepared to accept incoming datagrams or connections at immediately prepared to accept incoming datagrams or connections at
the protocol/port combinations advertised. However, the object the protocol/port combinations advertised. However, the object
contents MUST be retained only for the duration of the Query/Response contents MUST be retained only for the duration of the Query/Response
exchange and any following association setup, and afterwards exchange and any following association setup, and afterwards
discarded. (They may become invalid because of expired bindings at discarded. (They may become invalid because of expired bindings at
intermediate NATs, or because the advertising node is using agile intermediate NATs, or because the advertising node is using agile
ports.) ports.)
A GIST-Query requesting association setup always contains a Stack- A GIST-Query requesting association setup always contains a Stack-
Proposal and Stack-Configuration-Data object, and unless re-use Proposal and Stack-Configuration-Data object, and unless re-use
occurs, the GIST-Response does so also. For a GIST-Response, the occurs, the GIST-Response does so also. For a GIST-Response, the
Stack-Proposal MUST be invariant for the combination of outgoing Stack-Proposal MUST NOT depend on the GIST-Query. A node MAY make
interface and NSLPID (it MUST NOT depend on the GIST-Query). Once different proposals depending on the combination of interface and
the messaging association is set up, the querying node repeats the NSLPID. Once the messaging association is set up, the querying node
responder's Stack-Proposal over it in the GIST-Confirm. The repeats the responder's Stack-Proposal over it in the GIST-Confirm.
responding node MUST verify this to ensure that no bidding-down The responding node MUST verify this to ensure that no bidding-down
attack has occurred. attack has occurred; see Section 8.6 for further discussion.
5.7.2. Protocol Definition: Forwards-TCP 5.7.2. Protocol Definition: Forwards-TCP
This defines a basic configuration for the use of TCP between peers. This MA-Protocol-ID denotes a basic use of TCP between peers.
Support for this protocol is REQUIRED; associations using it can Support for this protocol is REQUIRED; associations using it can
carry messages with the transfer attribute Reliable=True. The carry messages with the transfer attribute Reliable=True. The
connection is opened in the forwards direction, from the querying connection is opened in the forwards direction, from the querying
node, towards the responder at a previously advertised port. The node, towards the responder at a previously advertised port. If this
higher-layer-addressing formats are: protocol is offered, MA-protocol-options data MUST also be carried in
the SCD object. The MA-protocol-options field formats are:
o downstream: no information (only padding). o in a Query: no information apart from the field header.
o upstream: 2 byte port number at which the connection will be o in a Response: 2 byte port number at which the connection will be
accepted. accepted, followed by 2 pad bytes.
5.7.3. Protocol Definition: Transport Layer Security 5.7.3. Protocol Definition: Transport Layer Security
This defines the use of transport layer security as a basic channel This MA-Protocol-ID denotes a basic use of transport layer channel
security mechanism. Support for this protocol is mandatory; security. Support for this protocol is mandatory; associations using
associations using it can carry messages with the transfer attribute it can carry messages with the transfer attribute Secure=True. For
Secure=True. For use with TCP, implementation of TLS1.0 [7] is use with TCP, implementation of TLS1.0 [6] is REQUIRED and
REQUIRED and implementation of TLS1.1 [8] is RECOMMENDED. (If an implementation of TLS1.1 [8] is RECOMMENDED. (If an unreliable
unreliable transport such as DCCP or UDP is defined for GIST in the transport such as DCCP or UDP is defined for GIST in the future, this
future, TLS would be implemented with it using DTLS [35].) This MA-Protocol-ID would be implemented for it using DTLS [35].) GIST
specification makes no additional requirements on the TLS nodes supporting TLS1.0 or TLS1.1 MUST be able to negotiate the TLS
implementation (e.g. ciphersuites or authentication mechanisms) since ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD be able to
these can be negotiated within TLS itself. negotiate the TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA.
No higher-layer-addressing format is defined for TLS. The default mode of TLS authentication (which applies in particular
to the above ciphersuites) uses a client/server certificate exchange.
The Querying node acts as a TLS client, and the Responding node acts
as a TLS server. Where one of the above ciphersuites is negotiated,
the GIST node acting as a server MUST provide a certificate, and MUST
request one from the GIST node acting as a TLS client. This allows
either server-only or mutual authentication, depending on the
certificates available to the client and the policy applied at the
server.
GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the
negotiation of alternative ciphersuites is used to trigger
alternative authentication procedures (for example, the use of pre-
shared keys, [24]). The use of other authentication procedures may
require additional specification work to define how they can be used
as part of TLS within the GIST framework, and may or may not require
the definition of additional MA-Protocol-IDs.
No MA-protocol-options field is required for this use of TLS.
5.7.4. Additional Protocol Options 5.7.4. Additional Protocol Options
Further protocols or configurations could be defined in the future Further protocols or configurations could be defined in the future
for additional performance or flexibility. Examples are: for additional performance or flexibility. Examples are:
o SCTP or DCCP as alternatives to TCP, with essentially the same o SCTP or DCCP as alternatives to TCP, with essentially the same
configuration. configuration.
o SigComp [20] for message compression. o SigComp [17] for message compression.
o IPsec [31], ssh [32], or HIP/IPsec [33] for channel security. o IPsec [30], ssh [31], or HIP/IPsec [32] for channel security.
o Alternative modes of TCP operation, for example where it is set up o Alternative modes of TCP operation, for example where it is set up
from the responder to the querying node. from the responder to the querying node.
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 Query- of the format of the message routing information (MRI) and Query-
encapsulation rules. These are given in the following subsections encapsulation rules. These are given in the following subsections
for the various possible message routing methods. for the various possible message routing methods.
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 essentially the Flow Identifier as For the path-coupled MRM, this is essentially the Flow Identifier as
in [24]. Minimally, this could just be the flow destination address; in [22]. Minimally, this could just be the flow destination address;
however, to account for policy based forwarding and other issues a however, to account for policy based forwarding and other issues a
more complete set of header fields should be used (see Section 4.3.4 more complete set of header fields should be used (see Section 4.3.4
and Section 7.2 for further discussion). and Section 7.2 for further 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
[ flow-label ] [ flow-label ]
skipping to change at page 47, line 12 skipping to change at page 48, line 31
policy-based forwarding or load balancing which takes the source policy-based forwarding or load balancing which takes the source
address into account. However, there may be circumstances where address into account. However, there may be circumstances where
the use of the signaling source address is preferable, such as: the use of the signaling source address is preferable, such as:
* In order to receive ICMP error messages about the Query message * In order to receive ICMP error messages about the Query message
(such as unreachable port or address). If these are delivered (such as unreachable port or address). If these are delivered
to the flow source rather than the signaling source, it will be to the flow source rather than the signaling source, it will be
very difficult for the querying node to detect that it is the very difficult for the querying node to detect that it is the
last GIST node on the path. last GIST node on the path.
* In order to recieve GIST error messages where the error message * In order to receive GIST error messages where the error message
sender could not interpret the NLI in the original message. sender could not interpret the NLI in the original message.
* In order to attempt to run GIST through an unmodified NAT, * In order to attempt to run GIST through an unmodified NAT,
which will only process and translate IP addresses in the IP which will only process and translate IP addresses in the IP
header. header.
Because of these considerations, use of the signaling source Because of these considerations, use of the signaling source
address is allowed as an option, with use based on local policy. address is allowed as an option, with use based on local policy.
A node SHOULD use the flow source address for initial Query A node SHOULD use the flow source address for initial Query
messages, but SHOULD transition to the signaling source address messages, but SHOULD transition to the signaling source address
for some retransmissions or as a matter of static configuration for some retransmissions or as a matter of static configuration
(e.g. if a NAT is known to be in the path out of a certain (e.g. if a NAT is known to be in the path out of a certain
interface). A flag in the common header tells the message interface). A flag in the common header tells the message
receiver which option was used. receiver which option was used.
It is vital that the Query message mimics the actual data flow as It is vital that the Query message mimics the actual data flow as
closely as possible, since this is the basis of how the signaling closely as possible, since this is the basis of how the signaling
message is attached to the data path. To this end, GIST SHOULD set message is attached to the data path. To this end, GIST SHOULD set
the DiffServ codepoint and (for IPv6) flow label to match the values the DiffServ codepoint and (for IPv6) flow label to match the values
in the MRI if this would be needed to ensure correct routing. in the MRI.
Any message sent in datagram mode SHOULD be below a conservative Any message sent in datagram mode SHOULD be below a conservative
estimate of the path MTU, for which this specification takes the estimate of the path MTU, for which this specification takes the
value 512 bytes as a default. It is possible that fragmented value 512 bytes as a default. It is possible that fragmented
datagrams including an RAO will not be correctly handled in the datagrams including an RAO will not be correctly handled in the
network, so the sender SHOULD set the DF (do not fragment) bit in the network, so the sender SHOULD set the DF (do not fragment) bit in the
IPv4 header in order to detect that a message has encountered a link IPv4 header in order to detect that a message has encountered a link
with an unusually low MTU. In this case, it MUST use the signaling with an unusually low MTU. In this case, it MUST use the signaling
source address for the IP source address in order to receive the ICMP source address for the IP source address in order to receive the ICMP
error. error.
A GIST implementation SHOULD apply validation checks to the MRI, to A GIST implementation SHOULD apply validation checks to the MRI, to
reject Query messages that are being injected by nodes with no reject Query messages that are being injected by nodes with no
legitimate interest in the flow being signalled for. In general, if legitimate interest in the flow being signalled for. In general, if
the GIST node can detect that no flow could arrive over the same the GIST node can detect that no flow could arrive over the same
interface as the Query message, it MUST be rejected. (Such checks interface as the Query message, it MUST be rejected with an
apply only to messages with the query encapsulation, since only those appropriate error message. (Such checks apply only to messages with
messages are required to track the flow path.) The main checks are the query encapsulation, since only those messages are required to
that the IP version should match the version(s) used on that track the flow path.) The main checks are that the IP version should
interface, and that the full range of source addresses (the source- match the version(s) used on that interface, and that the full range
address masked with its prefix-length) would pass ingress filtering of source addresses (the source-address masked with its prefix-
checks. length) would pass ingress filtering checks. For these cases, the
error message is "MRI Validation Failure" (Appendix A.4.4.12) with
subcodes 1 or 2 ("IP Version Mismatch" or "Ingress Filter Failure")
respectively.
5.8.1.3. Upstream Query Encapsulation 5.8.1.3. Upstream Query Encapsulation
In some deployment scenarios it is desirable and logically possible In some deployment scenarios it is desirable and logically possible
to set up routing state in the upstream direction (from flow receiver to set up routing state in the upstream direction (from flow receiver
towards the sender). This could be used to support firewall towards the sender). This could be used to support firewall
signaling to control traffic from an 'un-cooperative' sender, or signaling to control traffic from an 'un-cooperative' sender, or
signaling in general where the flow sender was not NSIS-capable. signaling in general where the flow sender was not NSIS-capable.
This is incorporated into GIST by defining an encapsulation and This is incorporated into GIST by defining an encapsulation and
processing rules for sending Query messages upstream. processing rules for sending Query messages upstream.
In general, it is not possible to determine the hop-by-hop route In general, it is not possible to determine the hop-by-hop route
upstream because of asymmetric routing. However, in particular upstream because of asymmetric routing. However, in particular
cases, the upstream peer can be discovered with a high degree of cases, the upstream peer can be discovered with a high degree of
confidence, for example: confidence, for example:
o The upstream GIST peer is 1 IP hop away, and can be reached by o The upstream GIST peer is 1 IP hop away, and can be reached by
tracing back through the interface on which the flow arrives. tracing back through the interface on which the flow arrives.
o The upstream peer is a border router of a single-home (stub) o The upstream peer is a border router of a single-homed (stub)
network. network.
This section defines an upstream Query encapsulation and validation This section defines an upstream Query encapsulation and validation
checks for when it can be used. The functionality to generate checks for when it can be used. The functionality to generate
upstream Queries is OPTIONAL, but if received they MUST be processed upstream Queries is OPTIONAL, but if received they MUST be processed
in the normal way (no special functionality is needed for this). It in the normal way (no special functionality is needed for this). It
is possible for routing state (for a given MRI and NSLPID) to be is possible for routing state (for a given MRI and NSLPID) to be
installed by both upstream and downstream Query exchanges. If the installed by both upstream and downstream Query exchanges. If the
SIDs are different, these items of routing state MUST be considered SIDs are different, these items of routing state MUST be considered
as independent; if they match, that installed by the downstream as independent; if they match, that installed by the downstream
skipping to change at page 49, line 15 skipping to change at page 50, line 36
o The IP-TTL of the message MUST be set to 255. o The IP-TTL of the message MUST be set to 255.
The sending GIST implementation SHOULD attempt to send the Query The sending GIST implementation SHOULD attempt to send the Query
message out of the same interface and to the same link layer message out of the same interface and to the same link layer
neighbour from which the data packets of the flow are arriving. neighbour from which 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 a message which has been propagated more than one IP hop, with an
"Invalid IP TTL" error message (Appendix A.4.4.11). This can be "Invalid IP TTL" error message (Appendix A.4.4.11). This can be
determined by examining the received IP TTL, similar to the determined by examining the received IP TTL, similar to the
generalised IP TTL security mechanism described in [23]. generalised IP TTL security mechanism described in [21].
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 NTLP state in the downstream direction. used to trigger setup of NTLP 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
This MRM is used to discover GIST nodes with particular properties in This MRM is used to discover GIST nodes with particular properties in
the direction of a given address, for example to discover a NAT along the direction of a given address, for example to discover a NAT along
the upstream data path (e.g. as in [28]. the upstream data path (e.g. as in [27].
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 51, line 41 skipping to change at page 52, line 41
3. For each flow and signaling direction where the node has accepted 3. For each flow and signaling direction where the node has accepted
the creation of routing state by a peer, there is an instance of the creation of routing state by a peer, there is an instance of
a Responding-Node state machine (Response-SM). This machine is a Responding-Node state machine (Response-SM). This machine is
responsible for managing the status of the routing state for that responsible for managing the status of the routing state for that
flow. Depending on policy, it MAY be responsible for flow. Depending on policy, it MAY be responsible for
[re]transmission of Response messages, or this MAY be handled by [re]transmission of Response messages, or this MAY be handled by
the Node-SM, and a Response-SM is not even created for a flow the Node-SM, and a Response-SM is not even created for a flow
until a properly formatted Confirm has been accepted. until a properly formatted Confirm has been accepted.
4. Messaging assocations have their own lifecycle, represented by 4. Messaging associations have their own lifecycle, represented by
MA-SM, from when they are first created (in an 'incomplete' MA-SM, from when they are first created (in an 'incomplete'
state, listening for an inbound connection or waiting for state, listening for an inbound connection or waiting for
outbound connections to complete), to when they are active and outbound connections to complete), to when they are active and
available for use. available for use.
Apart from the fact that the various machines can be created and Apart from the fact that the various machines can be created and
destroyed by each other, there is almost no interaction between them. destroyed by each other, there is almost no interaction between them.
The machines for different flows do not interact; the Query-SM and The machines for different flows do not interact; the Query-SM and
Response-SM for a single flow and signaling direction do not Response-SM for a single flow and signaling direction do not
interact. That is, the Response-SM which accepts the creation of interact. That is, the Response-SM which accepts the creation of
skipping to change at page 53, line 12 skipping to change at page 54, line 12
which no more appropriate messaging association state or routing which no more appropriate messaging association state or routing
state exists. Its structure is trivial: there is a single state state exists. Its structure is trivial: there is a single state
('Idle'); all events cause a transition back to Idle. Some events ('Idle'); all events cause a transition back to Idle. Some events
cause the creation of other state machines. The only events that are cause the creation of other state machines. The only events that are
processed by this state machine are incoming GIST messages (Query/ processed by this state machine are incoming GIST messages (Query/
Response/Confirm/Data) and API requests to send data; all other Response/Confirm/Data) and API requests to send data; all other
events are impossible. In addition to this event processing, the events are impossible. In addition to this event processing, the
Node level machine is responsible for managing listening endpoints Node level machine is responsible for managing listening endpoints
for messaging associations (although these relate to Responding node for messaging associations (although these relate to Responding node
operation, they cannot be handled by the Responder state machine operation, they cannot be handled by the Responder state machine
since they are not created per flow.) The processing rules for each since they are not created per flow). The processing rules for each
event are as follows: event are as follows:
Rule 1 (rx_Query): Rule 1 (rx_Query):
if (routing state can be created without a full 3-way handshake) then use the GIST service interface to determine the signaling application
create R-SM and pass message to it policy relating to this peer
if (the signaling application indicates that routing state should
be created) then
if (routing state can be created without a 3-way handshake) then
create R-SM and transfer control to it
else
send Response
else else
send Response propagate the Query with any updated NSLP payload provided
Rule 2 (rx_Response): Rule 2 (rx_Response):
// should already have a Q-SM to handle this // should already have a Q-SM to handle this
discard message discard message
send "No Routing State" error message send "No Routing State" error message
Rule 3 (rx_Confirm): Rule 3 (rx_Confirm):
if (routing state can be created without a full 3-way handshake) then if (routing state can be created before receiving a Confirm) then
// should already have R-SM for it which would handle this message // should already have R-SM for it which would handle this message
discard message discard message
send "No Routing State" error message send "No Routing State" error message
else else
create R-SM and pass message to it create R-SM and pass message to it
Rule 4 (rx_Data): pass directly to NSLP Rule 4 (rx_Data):
if (node policy will only process Data messages with matching
routing state) then
send "No Routing State" error message
else
pass directly to NSLP
Rule 5 (tg_NSLPData): Rule 5 (tg_NSLPData):
if Q-mode encapsulation is not possible for this MRI if Q-mode encapsulation is not possible for this MRI
reject message with an error reject message with an error
else else
if (local policy & transfer attributes say routing if (local policy & transfer attributes say routing
state is not needed) then state is not needed) then
send message statelessly send message statelessly
else else
skipping to change at page 54, line 22 skipping to change at page 55, line 33
o Awaiting Refresh o Awaiting Refresh
The Q-SM is created by the N-SM machine as a result of a request to The Q-SM is created by the N-SM machine as a result of a request to
send a message for a flow in a signaling direction where the send a message for a flow in a signaling direction where the
appropriate state does not exist. The Query is generated immediately appropriate state does not exist. The Query is generated immediately
and the No_Response timer is started. The NSLP data MAY be carried and the No_Response timer is started. The NSLP data MAY be carried
in the Query if local policy and the transfer attributes allow it, in the Query if local policy and the transfer attributes allow it,
otherwise it MUST be queued locally pending MA establishment. Then otherwise it MUST be queued locally pending MA establishment. Then
the machine transitions to the Awaiting Response state, in which the machine transitions to the Awaiting Response state, in which
timout-based retransmissions are handled. Data messages (rx_Data timeout-based retransmissions are handled. Data messages (rx_Data
events) should not occur in this state; if they do, this may indicate events) should not occur in this state; if they do, this may indicate
a lost Response and a node MAY also retransmit a Query for this a lost Response and a node MAY also retransmit a Query for this
reason. reason.
Once a Response has been successfully recieved and routing state Once a Response has been successfully received and routing state
created, the machine transitions to Established, during which NSLP created, the machine transitions to Established, during which NSLP
data can be sent and received normally. Further Responses received data can be sent and received normally. Further Responses received
in this state MUST be treated the same way (this may be the result of in this state MUST be treated the same way (this may be the result of
a lost Confirm). The Awaiting Refresh state can be considered as a a lost Confirm). The Awaiting Refresh state can be considered as a
substate of Established, where a new Query has been generated to substate of Established, where a new Query has been generated to
refresh the routing state (as in Awaiting Response) but NSLP data can refresh the routing state (as in Awaiting Response) but NSLP data can
be handled normally. be handled normally.
The timers relevant to this state machines are as follows: The timers relevant to this state machine are as follows:
Refresh_QNode: Indicates when the routing state stored by this state Refresh_QNode: Indicates when the routing state stored by this state
machine must be refreshed. It is reset whenever a Response is machine must be refreshed. It is reset whenever a Response is
received indicating that the routing state is still valid. received indicating that the routing state is still valid.
Implementations MUST set the period of this timer based on the Implementations MUST set the period of this timer based on the
value in the RS-validity-time field of a Reponse message to ensure value in the RS-validity-time field of a Response message to
that a Query is generated before the peer's routing state expires. ensure that a Query is generated before the peer's routing state
expires.
No_Response: Indicates that a Response has not been received in No_Response: Indicates that a Response has not been received in
answer to a Query. This is started whenever a Query is sent and answer to a Query. This is started whenever a Query is sent and
stopped when a Response is received. stopped when a Response is received.
Inactive_QNode: Indicates that no traffic is currently being handled Inactive_QNode: Indicates that no traffic is currently being handled
by this state machine. This is reset whenever the state machine by this state machine. This is reset whenever the state machine
handles NSLP data (in either direction). When it expires, the handles NSLP data (in either direction). When it expires, the
state machine MAY be deleted. The period of the timer can be set state machine MAY be deleted. The period of the timer can be set
at any time via the API (SetStateLifetime), and if the period is at any time via the API (SetStateLifetime), and if the period is
skipping to change at page 56, line 28 skipping to change at page 58, line 23
Rule 3: Rule 3:
// Assume the Confirm was lost in transit so resend it // Assume the Confirm was lost in transit so resend it
// for the last Response we received // for the last Response we received
send Confirm message send Confirm message
restart Refresh_QNode and Inactive_QNode timers restart Refresh_QNode and Inactive_QNode timers
Rule 4: Rule 4:
if a new MA-SM is needed create one if a new MA-SM is needed create one
if a Confirm is required send Confirm message if the R flag was set send a Confirm message
pass any NSLP data to the NSLP pass any NSLP data to the NSLP
send any stored Data messages send any stored Data messages
stop No_Response timer stop No_Response timer
start Refresh_QNode and Inactive_QNode timers start Refresh_QNode and Inactive_QNode timers
Rule 5: Rule 5:
send Data message send Data message
restart Inactive_QNode timer restart Inactive_QNode timer
skipping to change at page 57, line 32 skipping to change at page 59, line 25
2. It is created on receiving a Query, but a Confirm is requested. 2. It is created on receiving a Query, but a Confirm is requested.
A timer is used to retransmit Response messages and the R-SM is A timer is used to retransmit Response messages and the R-SM is
destroyed if no valid Confirm is received. destroyed if no valid Confirm is received.
3. It cannot be created until a valid Confirm is received (the 3. It cannot be created until a valid Confirm is received (the
initial Query will have been handled by the Node level machine). initial Query will have been handled by the Node level machine).
In case 2 the R-SM is created in the Awaiting Confirm state, and In case 2 the R-SM is created in the Awaiting Confirm state, and
remains there until a Confirm is received, at which point it remains there until a Confirm is received, at which point it
transitions to Established. In cases 1 and 3 the R-SM is created transitions to Established. In cases 1 and 3 the R-SM is created
already in the Established state. In Established state the NSLP can directly in the Established state. Note that if the machine is
send and receive data normally, and any additional rx_Confirm events created on receiving a Query, some of the message processing will
MUST be silently ignored. The Awaiting Refresh state can be already have been performed in the Node state machine. In the
considered a substate of Established, where a Query has been received Established state the NSLP can send and receive data normally, and
to begin the routing state refresh. any additional rx_Confirm events MUST be silently ignored. The
Awaiting Refresh state can be considered a substate of Established,
where a Query has been received to begin the routing state refresh.
In the Awaiting Refresh state the R-SM behaves as in the Awaiting In the Awaiting Refresh state the R-SM behaves as in the Awaiting
Confirm state, except that the NSLP can still send and receive data. Confirm state, except that the NSLP can still send and receive data.
In particular, in both states there is timer-based retransmission of In particular, in both states there is timer-based retransmission of
Response messages until a Confirm is received; additional rx_Query Response messages until a Confirm is received; additional rx_Query
events in these states MUST also generate a response and restart the events in these states MUST also generate a response and restart the
no_Confirm timer. no_Confirm timer.
The timers relevant to the operation of this state machine are as The timers relevant to the operation of this state machine are as
follows: follows:
skipping to change at page 59, line 14 skipping to change at page 61, line 14
The processing rules are as follows: The processing rules are as follows:
Rule 1: Rule 1:
// a Confirm message is required // a Confirm message is required
send Response message send Response message
(re)start No_Confirm timer (re)start No_Confirm timer
Rule 2: Rule 2:
pass any piggybacked data to the NSLP
if a new MA-SM would be needed for this peer if a new MA-SM would be needed for this peer
create one in listening state create one in listening state
start Expire_RNode timer start Expire_RNode timer
Rule 3: send the Data message Rule 3: send the Data message
Rule 4: pass data to NSLP Rule 4: pass data to NSLP
Rule 5: Rule 5:
// no Confirm message is required // no Confirm message is required
send Response message send Response message
start Expire_RNode timer start Expire_RNode timer
Rule 6: send "No Routing State" error message Rule 6: send "No Routing State" error message
Rule 7: store Data message Rule 7: store Data message
Rule 8: Rule 8:
pass any piggybacked data to the NSLP
send any stored Data messages send any stored Data messages
stop No_Confirm timer stop No_Confirm timer
start Expire_RNode timer start Expire_RNode timer
Rule 9: Rule 9:
if number of Responses sent has reached threshold if number of Responses sent has reached threshold
// nResp_isMax is true // nResp_isMax is true
destroy self destroy self
else else
skipping to change at page 60, line 19 skipping to change at page 62, line 21
is waiting for the connection process(es) for every protocol in the is waiting for the connection process(es) for every protocol in the
messaging association to complete; this might involve creating messaging association to complete; this might involve creating
listening endpoints or attempting active connects. Timers may also listening endpoints or attempting active connects. Timers may also
be necessary to detect connection failure (e.g. no incoming be necessary to detect connection failure (e.g. no incoming
connection within a certain period), but these are not modelled connection within a certain period), but these are not modelled
explicitly. The Connected state indicates that the MA is open and explicitly. The Connected state indicates that the MA is open and
ready to use. In addition there is an Idle state in which the local ready to use. In addition there is an Idle state in which the local
node no longer requires the messaging association but the remote node node no longer requires the messaging association but the remote node
still wants it to be kept open. still wants it to be kept open.
Clearly, many internal details of the messaging assocation protocols Clearly, many internal details of the messaging association protocols
are hidden in this model, especially where the messaging association are hidden in this model, especially where the messaging association
uses multiple protocol layers. Note also that although the existence uses multiple protocol layers. Note also that although the existence
of messaging associations is not directly visible to NSLPs, there is of messaging associations is not directly visible to signaling
some interaction between the two because security-related information applications, there is some interaction between the two because
becomes available during the open process, and this may be indicated security-related information becomes available during the open
to signaling applications if they have requested it. process, and this may be indicated to signaling applications if they
have requested it.
The timers relevant to the operation of this state machine are as The timers relevant to the operation of this state machine are as
follows: follows:
SendHello: Indicates that an MAHello message should be sent to the SendHello: Indicates that an MAHello message should be sent to the
remote node. The period of this timer is determined by the MA- remote node. The period of this timer is determined by the MA-
Hold-Time sent by the remote node during the Query/Response Hold-Time sent by the remote node during the Query/Response/
exchange. Confirm exchange.
NoHello: Indicates that no MAHello has been received from the remote NoHello: Indicates that no MAHello has been received from the remote
node for a period of time. The period of this timer is sent to node for a period of time. The period of this timer is sent to
the remote node as the MA-Hold-Time during the Query/Response the remote node as the MA-Hold-Time during the Query/Response
exchange. exchange.
NoActivity: Indicates that the link has been inactive for a period of NoActivity: Indicates that the link has been inactive for a period of
time. The period of this timer is implementation specific but is time. The period of this timer is implementation specific but is
likely to be related to the period of the NoHello timer. likely to be related to the period of the NoHello timer.
skipping to change at page 63, line 27 skipping to change at page 65, line 27
out the complete path update processing. Its responsibilities are to out the complete path update processing. Its responsibilities are to
detect the route change, update its local routing state consistently, detect the route change, update its local routing state consistently,
and inform interested signaling applications at affected nodes. and inform interested signaling applications at affected nodes.
xxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxx
x +--+ +--+ +--+ x Initial x +--+ +--+ +--+ x Initial
x .|C1|_.....|D1|_.....|E1| x Configuration x .|C1|_.....|D1|_.....|E1| x Configuration
x . +--+. .+--+. .+--+\. x x . +--+. .+--+. .+--+\. x
>>xxxxxxxxxxxxx . . . . . . xxxxxx>> >>xxxxxxxxxxxxx . . . . . . xxxxxx>>
+-+ +-+ . .. .. . +-+ +-+ +-+ . .. .. . +-+
...|A|.......|B|/ .. .. .|F|_.... ...|A|_......|B|/ .. .. .|F|_....
+-+ +-+ . . . . . . +-+ +-+ +-+ . . . . . . +-+
. . . . . . . . . . . .
. +--+ +--+ +--+ . . +--+ +--+ +--+ .
.|C2|_.....|D2|_.....|E2|/ .|C2|_.....|D2|_.....|E2|/
+--+ +--+ +--+ +--+ +--+ +--+
+--+ +--+ +--+ Configuration +--+ +--+ +--+ Configuration
.|C1|......|D1|......|E1| after failure .|C1|......|D1|......|E1| after failure
. +--+ .+--+ +--+ of D1-E link . +--+ .+--+ +--+ of E1-F link
. \. . \. ./ . \. . \. ./
+-+ +-+. .. .. +-+ +-+ +-+ . .. .. +-+
...|A|.......|B|. .. .. .|F|_.... ...|A|_......|B|. .. .. .|F|_....
+-+ +-+\ . . . . . +-+ +-+ +-+\ . . . . . +-+
>>xxxxxxxxxxxxx . . . . . . xxxxxx>> >>xxxxxxxxxxxxx . . . . . . xxxxxx>>
x . +--+ +--+ +--+ . x x . +--+ +--+ +--+ . x
x .|C2|_.....|D2|......|E2|/ x x .|C2|_.....|D2|_.....|E2|/ x
x +--+ +--+ +--+ x x +--+ +--+ +--+ x
xxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxx
........... = physical link topology ........... = physical link topology
>>xxxxxxx>> = flow direction >>xxxxxxx>> = flow direction
_.......... = outgoing link for flow xxxxxx given _.......... = outgoing link for flow xxxxxx given
by local forwarding table by local forwarding table
Figure 9: A Re-Routing Event Figure 9: 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 9. An the problem. Consider the re-routing event shown in Figure 9. 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.
On the assumption that NSLPs are soft-state based and operate end to On the assumption that signaling applications are soft-state based
end, and because GIST also periodically updates its picture of and operate end to end, and because GIST also periodically updates
routing state, route changes will eventually be repaired its picture of routing state, route changes will eventually be
automatically. The specification as already given includes this repaired automatically. The specification as already given includes
functionality. However, especially if NSLP refresh times are this functionality. However, especially if upper layer refresh times
extended to reduce signaling load, the duration of inconsistent state are extended to reduce signaling load, the duration of inconsistent
may be very long indeed. Therefore, GIST includes logic to exchange state may be very long indeed. Therefore, GIST includes logic to
prompt notifications with NSLPs, to allow local repair if possible. exchange prompt notifications with signaling applications, to allow
The additional mechanisms to achieve this are described in the local repair if possible. The additional mechanisms to achieve this
following subsections. To a large extent, these additions can be are described in the following subsections. To a large extent, these
seen as implementation issues; the protocol messages and their additions can be seen as implementation issues; the protocol messages
significance are not changed, but there are extra interactions and their significance are not changed, but there are extra
through the API between GIST and signaling applications, and interactions through the API between GIST and signaling applications,
additional triggers for transitions between the various GIST states. and additional triggers for transitions between the various GIST
states.
7.1.2. Route Change Detection Mechanisms 7.1.2. Route Change Detection Mechanisms
There are two aspects to detecting a route change at a single node: There are two aspects to detecting a route change at a single node:
o Detecting that the outgoing path, in the direction of the Query, o Detecting that the outgoing path, in the direction of the Query,
has (or may have) changed. has (or may have) changed.
o Detecting that the incoming path, in the direction of the o Detecting that the incoming path, in the direction of the
Response, has (or may have) changed (in which case the node may no Response, has (or may have) changed (in which case the node may no
skipping to change at page 65, line 23 skipping to change at page 67, line 24
if the routing change is local, not if it happens a few routing if the routing change is local, not if it happens a few routing
hops away (including the case that it happens at a GIST-unaware hops away (including the case that it happens at a GIST-unaware
node). node).
Extended Trigger: Here, GIST checks a link-state topology database to Extended Trigger: Here, GIST checks a link-state topology database to
discover that the path has changed. This makes certain discover that the path has changed. This makes certain
assumptions on consistency of route computation and only works assumptions on consistency of route computation and only works
within a single area for OSPF and similar link-state protocols. within a single area for OSPF and similar link-state protocols.
Where available, this offers the most accurate and rapid Where available, this offers the most accurate and rapid
indication of route changes, but requires more access to the indication of route changes, but requires more access to the
routing internals than a typical OS may provide. routing internals than a typical operating system may provide.
GIST C-mode Monitoring: GIST may find that C-mode packets are GIST C-mode Monitoring: GIST may find that C-mode packets are
arriving (from either peer) with a different TTL or on a different arriving (from either peer) with a different TTL or on a different
interface. This provides no direct information about the new flow interface. This provides no direct information about the new flow
path, but indicates that routing has changed and that rediscovery path, but indicates that routing has changed and that rediscovery
may be required. may be required.
Data Plane Monitoring: The signaling application on a node may detect Data Plane Monitoring: The signaling application on a node may detect
a change in behaviour of the flow, such as TTL change, arrival on a change in behaviour of the flow, such as TTL change, arrival on
a different interface, or loss of the flow altogether. The a different interface, or loss of the flow altogether. The
skipping to change at page 67, line 13 skipping to change at page 69, line 13
that the peer has not changed. When the status returns to Good, GIST that the peer has not changed. When the status returns to Good, GIST
MUST if necessary update its routing state table so that the MUST if necessary update its routing state table so that the
relationships between MRI/SID/NSLPID tuples and messaging relationships between MRI/SID/NSLPID tuples and messaging
associations are up to date. associations are up to date.
When classification of the routing state for the downstream direction When classification of the routing state for the downstream direction
changes to Bad/Tentative because of local routing indications, GIST changes to Bad/Tentative because of local routing indications, GIST
MAY automatically change the classification in the upstream direction MAY automatically change the classification in the upstream direction
to Tentative unless local routing indicates that this is not to Tentative unless local routing indicates that this is not
necessary. This SHOULD NOT be done in the case where the initial necessary. This SHOULD NOT be done in the case where the initial
change was indicated by the NSLP. This mechanism accounts for the change was indicated by the signaling application. This mechanism
fact that a routing change may affect several nodes, and so can be an accounts for the fact that a routing change may affect several nodes,
indication that upstream routing may also have changed. In any case, and so can be an indication that upstream routing may also have
whenever GIST updates the routing status, it informs the NSLPs with changed. In any case, whenever GIST updates the routing status, it
the NetworkNotification API (Appendix B.4), unless the change was informs the signaling application with the NetworkNotification API
caused via the API in the first place. (Appendix B.4), unless the change was caused via the API in the first
place.
The GIST behaviour for state repair is different for the Querying and The GIST behaviour for state repair is different for the Querying and
Responding node. At the Responding node, there is no additional Responding node. At the Responding node, there is no additional
behaviour, since the Responding node cannot initiate protocol behaviour, since the Responding node cannot initiate protocol
transitions autonomously, it can only react to the Querying node. transitions autonomously, it can only react to the Querying node.
The Querying node has three options, depending on how the transition The Querying node has three options, depending on how the transition
from 'Good' was initially caused: from 'Good' was initially caused:
1. To inspect the routing/forwarding table and verifying that the 1. To inspect the routing/forwarding table and verifying that the
next peer has not changed. This technique MUST NOT be used if next peer has not changed. This technique MUST NOT be used if
the transition was caused by an NSLP, but SHOULD be used the transition was caused by a signaling application, but SHOULD
otherwise if available. be used otherwise if available.
2. To move to the 'Awaiting Refresh' state. This technique MUST NOT 2. To move to the 'Awaiting Refresh' state. This technique MUST NOT
be used if the current status is 'Bad', since data is being be used if the current status is 'Bad', since data is being
incorrectly delivered. incorrectly delivered.
3. To move to the 'Awaiting Response' state. This technique may be 3. To move to the 'Awaiting Response' state. This technique may be
used at any time, but has the effect of freezing NSLP used at any time, but has the effect of freezing NSLP
communication while GIST state is being repaired. communication while GIST state is being repaired.
The second and third techniques trigger the execution of a GIST The second and third techniques trigger the execution of a GIST
handshake to carry out the repair. It may be desirable to delay the handshake to carry out the repair. It may be desirable to delay the
start of the handshake process, either to wait for the network to start of the handshake process, either to wait for the network to
stabilise, to avoid flooding the network with Query traffic for a stabilise, to avoid flooding the network with Query traffic for a
large number of affected flows, or to wait for confirmation that the large number of affected flows, or to wait for confirmation that the
node is still on the path from the upstream peer. One approach is to node is still on the path from the upstream peer. One approach is to
delay the handshake until there is NSLP data to be transmitted. delay the handshake until there is NSLP data to be transmitted.
Implementation of such delays is a matter of local policy; however, Implementation of such delays is a matter of local policy; however,
GIST MUST begin the handshake immediately if the status change was GIST MUST begin the handshake immediately if the status change was
caused by an InvalidateRoutingState API call is marked as 'Urgent', caused by an InvalidateRoutingState API call marked as 'Urgent', and
and SHOULD begin it if the upstream routing state is still known to SHOULD begin it if the upstream routing state is still known to be
be Good. Good.
7.1.4. Signaling Application Operation 7.1.4. Signaling Application Operation
Signaling applications can use these functions as provided by GIST to Signaling applications can use these functions as provided by GIST to
carry out rapid local repair following re-routing events. The carry out rapid local repair following re-routing events. The
signaling application instances carry out the multi-hop aspects of signaling application instances carry out the multi-hop aspects of
the procedure, including crossover node detection, and tear down/ the procedure, including crossover node detection, and tear-down/
reinstall signaling application state; they also trigger GIST to reinstallation of signaling application state; they also trigger GIST
carry out the local routing state maintenance operations over each to carry out the local routing state maintenance operations over each
individual hop. The local repair procedures depend heavily on the individual hop. The local repair procedures depend heavily on the
fact that stateful NSLP nodes are a single GIST hop apart; this is fact that stateful NSLP nodes are a single GIST hop apart; this is
enforced by the details of the GIST peer-discovery process. enforced by the details of the GIST peer-discovery process.
The following outline description of a possible set of NSLP actions The following outline description of a possible set of NSLP actions
takes the scenario of Figure 9 as an example. takes the scenario of Figure 9 as an example.
1. The NSLP at node E1 is notified by GIST of route changes 1. The signaling application at node E1 is notified by GIST of route
affecting the downstream and upstream directions. The downstream changes affecting the downstream and upstream directions. The
status was updated to Bad because of a trigger from the local downstream status was updated to Bad because of a trigger from
forwarding tables, and the upstream status changed automatically the local forwarding tables, and the upstream status changed
to Tentative as a consequence. The NSLP at E1 MAY begin local automatically to Tentative as a consequence. The signaling
repair immediately, or MAY propagate a notification upstream to application at E1 MAY begin local repair immediately, or MAY
D1 that re-routing has occurred. propagate a notification upstream to D1 that re-routing has
occurred.
2. The NSLP at node D1 is notified of the route change, either by 2. The signaling application at node D1 is notified of the route
NSLP level notifications or from the GIST level (e.g. by a change, either by signaling application notifications or from the
trigger from a link-state topology database). If the information GIST level (e.g. by a trigger from a link-state topology
propagates faster within the routing protocol, GIST will change database). If the information propagates faster within the
the upstream/downstream routing state to Tentative/Bad routing protocol, GIST will change the upstream/downstream
automatically, and this will cause the NSLP to propagate the routing state to Tentative/Bad automatically, and this will cause
notification further upstream. the signaling application to propagate the notification further
upstream.
3. This process continues until the notification reaches node A. 3. This process continues until the notification reaches node A.
Here, there is no downstream routing change, so GIST only learns Here, there is no downstream routing change, so GIST only learns
of the update via the NSLP trigger. Since the upstream status is of the update via the signaling application trigger. Since the
still Good, it therefore begins the repair handshake immediately. upstream status is still Good, it therefore begins the repair
handshake immediately.
4. The handshake initiated by node A causes its downstream routing 4. The handshake initiated by node A causes its downstream routing
state to be confirmed as Good and unchanged there; it also state to be confirmed as Good and unchanged there; it also
confirms the (Tentative) upstream routing state at B as Good. confirms the (Tentative) upstream routing state at B as Good.
This is enough to identify B as the crossover router, and the This is enough to identify B as the crossover router, and the
NSLP and GIST can begin the local repair process. signaling application and GIST can begin the local repair
process.
An alternative way to reach step (4) is that node B is able to An alternative way to reach step (4) is that node B is able to
determine autonomously that there is no likelihood of an upstream determine autonomously that there is no likelihood of an upstream
route change (e.g. it is an area border router and the route change route change (e.g. it is an area border router and the route change
is only intra-area). In this case, the NSLP and GIST will see that is only intra-area). In this case, the signaling application and
the upstream state is Good and can begin the local repair directly. GIST will see that the upstream state is Good and can begin the local
repair directly.
After a route change, a signaling application may wish to remove After a route change, a signaling application may wish to remove
state at another node which is no longer on the path. However, since state at another node which is no longer on the path. However, since
it is no longer on the path, in principle GIST can no longer send it is no longer on the path, in principle GIST can no longer send
messages to it. (In general, provided this state is soft, it will messages to it. (In general, provided this state is soft, it will
time out anyway; however, the timeouts involved may have been set to time out anyway; however, the timeouts involved may have been set to
be very long to reduce signaling load.) The requirement to remove be very long to reduce signaling load.) The requirement to remove
state in a specific peer node is identified in [29]. state in a specific peer node is identified in [28].
This requirement can be met provided that GIST is able to use the old This requirement can be met provided that GIST is able to use the old
path to the signaling application peer for some period while the NSLP path to the signaling application peer for some period while the
still needs it. Since NSLP peers are a single GIST hop apart, the signaling application still needs it. Since NSLP peers are a single
necessary information is just the old entry in the node's routing GIST hop apart, the necessary information is just the old entry in
state table for that flow. Rather than requiring the GIST level to the node's routing state table for that flow. Rather than requiring
maintain multiple generations of this information, it can just be the GIST level to maintain multiple generations of this information,
provided to the signaling application in the same node (in an opaque it can just be provided to the signaling application in the same node
form), which can store it if necessary and provide it back to the (in an opaque form), which can store it if necessary and provide it
GIST layer in case it needs to be used. This information is denoted back to the GIST layer in case it needs to be used. This information
as 'SII-Handle' in the abstract API of Appendix B. Messages sent is denoted as 'SII-Handle' in the abstract API of Appendix B.
this way MUST bypass the GIST routing state tables at the sender, and Messages sent this way MUST bypass the GIST routing state tables at
this is indicated by setting the E flag in the common header the sender, and this is indicated by setting the E flag in the common
(Appendix A.1); at the receiver, GIST MUST NOT validate the MRI/SID/ header (Appendix A.1); at the receiver, GIST MUST NOT validate the
NSLPID against local routing state and instead indicates the mode of MRI/SID/NSLPID against local routing state and instead indicates the
reception to signaling applications through the API (Appendix B.2). mode of reception to signaling applications through the API
Signaling applications should validate the source and effect of the (Appendix B.2). Signaling applications should validate the source
message themselves. and effect of the message themselves, and if appropriate should in
particular indicate to GIST (see Appendix B.5) that routing state is
no longer required for this flow. This is necessary to prevent GIST
in nodes on the old path initiating routing state refresh and thus
causing state conflicts at the crossover router.
7.2. NAT Traversal 7.2. NAT Traversal
GIST messages must carry packet addressing and higher layer GIST messages must carry packet addressing and higher layer
information as payload data in order to define the flow signalled information as payload data in order to define the flow signalled
for. (This applies to all GIST messages, regardless of how they are for. (This applies to all GIST messages, regardless of how they are
encapsulated or which direction they are travelling in.) At an encapsulated or which direction they are travelling in.) At an
addressing boundary the data flow packets will have their headers addressing boundary the data flow packets will have their headers
translated; if the signaling payloads are not translated translated; if the signaling payloads are not translated
consistently, the signaling messages will refer to incorrect (and consistently, the signaling messages will refer to incorrect (and
probably meaningless) flows after passing through the boundary. In probably meaningless) flows after passing through the boundary. In
addition, GIST handshake messages carry additional addressing addition, GIST handshake messages carry additional addressing
information about the GIST nodes themselves, and this must also be information about the GIST nodes themselves, and this must also be
processed appropriately when traversing a NAT. processed appropriately when traversing a NAT.
The simplest solution to this problem is to require that a NAT is The simplest solution to this problem is to require that a NAT is
GIST-aware, and to allow it to modify messages based on the contents GIST-aware, and to allow it to modify messages based on the contents
of the MRI. (This is makes the assumption that NATs only rewrite the of the MRI. (This makes the assumption that NATs only rewrite the
header fields included in this payload, and not other higher layer header fields included in this payload, and not other higher layer
identifiers.) Provided this is done consistently with the data flow identifiers.) Provided this is done consistently with the data flow
header translation, signaling messages will be valid each side of the header translation, signaling messages will be valid each side of the
boundary, without requiring the NAT to be signaling application boundary, without requiring the NAT to be signaling application
aware. (Note, however, that if the NAT does not understand the MRI, aware. (Note, however, that if the NAT does not understand the MRI,
it should reject the message with an appropriate error.) it should reject the message with an appropriate error.)
This specification defines an additional object that a NAT can insert This specification defines an additional object that a NAT can insert
into Query-encapsulated messages and which is echoed back in any into Query-encapsulated messages and which is echoed back in any
responses to those messages. The new object, the NAT-Traversal responses to those messages. The new object, the NAT-Traversal
skipping to change at page 70, line 36 skipping to change at page 72, line 47
This specification does not define normative behaviour for a NAT This specification does not define normative behaviour for a NAT
translating GIST messages, since much of this will depend on NAT translating GIST messages, since much of this will depend on NAT
policy about allocating bindings; the description is purely policy about allocating bindings; the description is purely
informative. However, it does define the behaviour of a GIST node informative. However, it does define the behaviour of a GIST node
receiving a message containing a NAT-Traversal object. receiving a message containing a NAT-Traversal object.
A possible set of operations for a NAT to process a Query- A possible set of operations for a NAT to process a Query-
encapsulated message is as follows: encapsulated message is as follows:
1. Verify that bindings for the 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.
3. Create bindings for subsequent C-mode signaling (based on the 3. Create bindings for subsequent C-mode signaling (based on the
information in the Network-Layer-Information and Stack- information in the Network-Layer-Information and Stack-
Configuration-Data objects). Configuration-Data objects).
4. Create new Network-Layer-Information and if necessary Stack- 4. Create new Network-Layer-Information and if necessary Stack-
Configuration-Data objects with fields to force D-mode response Configuration-Data objects with fields to force D-mode response
skipping to change at page 71, line 18 skipping to change at page 73, line 30
6. Encapsulate the message according to the normal rules of this 6. Encapsulate the message according to the normal rules of this
specification for the Query-encapsulation. If the S-flag was set specification for the Query-encapsulation. If the S-flag was set
in the original message, the same IP source address selection in the original message, the same IP source address selection
policy should be applied to the forwarded message. policy should be applied to the forwarded message.
7. Forward the message with these new payloads. 7. Forward the message with these new payloads.
A GIST node receiving such a message MUST verify that all mandatory A GIST node receiving such a message MUST verify that all mandatory
objects containing addressing have been translated correctly, or else objects containing addressing have been translated correctly, or else
reject the message with a 'Object Type Error' message reject the message with an 'Object Type Error' message
(Appendix A.4.4.9) with subcode 4 ('Untranslated Object'). The error (Appendix A.4.4.9) with subcode 4 ('Untranslated Object'). The error
message MUST include the NAT-Traversal object as the first TLV after message MUST include the NAT-Traversal object as the first TLV after
the common header (this is true for any other error message generated the common header (this is true for any other error message generated
as a response). Otherwise, the message is processed essentially as as a response). Otherwise, the message is processed essentially as
normal. If no state needs to be updated for the message, the NAT- normal. If no state needs to be updated for the message, the NAT-
Traversal object can be effectively ignored. The other possibility Traversal object can be effectively ignored. The other possibility
is that a Response must be returned, either because the message is is that a Response must be returned, either because the message is
the beginning of a handshake for a new flow, or it is a refresh for the beginning of a handshake for a new flow, or it is a refresh for
existing state. In both cases, the GIST node MUST create the existing state. In both cases, the GIST node MUST create the
Response message in the normal way using the 'local' form of the MRI, Response message in the normal way using the 'local' form of the MRI,
skipping to change at page 72, line 51 skipping to change at page 75, line 14
words, at least one tunnel endpoint must be signaling application words, at least one tunnel endpoint must be signaling application
aware. aware.
In some cases, it is the tunnel exit point (i.e. the node where In some cases, it is the tunnel exit point (i.e. the node where
tunnelled data and downstream signaling packets leave the tunnel) tunnelled data and downstream signaling packets leave the tunnel)
that will wish to carry out the tunnel signaling, but this node will that will wish to carry out the tunnel signaling, but this node will
not have knowledge or control of how the tunnel entry point is not have knowledge or control of how the tunnel entry point is
carrying out the data flow encapsulation. The information about how carrying out the data flow encapsulation. The information about how
the inner MRI/SID relate to the tunnel MRI/SID needs to be carried in the inner MRI/SID relate to the tunnel MRI/SID needs to be carried in
the signaling data from the tunnel entry point (this functionality is the signaling data from the tunnel entry point (this functionality is
the equivalent to the RSVP SESSION_ASSOC object of [12]). In the the equivalent to the RSVP SESSION_ASSOC object of [10]). In the
NSIS protocol suite, these bindings are managed by the signaling NSIS protocol suite, these bindings are managed by the signaling
applications, either implicitly (e.g. by SID re-use) or explicitly applications, either implicitly (e.g. by SID re-use) or explicitly
(by carrying objects that bind the inner and outer SIDs as part of (by carrying objects that bind the inner and outer SIDs as part of
the NSLP payload). the NSLP payload).
7.4. IPv4-IPv6 Transition and Interworking 7.4. IPv4-IPv6 Transition and Interworking
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 [30].) In mixed environments, GIST MUST Dual Stack: (As described in [29].) In mixed environments, GIST MUST
use the same IP version as the flow it is signaling for Query- use the same IP version for Query-encapsulated messages as the
encapsulated messages and SHOULD do so for other signaling also flow it is signaling for, and SHOULD do so for other signaling
(see Section 5.2.2). The IP version used in datagram mode is also (see Section 5.2.2). The IP version used in datagram mode is
closely tied to the IP version used by the data flow, so it is closely tied to the IP version used by the data flow, so it is
intrinsically impossible for a IPv4-only or IPv6-only GIST node to intrinsically impossible for a IPv4-only or IPv6-only GIST node to
support signaling for flows using the other IP version. Hosts support signaling for flows using the other IP version. Hosts
which are dual stack for applications and routers which are dual which are dual stack for applications and routers which are dual
stack for forwarding need GIST implementations which can support stack for forwarding need GIST implementations which can support
both IP versions. Applications with a choice of IP versions might both IP versions. Applications with a choice of IP versions might
select a version based on which could be supported in the network select a version based on which could be supported in the network
by GIST, which could be established by invoking parallel discovery by GIST, which could be established by invoking parallel discovery
procedures. procedures.
Packet Translation: (Applicable to SIIT [6] and NAT-PT [13].) Some Packet Translation: (Applicable to SIIT [5] and NAT-PT [11].) Some
transition mechanisms allow IPv4 and IPv6 nodes to communicate by transition mechanisms allow IPv4 and IPv6 nodes to communicate by
placing packet translators between them. From the GIST placing packet translators between them. From the GIST
perspective, this should be treated essentially the same way as perspective, this should be treated essentially the same way as
any other NAT operation (e.g. between 'public' and 'private' any other NAT operation (e.g. between 'public' and 'private'
addresses) as described in Section 7.2. The translating node addresses) as described in Section 7.2. The translating node
needs to be GIST-aware; it will have to translate the addressing needs to be GIST-aware; it will have to translate the addressing
payloads between IPv4 and IPv6 formats for flows which cross payloads between IPv4 and IPv6 formats for flows which cross
between the two. The translation rules for the fields in the MRI between the two. The translation rules for the fields in the MRI
payload (including e.g. DiffServ-codepoint and flow-label) are as payload (including e.g. DiffServ-codepoint and flow-label) are as
defined in [6]. defined in [5].
Tunnelling: (Applicable to 6to4 [15].) Many transition mechanisms Tunnelling: (Applicable to 6to4 [13].) Many transition mechanisms
handle the problem of how an end to end IPv6 (or IPv4) flow can be handle the problem of how an end to end IPv6 (or IPv4) flow can be
carried over intermediate IPv4 (or IPv6) regions by tunnelling; carried over intermediate IPv4 (or IPv6) regions by tunnelling;
the methods tend to focus on minimising the tunnel administration the methods tend to focus on minimising the tunnel administration
overhead. overhead.
From the GIST perspective, the treatment should be as similar as From the GIST perspective, the treatment should be as similar as
possible to any other IP tunnelling mechanism, as described in possible to any other IP tunnelling mechanism, as described in
Section 7.3. In particular, the end to end flow signaling will Section 7.3. In particular, the end to end flow signaling will
pass transparently through the tunnel, and signaling for the pass transparently through the tunnel, and signaling for the
tunnel itself will have to be managed by the tunnel endpoints. tunnel itself will have to be managed by the tunnel endpoints.
However, additional considerations may arise because of special However, additional considerations may arise because of special
features of the tunnel management procedures. In particular, [16] features of the tunnel management procedures. In particular, [14]
is based on using an anycast address as the destination tunnel is based on using an anycast address as the destination tunnel
endpoint. GIST MAY use anycast destination addresses in the endpoint. GIST MAY use anycast destination addresses in the
Query-encapsulation of D-mode messages if necessary, but MUST NOT Query-encapsulation of D-mode messages if necessary, but MUST NOT
use them in the Network-Layer-Information addressing field; normal use them in the Network-Layer-Information addressing field; normal
unicast addresses MUST be used instead. Note that the addresses unicast addresses MUST be used instead. Note that the addresses
from the IP header are not used by GIST in matching requests and from the IP header are not used by GIST in matching requests and
responses, so there is no requirement to use anycast source responses, so there is no requirement to use anycast source
addresses. addresses.
8. Security Considerations 8. Security Considerations
The security requirement for GIST is to protect the signaling plane The security requirement for GIST is to protect the signaling plane
against identified security threats. For the signaling problem as a against identified security threats. For the signaling problem as a
whole, these threats have been outlined in [25]; the NSIS framework whole, these threats have been outlined in [23]; the NSIS framework
[24] assigns a subset of the responsibilities to the NTLP. The main [22] 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: Signaling message content can be protected Message Protection: Signaling 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 signaling applications provide such protection as a service to signaling applications
between adjacent peers. between adjacent peers.
Routing State Integrity Protection: It is important that signaling Routing State Integrity Protection: It is important that signaling
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 77, line 18 skipping to change at page 79, line 18
messages need to be routed identically to the data flow described by messages need to be routed identically to the data flow described by
the MRI, and the routing state table is the GIST view of how these the MRI, and the routing state table is the GIST view of how these
flows are being routed through the network in the immediate flows are being routed through the network in the immediate
neighbourhood of the node. Routes are only weakly secured (e.g. neighbourhood of the node. Routes are only weakly secured (e.g.
there is no cryptographic binding of a flow to a route), and there is there is no cryptographic binding of a flow to a route), and there is
no authoritative information about flow routes other than the current no authoritative information about flow routes other than the current
state of the network itself. Therefore, consistency between GIST and state of the network itself. Therefore, consistency between GIST and
network routing state has to be ensured by directly interacting with network routing state has to be ensured by directly interacting with
the routing mechanisms to ensure that the signaling peers are the the routing mechanisms to ensure that the signaling 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 [34]. and techniques in this context is provided in [33].
In one direction, peer identification is installed and refreshed only In one direction, peer identification is installed and refreshed only
on receiving a GIST-Reponse message (compare Figure 4). This MUST on receiving a GIST-Response message (compare Figure 4). This MUST
echo the cookie from a previous GIST-Query message, which will have echo the cookie from a previous GIST-Query message, which will have
been sent along the flow path (in datagram mode, i.e. end-to-end been sent along the flow path (in datagram mode, i.e. end-to-end
addressed). Hence, only the true next peer or an on-path attacker addressed). Hence, only the true next peer or an on-path attacker
will be able to generate such a message, provided freshness of the will be able to generate such a message, provided freshness of the
cookie can be checked at the querying node. cookie can be 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
on receiving a GIST-Query message containing addressing information on receiving a GIST-Query message containing addressing information
for the signaling source. However, any node in the network could for the signaling source. However, any node in the network could
generate such a message (indeed, many nodes in the network could be generate such a message (indeed, many nodes in the network could be
skipping to change at page 79, line 4 skipping to change at page 81, line 4
GIST-Confirm message, possibly on a secure channel. If the GIST-Confirm message, possibly on a secure channel. If the
channel exists, the additional delay is one one-way delay and the channel exists, the additional delay is one one-way delay and the
total is no more than the minimal theoretically possible delay of total is no more than the minimal theoretically possible delay of
a three-way handshake, i.e., 1.5 node-to-node round-trip times. a three-way handshake, i.e., 1.5 node-to-node round-trip times.
The delay gets significantly larger if a new connection needs to The delay gets significantly larger if a new connection needs to
be established first. be established first.
2. The Response to the Query message contains a cookie, which is 2. The Response to the Query message contains a cookie, which is
repeated in the Confirm. State is only established for messages repeated in the Confirm. State is only established for messages
that contain a valid cookie. The setup delay is also 1.5 round- that contain a valid cookie. The setup delay is also 1.5 round-
trip times. (This mechanism is similar to that in SCTP [14] and trip times. (This mechanism is similar to that in SCTP [12] and
other modern protocols.) other modern protocols.)
Once a node has decided to establish routing state, there may still Once a node has decided to establish routing state, there may still
be transport and security state to be established between peers. be transport and security state to be established between peers.
This state setup is also vulnerable to denial of service attacks. This state setup is also vulnerable to denial of service attacks.
GIST relies on the lower layer protocols that make up messaging GIST relies on the lower layer protocols that make up messaging
associations to mitigate such attacks. In the current specification, associations to mitigate such attacks. In the current specification,
the querying node is always the one wishing to establish a messaging the querying node is always the one wishing to establish a messaging
association, so it is the responding node that needs to be protected. association, so it is the responding node that needs to be protected.
Signaling applications can use the services provided by GIST to
defend against certain (e.g. flooding) denial of service attacks. In
particular, they can elect to process only messages from peers that
have passed a return routability check or been authenticated at the
messaging association level (see Appendix B.2). Signaling
applications that accept messages under other circumstances (in
particular, before routing state has been fully established at the
GIST level) need to take this into account when designing their
denial of service prevention mechanisms, for example by not creating
local state as a result of processing such messages.
8.5. Requirements on Cookie Mechanisms 8.5. Requirements on Cookie Mechanisms
The requirements on the Query cookie can be summarised as follows: The requirements on the Query cookie can be summarised as follows:
Liveness: The cookie must be live (must change from one handshake to Liveness: The cookie must be live (must change from one handshake to
the next). To prevent replay attacks. the next). To prevent replay attacks.
Unpredictability: The cookie must not be guessable (e.g. not from a Unpredictability: The cookie must not be guessable (e.g. not from a
sequence or timestamp). To prevent direct forgery based on seeing sequence or timestamp). To prevent direct forgery based on seeing
a history of captured messages. a history of captured messages.
skipping to change at page 80, line 12 skipping to change at page 82, line 26
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: modified Confirm. The routing state here includes:
The NLI of the Query The NLI of the Query
The MRI/NSLPID for the messaging The MRI/NSLPID for the messaging
The interface on which the Query was received The interface on 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
random number which is unique for this routing state machine strong random number which is unique for this routing state machine
handshake. A node SHOULD implement this or an equivalently strong handshake. A node SHOULD implement this or an equivalently strong
mechanism. mechanism.
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 SHOULD implement this or an equivalently strong mechanism. A node SHOULD 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
a timestamp like SCTP. Another is to use a local secret with (rapid) a timestamp like SCTP. Another is to give the local secret a (rapid)
rollover, with the liveness data as the generation number of the rollover, with the liveness data as the generation number of the
secret, like IKEv2. In both cases, the liveness data has to be secret, like IKEv2. In both cases, the liveness data has to be
carried outside the hash, to allow the hash to be verified at the carried outside the hash, to allow the hash to be verified at the
Responder. Another approach is to replace the hash with encryption Responder. Another approach is to replace the hash with encryption
under a locally known secret, in which case the liveness data does under a locally known secret, in which case the liveness data does
not need to be carried in the clear. Any symmetric cipher immune to not need to be carried in the clear. Any symmetric cipher immune to
known plaintext attacks can be used. known plaintext attacks can be used.
If a node recieves a message for which cookie validation fails, it To support the validation simplicity requirement, the Responder can
check the liveness data to filter out some blind (flooding) attacks
before beginning any cryptographic cookie verification. To support
this usage, the liveness data must be carried in the clear and not be
easily guessable; this rules out the timestamp approach, and suggests
the use of sequence of secrets with the liveness data identifying the
position in the sequence. The secret strength and rollover frequency
must be high enough that the secret cannot be brute-forced during its
lifetime. Note that any node can use a Query to discover the current
liveness data, so it remains hard to defend against sophisticated
attacks which disguise such 'probes' within a flood of Queries from
forged source addresses. Therefore, it remains important to use an
efficient hashing mechanism or equivalent.
If a node receives a message for which cookie validation fails, it
MAY return an "Object Value Error" error message (Appendix A.4.4.10) MAY return an "Object Value Error" error message (Appendix A.4.4.10)
with subcode 4 ("Invalid Cookie") to the sender, as well as dropping with subcode 4 ("Invalid Cookie") to the sender, as well as dropping
the message. However, doing so in general makes a node a source of the message. However, doing so in general makes a node a source of
backscatter. Therefore, this SHOULD only be enabled selectively, backscatter. Therefore, this SHOULD only be enabled selectively,
e.g. during initial deployment or debugging. e.g. during initial deployment or debugging.
8.6. Residual Threats 8.6. Security Protocol Selection Policy
This specification defines a single mandatory-to-implement security
protocol (TLS, Section 5.7.3). However, it is possible to define
additional security protocols in the future, for example to allow re-
use with other types of credentials, or migrate towards protocols
with stronger security properties. In addition, use of any security
protocol for a messaging association is optional. Security protocol
selection is carried out as part of the GIST handshake mechanism
(Section 4.4.1).
The selection process may be vulnerable to downgrade attacks, where a
man in the middle modifies the capabilities offered in the Query or
Response to mislead the peers into accepting a lower level of
protection than is achievable. There is a two part defence against
such attacks (the following is based the same concepts as [18]):
1. The Response does not depend on the Stack-Proposal in the Query
(see Section 5.7.1). Therefore, tampering with the Query message
has no effect on the resulting messaging association
configuration.
2. The Responding node's Stack-Proposal is echoed in the Confirm.
The Responding node checks this to validate that the proposal it
made in the Response is the same as the one received by the
Querying node. (Note that as a consequence of the previous
point, the Responding node does not have to remember the proposal
explicitly, since it is a static function of local policy.)
The validity of the second part depends on the strength of the
security protection provided for the Confirm message. If the
Querying node is prepared to create messaging associations with null
security properties (e.g. TCP only), the defence is ineffective,
since the man in the middle can re-insert the original Responder's
Stack-Proposal, and the Responding node will assume that the minimal
protection is a consequence of Querying node limitations. However,
if the messaging association provides at least integrity protection
that cannot be broken in real-time, the Confirm cannot be modified in
this way. Therefore, provided that the Querying node applies a
security policy on the messaging association protocols it will create
that ensures at least this minimal level of protection is met, it can
be assured that the capability discovery process will result in the
setup of a messaging association with the correct security properties
as appropriate for the two peers involved.
8.7. Residual Threats
Taking the above security mechanisms into account, the main residual Taking the above security mechanisms into account, the main residual
threats against NSIS are three types of on-path attack. threats against NSIS are three types of on-path attack.
An on-path attacker who can intercept the initial Query can do most An on-path attacker who can intercept the initial Query can do most
things it wants to the subsequent signaling. It is very hard to things it wants to the subsequent signaling. It is very hard to
protect against this at the GIST level; the only defence is to use protect against this at the GIST level; the only defence is to use
strong messaging association security to see whether the Responding strong messaging association security to see whether the Responding
node is authorised to take part in NSLP signaling exchanges. To some node is authorised to take part in NSLP signaling exchanges. To some
extent, this behaviour is logically indistinguishable from correct extent, this behaviour is logically indistinguishable from correct
operation, so it is easy to see why defence is difficult. Note than operation, so it is easy to see why defence is difficult. Note that
an on-path attacker of this sort can do anything to the traffic as an on-path attacker of this sort can do anything to the traffic as
well as the signaling. Therefore, the additional threat induced by well as the signaling. Therefore, the additional threat induced by
the signaling weakness seems tolerable. the signaling weakness seems tolerable.
At the NSLP level, there is a concern about transitivity of trust of At the NSLP level, there is a concern about transitivity of trust of
correctness of routing along the signaling chain. The NSLP at the correctness of routing along the signaling 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). However, an on-path peer (or a node delegated by the on-path node). However,
it has no assurance that the node beyond the responder is also on- it has no assurance that the node beyond the responder is also on-
path, or that the MRI (in particular) is not being modified by the path, or that the MRI (in particular) is not being modified by the
skipping to change at page 84, line 42 skipping to change at page 88, line 42
1024-1999: Specification Required 1024-1999: Specification Required
2000-2047: Private/Experimental Use 2000-2047: Private/Experimental Use
2048-4095: Reserved 2048-4095: Reserved
When a new object type is defined, the extensibility bits (A/B, When a new object type is defined, the extensibility bits (A/B,
see Appendix A.2.1) must also be defined. see Appendix A.2.1) must also be defined.
Message Routing Methods: GIST allows the idea of multiple message Message Routing Methods: GIST allows multiple message routing methods
routing methods (see Section 3.3). The message routing method is (see Section 3.3). The message routing method is indicated in the
indicated in the leading byte of the MRI object (Appendix A.3.1). leading byte of the MRI object (Appendix A.3.1). This
This specification defines the following values: specification defines the following values:
+---------+------------------------+ +---------+------------------------+
| MRM | Message Routing Method | | MRM | Message Routing Method |
+---------+------------------------+ +---------+------------------------+
| 0 | Path Coupled MRM | | 0 | Path Coupled MRM |
| | | | | |
| 1 | Loose End MRM | | 1 | Loose End MRM |
+---------+------------------------+ +---------+------------------------+
Allocation policies for further values are as follows: Allocation policies for further values are as follows:
skipping to change at page 85, line 45 skipping to change at page 89, line 45
Allocation policies for further values are as follows: Allocation policies for further values are as follows:
3-63: Standards Action 3-63: Standards Action
64-119: Expert Review 64-119: Expert Review
120-127: Private/Experimental Use 120-127: Private/Experimental Use
128-255: Reserved 128-255: Reserved
Allocating a new MA-Protocol-ID requires defining the higher layer Allocating a new MA-Protocol-ID requires defining the format for
addressing information (if any) in the Stack-Configuration-Data the MA-protocol-options field (if any) in the Stack-Configuration-
object that is needed to define its configuration. Note that the Data object that is needed to define its configuration. Note that
MA-Protocol-ID is not an IP Protocol number (indeed, some of the the MA-Protocol-ID is not an IP Protocol number (indeed, some of
messaging association protocols - such as TLS - do not have an IP the messaging association protocols - such as TLS - do not have an
Protocol number). IP Protocol number).
Error Codes/Subcodes: There is a 2 byte error code and 1 byte subcode Error Codes/Subcodes: There is a 2 byte error code and 1 byte subcode
in the Value field of the Error object (Appendix A.4.1). Error in the Value field of the Error object (Appendix A.4.1). Error
codes 1-12 are defined in Appendix A.4.4 together with subcodes codes 1-12 are defined in Appendix A.4.4 together with subcodes
0-3 for code 1, 0-4 for code 9 and 0-5 for code 10. Additional 0-3 for code 1, 0-4 for code 9, 0-5 for code 10, and 0-2 for code
codes and subcodes are allocated on a first-come, first served 12. Additional codes and subcodes are allocated on a first-come,
basis. When a new error code/subcode combination is allocated, first served basis. When a new error code/subcode combination is
the Error Class and the format of any associated error-specific allocated, the Error Class and the format of any associated error-
information must also be defined. specific information must also be defined.
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, Luis Cordeiro, Elwyn Davies, Braden, Marcus Brunner, Benoit Campedel, Luis Cordeiro, Elwyn Davies,
Christian Dickmann, Pasi Eronen, Xiaoming Fu, Ruediger Geib, Eleanor Christian Dickmann, Pasi Eronen, Alan Ford, Xiaoming Fu, Ruediger
Hepworth, Cheng Hong, Cornelia Kappler, Georgios Karagiannis, Chris Geib, Eleanor Hepworth, Thomas Herzog, Cheng Hong, Jia Jia, Cornelia
Lang, John Loughney, Allison Mankin, Jukka Manner, Pete McCann, Kappler, Georgios Karagiannis, Chris Lang, John Loughney, Allison
Andrew McDonald, Glenn Morrow, Dave Oran, Andreas Pashaldis, Henning Mankin, Jukka Manner, Pete McCann, Andrew McDonald, Glenn Morrow,
Peters, Tom Phelan, Takako Sanda, Charles Shen, Melinda Shore, Martin Dave Oran, Andreas Pashalidis, Henning Peters, Tom Phelan, Takako
Stiemerling, Mike Thomas, Hannes Tschofenig, Sven van den Bosch, Sanda, Charles Shen, Melinda Shore, Martin Stiemerling, Martijn
Michael Welzl, and Lars Westberg. In particular, Hannes Tschofenig Swanink, Mike Thomas, Hannes Tschofenig, Sven van den Bosch, Michael
Welzl, Lars Westberg, and Mayi Zoumaro-djayoon. Parts of the TLS
usage description (Section 5.7.3) were derived from the Diameter base
protocol specification, RFC3588. In addition, Hannes Tschofenig
provided a detailed set of review comments on the security section, provided a detailed set of review comments on the security section,
and Andrew McDonald provided the formal description for the initial and Andrew McDonald provided the formal description for the initial
packet formats. Chris Lang's implementation work provided objective packet formats. Chris Lang's implementation work provided objective
feedback on the clarity and feasibility of the specification, and he feedback on the clarity and feasibility of the specification, and he
also provided the state machine description and the initial error also provided the state machine description and the initial error
catalogue and formats. We look forward to inputs and comments from catalogue and formats.
many more in the future.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [1] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [3] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
Specifications: ABNF", RFC 2234, November 1997.
[4] 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.
[5] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [4] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999. RFC 2711, October 1999.
[6] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", [5] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC 2765, February 2000. RFC 2765, February 2000.
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[8] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", [8] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005. draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005.
11.2. Informative References 11.2. Informative References
[9] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, [9] 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.
[10] Kent, S. and R. Atkinson, "Security Architecture for the [10] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
Internet Protocol", RFC 2401, November 1998.
[11] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[12] 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.
[13] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - [11] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000. Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[14] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [12] 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.
Paxson, "Stream Control Transmission Protocol", RFC 2960, Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000. October 2000.
[15] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via [13] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001. IPv4 Clouds", RFC 3056, February 2001.
[16] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [14] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001. RFC 3068, June 2001.
[17] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, [15] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001. September 2001.
[18] Grossman, D., "New Terminology and Clarifications for [16] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002. Diffserv", RFC 3260, April 2002.
[19] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [17] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[20] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
Z., and J. Rosenberg, "Signaling Compression (SigComp)", Z., and J. Rosenberg, "Signaling Compression (SigComp)",
RFC 3320, January 2003. RFC 3320, January 2003.
[21] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. [18] 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.
[22] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN [19] 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.
[23] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL [20] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-08 (work in progress),
September 2005.
[21] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004. Security Mechanism (GTSM)", RFC 3682, February 2004.
[24] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [22] 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.
[25] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next [23] 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.
[26] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", [24] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for
draft-ietf-dccp-spec-11 (work in progress), March 2005. Transport Layer Security (TLS)", RFC 4279, December 2005.
[27] Conta, A., "Internet Control Message Protocol (ICMPv6) for the [25] Kohler, E., "Datagram Congestion Control Protocol (DCCP)",
draft-ietf-dccp-spec-13 (work in progress), December 2005.
[26] Conta, A., "Internet Control Message Protocol (ICMPv6) for the
Internet Protocol Version 6 (IPv6) Specification", Internet Protocol Version 6 (IPv6) Specification",
draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005. draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005.
[28] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol [27] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-07 (work in progress), (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in progress),
July 2005. February 2006.
[29] Bosch, S., "NSLP for Quality-of-Service signalling", [28] Manner, J., "NSLP for Quality-of-Service signalling",
draft-ietf-nsis-qos-nslp-07 (work in progress), July 2005. draft-ietf-nsis-qos-nslp-09 (work in progress), February 2006.
[30] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for [29] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 (work in IPv6 Hosts and Routers", RFC 4213, October 2005.
progress), March 2005.
[31] Kent, S. and K. Seo, "Security Architecture for the Internet [30] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), Protocol", RFC 4301, December 2005.
April 2005.
[32] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", [31] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
draft-ietf-secsh-architecture-22 (work in progress), draft-ietf-secsh-architecture-22 (work in progress),
March 2005. March 2005.
[33] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 [32] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-04
(work in progress), June 2005. (work in progress), October 2005.
[34] Nikander, P., "Mobile IP version 6 Route Optimization Security [33] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Design Background", draft-ietf-mip6-ro-sec-03 (work in Nordmark, "Mobile IP Version 6 Route Optimization Security
progress), May 2005. Design Background", RFC 4225, December 2005.
[34] Floyd, S. and V. Jacobson, "The Synchronisation of Periodic
Routing Messages", SIGCOMM Symposium on Communications
Architectures and Protocols pp. 33--44, September 1993.
[35] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [35] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", draft-rescorla-dtls-05 (work in progress), Security", draft-rescorla-dtls-05 (work in progress),
June 2005. June 2005.
[36] Loughney, J., "NSIS Extensibility Model", [36] Loughney, J., "NSIS Extensibility Model",
draft-loughney-nsis-ext-01 (work in progress), July 2005. draft-loughney-nsis-ext-01 (work in progress), July 2005.
Appendix A. Bit-Level Formats and Error Messages Appendix A. Bit-Level Formats and Error Messages
skipping to change at page 91, line 33 skipping to change at page 95, line 33
A.1. The GIST Common Header A.1. The GIST Common Header
This header precedes all GIST messages. It has a fixed format, as This header precedes all GIST messages. It has a fixed format, as
shown below. shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | GIST hops | Message length | | Version | GIST hops | Message length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signaling Application ID | Type |S|R|E| Reserved| | NSLPID | Type |S|R|E| Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message length = the total number of words in the message after Message length = the total number of words in the message after
the common header itself the common header itself
Type = the GIST message type (Query, Response, etc.) Type = the GIST message type (Query, Response, etc.)
S flag = S=1 if the IP source address is the same as the S flag = S=1 if the IP source address is the same as the
signaling source address, S=0 if it is different signaling source address, S=0 if it is different
R flag = R=1 if a reply to this message is explicitly R flag = R=1 if a reply to this message is explicitly
requested requested
E flag = E=1 if is the message was explicitly routed E flag = E=1 if the message was explicitly routed
Section 7.1.4 Section 7.1.4
The rules governing the use of the R-flag depend on the GIST message The rules governing the use of the R-flag depend on the GIST message
type. It MUST always be set (R=1) in Query messages (these always type. It MUST always be set (R=1) in Query messages (these always
elicit a Response), and never in Confirm, Data or Error messages. It elicit a Response), and never in Confirm, Data or Error messages. It
is optional in a MA-Hello; if set, another MA-Hello is sent in reply. is optional in a MA-Hello; if set, another MA-Hello is sent in reply.
It is optional in a Response (but MUST be set if the Response It is optional in a Response (but MUST be set if the Response
contains a Responder cookie); if set, a Confirm is sent in reply. contains a Responder cookie); if set, a Confirm is sent in reply.
Parsing failures may be caused by unknown Version or Type values, Parsing failures may be caused by unknown Version or Type values,
inconsistent R flag setting, or a Message Length inconsistent with inconsistent R flag setting, or a Message Length inconsistent with
the set of objects carried. In all cases the receiver MUST if the set of objects carried. In all cases the receiver MUST if
possible return an "Common Header Parse Error" message possible return a "Common Header Parse Error" message
(Appendix A.4.4.1) with the appropriate subcode, and not process the (Appendix A.4.4.1) with the appropriate subcode, and not process the
message further. message further.
A.2. General Object Format A.2. General Object Format
Each object begins with a fixed header giving the object Type and Each object begins with a fixed header giving the object Type and
object Length. This is followed by the object Value, which is a object Length. This is followed by the object Value, which is a
whole number of 32-bit words long. whole number of 32-bit words long.
0 1 2 3 0 1 2 3
skipping to change at page 92, line 43 skipping to change at page 96, line 43
consistent with the contents of the object, an "Object Value consistent with the contents of the object, an "Object Value
Error" message (Appendix A.4.4.10) with subcode 0 "Incorrect Error" message (Appendix A.4.4.10) with subcode 0 "Incorrect
Length" MUST be returned and the message dropped. Length" MUST be returned and the message dropped.
o Value is (therefore) a whole number of 32 bit words. If there is o Value is (therefore) a whole number of 32 bit words. If there is
any padding required, the length and location must be defined by any padding required, the length and location must be defined by
the object-specific format information; objects which contain the object-specific format information; objects which contain
variable length (e.g. string) types may need to include additional variable length (e.g. string) types may need to include additional
length subfields to do so. length subfields to do so.
Any part of the object used for padding or defined as reserved MUST Any part of the object used for padding or defined as reserved
be set to 0 on transmission and MUST be ignored on reception. (marked 'Reserved' or 'Rsv' in the diagrams below) MUST be set to 0
on transmission and MUST be ignored on reception.
A.2.1. Object Extensibility A.2.1. Object Extensibility
The leading two bits of the common TLV header are used to signal the The leading two bits of the TLV header are used to signal the desired
desired treatment for objects whose treatment has not been defined in treatment for objects whose Type field is unknown at the receiver.
the protocol specification in question (i.e. whose Type field is The following three categories of object have been identified, and
unknown at the receiver). The following three categories of object are described here.
have been identified, and are described here.
AB=00 ("Mandatory"): If the object is not understood, the entire AB=00 ("Mandatory"): If the object is not understood, the entire
message containing it MUST be rejected with a "Object Type Error" message containing it MUST be rejected with an "Object Type Error"
message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object"). message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object").
AB=01 ("Ignore"): If the object is not understood, it MUST be deleted AB=01 ("Ignore"): If the object is not understood, it MUST be deleted
and the rest of the message processed as usual. and the rest of the message processed as usual.
AB=10 ("Forward"): If the object is not understood, it MUST be AB=10 ("Forward"): If the object is not understood, it MUST be
retained unchanged in any message forwarded as a result of message retained unchanged in any message forwarded as a result of message
processing, but not stored locally. processing, but not stored locally.
The combination AB=11 is reserved. Note that the concept of The combination AB=11 is reserved.
retaining an unknown object and including it in refresh messages
further up or down the signaling path does not apply to GIST, since
refresh operations only take place between adjacent peers.
A.3. GIST TLV Objects A.3. GIST TLV Objects
A.3.1. Message-Routing-Information A.3.1. Message-Routing-Information
Type: Message-Routing-Information Type: Message-Routing-Information
Length: Variable (depends on message routing method) Length: Variable (depends on message routing method)
0 1 2 3 0 1 2 3
skipping to change at page 94, line 25 skipping to change at page 98, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Reserved | Flow Label : : Reserved | Flow Label :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SPI : : SPI :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Source Port : Destination Port : : Source Port : Destination Port :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The flags are: The flags are:
P - P=1 means that IP Protocol should be interpreted P - P=1 means that IP Protocol should be interpreted
T - T=1 means that DS-Field should be interpreted; see [4] and [18] T - T=1 means that DS-Field should be interpreted; see [3] and [16]
F - F=1 means that flow Label is present and should be interpreted F - F=1 means that flow Label is present and should be interpreted
S - S=1 means that SPI is present and should be interpreted; see [10] S - S=1 means that SPI is present and should be interpreted; see [30]
A/B - Source/Destination Port (see below) A/B - Source/Destination Port (see below)
D - Direction of message relative to flow D - Direction of message relative to flow
The source and destination addresses are always present and of the The source and destination addresses are always present and of the
same type; their length depends on the value in the IP-Ver field. In same type; their length depends on the value in the IP-Ver field. In
the normal case where the MRI refers only to traffic between specific the normal case where the MRI refers only to traffic between specific
host addresses, the Source/Dest Prefix values would both be 32/128 host addresses, the Source/Dest Prefix values would both be 32/128
for IPv4/6 respectively. for IPv4/6 respectively.
In the case of IPv6, the Protocol field refers to the true upper In the case of IPv6, the Protocol field refers to the true upper
layer protocol carried by the packets, i.e. excluding any IP option layer protocol carried by the packets, i.e. excluding any IP option
headers. This is therefore not necessarily the same as the Next headers. This is therefore not necessarily the same as the Next
Header value from the base IPv6 header. Header value from the base IPv6 header.
F may only be set if IP-Ver is 6. If F is not set, the entire 32 bit F may only be set if IP-Ver is 6. If F is not set, the entire 32 bit
word for the FLow Label is absent. word for the Flow Label is absent.
The S/A/B flags can only be set if P is set. The SPI field is only The S/A/B flags can only be set if P is set. The SPI field is only
present if the S flag is set. present if the S flag is set.
If either of A, B is set (value=1), the word containing the port If either of A, B is set (value=1), the word containing the port
numbers is included in the object. However, the contents of each numbers is included in the object. However, the contents of each
field is only significant if the corresponding flag is set; field is only significant if the corresponding flag is set;
otherwise, the contents of the field is regarded as padding, and the otherwise, the contents of the field is regarded as padding, and the
MRI refers to all ports (i.e. acts as a wildcard). If the flag is MRI refers to all ports (i.e. acts as a wildcard). If the flag is
set and Port=0x0000, the MRI will apply to a specific port, whose set and Port=0x0000, the MRI will apply to a specific port, whose
skipping to change at page 97, line 25 skipping to change at page 101, line 25
bytes. bytes.
If there are no profiles (i.e. all bytes are null), then a "Object If there are no profiles (i.e. all bytes are null), then a "Object
Value Error" message (Appendix A.4.4.10) with subcode 3 ("Empty Value Error" message (Appendix A.4.4.10) with subcode 3 ("Empty
List") MUST be returned and the message dropped. List") MUST be returned and the message dropped.
A.3.5. Stack-Configuration-Data A.3.5. Stack-Configuration-Data
Type: Stack-Configuration-Data Type: Stack-Configuration-Data
Length: Variable (depends on number of protocols and size of each Length: Variable (depends on number of protocols and size of each MA-
protocol configuration data) protocol-options field)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HL-Count | Reserved | | MPO-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MA-Hold-Time | | MA-Hold-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Higher-Layer-Information 1 // // MA-protocol-options 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Higher-Layer-Information N // // MA-protocol-options N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MA-Hold-Time = the time for which the messaging association will MA-Hold-Time = the time for which the messaging association will
be held open without traffic or a hello message. be held open without traffic or a hello message.
Given in milliseconds. Given in milliseconds.
HL-Count = the number of higher-layer-information fields MPO-Count = the number of MA-protocol-options fields present
(these contain their own length information) (these contain their own length information)
The higher layer information fields are formatted as follows: The MA-protocol-options fields are formatted as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MA-Protocol-ID | Proposal | Length |D| Reserved | |MA-Protocol-ID | Profile | Length |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Higher-Layer-Addressing // // Options Data //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MA-Protocol-ID = Protocol identifier as described in MA-Protocol-ID = Protocol identifier as described in
Section 5.7 Section 5.7
. .
Proposal = Tag indicating which proposal from the accompanying Profile = Tag indicating which profile from the accompanying
Stack-Proposal object this applies to. Proposals Stack-Proposal object this applies to. Profiles
are numbered from 1 upwards; the special value 0 are numbered from 1 upwards; the special value 0
indicates 'applies to all proposals'. indicates 'applies to all profiles'.
Length = the byte length of higher layer addressing Length = the byte length of MA-protocol-options field
information that follows. This will be zero-padded that follows. This will be zero-padded
up to the next word boundary. up to the next word boundary.
D flag = If set (D=1), this protocol MUST not be used for a D flag = If set (D=1), this protocol MUST not be used for a
messaging assocation. messaging association.
Note that the format of the higher-layer-addressing data may differ Note that the format of the options data may differ depending on
depending on whether the object is in a GIST-Query or GIST-Response. whether the field is in a GIST-Query or GIST-Response.
A.3.6. Query Cookie A.3.6. Query Cookie
Type: Query-Cookie Type: Query-Cookie
Length: Variable (selected by querying node) Length: Variable (selected by querying node)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 101, line 17 skipping to change at page 105, line 17
C - C=1 means a debug Comment is present after header. C - C=1 means a debug Comment is present after header.
D - D=1 means the original message was received in D-Mode D - D=1 means the original message was received in D-Mode
Q - Q=1 means the original message was received Q-Mode encapsulated Q - Q=1 means the original message was received Q-Mode encapsulated
(can't be set if D=0). (can't be set if D=0).
A GIST Error object contains an error-class (see Appendix A.4.3), an A GIST Error object contains an error-class (see Appendix A.4.3), an
error-code, an error-subcode, and as much information about the error-code, an error-subcode, and as much information about the
message which triggered the error as is available. This information message which triggered the error as is available. This information
MUST include the Common header of the original message and SHOULD MUST include the Common header of the original message and SHOULD
also include the Session Id and MRI objects if these could be decoded also include the Session Id and MRI objects if these could be decoded
correctlty. These objects are included in their entirety, except for correctly. These objects are included in their entirety, except for
their TLV Headers. their TLV Headers.
The Info Count field contains the number of Additional Information The Info Count field contains the number of Additional Information
fields in the object. This count is usually 0 or 1, but may be more fields in the object. This count is usually 0 or 1, but may be more
for certain messages; the precise set of fields to include is defined for certain messages; the precise set of fields to include is defined
with the error code/subcode. The field formats are given in with the error code/subcode. The field formats are given in
Appendix A.4.2 and their use for the different errors is given in the Appendix A.4.2 and their use for the different errors is given in the
error catalogue Appendix A.4.4. The Debugging Comment is a null- error catalogue Appendix A.4.4. The Debugging Comment is a null-
terminated UTF-8 string, padded if necessary to a whole number of 32- terminated UTF-8 string, padded if necessary to a whole number of 32-
bit words with more null characters. bit words with more null characters.
skipping to change at page 102, line 30 skipping to change at page 106, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object provides information about the type of object which This object provides information about the type of object which
caused the error. caused the error.
Object Value Info: Object Value Info:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | Real Object Length | Offset | | Rsv | Real Object Length | Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Object // // Object //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Real Object Length: Since the length in the original TLV header Real Object Length: Since the length in the original TLV header
may be inaccurate, this field provides the actual may be inaccurate, this field provides the actual
length of the object (including the TLV Header) length of the object (including the TLV Header)
included in the error message. included in the error message.
Offset: The byte in the object at which the GIST node Offset: The byte in the object at which the GIST node
found the error. found the error.
skipping to change at page 103, line 5 skipping to change at page 107, line 5
This object carries information about a TLV object which was found This object carries information about a TLV object which was found
to be invalid in the original message. An error message may contain to be invalid in the original message. An error message may contain
more than one Object Value Info object. more than one Object Value Info object.
A.4.3. Error Classes A.4.3. Error Classes
The first byte of the error object, "Error Class", indicates the The first byte of the error object, "Error Class", indicates the
severity level. The currently defined severity levels are: severity level. The currently defined severity levels are:
Informational: response data which should not be thought of as 0 (Informational): response data which should not be thought of as
changing the condition of the protocol state machine. changing the condition of the protocol state machine.
Success: response data which indicates that the message being 1 (Success): response data which indicates that the message being
responded to has been processed successfully in some sense. responded to has been processed successfully in some sense.
Protocol-Error: the message has been rejected because of a protocol 2 (Protocol-Error): the message has been rejected because of a
error (e.g. an error in message format). protocol error (e.g. an error in message format).
Transient-Failure: the message has been rejected because of a 3 (Transient-Failure): the message has been rejected because of a
particular local node status which may be transient (i.e. it may particular local node status which may be transient (i.e. it may
be worthwhile to retry after some delay). be worthwhile to retry after some delay).
Permanent-Failure: the message has been rejected because of local 4 (Permanent-Failure): the message has been rejected because of local
node status which will not change without additional out of band node status which will not change without additional out of band
(e.g. management) operations. (e.g. management) operations.
Additional error class values are reserved. Additional error class values are reserved.
The allocation of error classes to particular errors is not precise; The allocation of error classes to particular errors is not precise;
the above descriptions are deliberately informal. Actual error the above descriptions are deliberately informal. Actual error
processing should take into account the specific error in question; processing should take into account the specific error in question;
the error class may be useful supporting information (e.g. in network the error class may be useful supporting information (e.g. in network
debugging). debugging).
A.4.4. Error Catalogue A.4.4. Error Catalogue
This section lists all the possible GIST errors, including when they This section lists all the possible GIST errors, including when they
are raised and what additiona information fields should be carried in are raised and what additional information fields should be carried
the error object. in the error object.
A.4.4.1. Common Header Parse Error A.4.4.1. Common Header Parse Error
Class: Protocol-Error Class: Protocol-Error
Code: 1 Code: 1
Additional Info: Depends on subcode Additional Info: Depends on subcode
This message is sent if a GIST node receives a message where the This message is sent if a GIST node receives a message where the
common header cannot be parsed correctly, or where an error in the common header cannot be parsed correctly, or where an error in the
overall message format is detected. Note that in this case the overall message format is detected. Note that in this case the
skipping to change at page 104, line 51 skipping to change at page 108, line 51
This message is sent if a GIST node receives a message over an MA This message is sent if a GIST node receives a message over an MA
which is not associated with the MRI/NSLPID/SID combination in the which is not associated with the MRI/NSLPID/SID combination in the
message. message.
A.4.4.5. No Routing State A.4.4.5. No Routing State
Class: Protocol-Error Class: Protocol-Error
Code: 5 Code: 5
Additional Info: None Additional Info: None
This message is sent if a node receives a message for which there is This message is sent if a node receives a message for which routing
no matching routing state (and therefore no appropriate Q/R-SM). state should exist, but has not yet been created (and thus there is
no appropriate Q/R-SM). This can occur either on receiving a
This can occur either at a Querying node which receives an unexpected Response to an unknown Query, or on receiving a Data message at a
Response message, or at a Responding node which receives an node whose policy requires routing state to exist before such
unexpected Data message. messages can be accepted. See also Section 6.1 and Section 6.3.
A.4.4.6. Unknown NSLPID A.4.4.6. Unknown NSLPID
Class: Permanent-Failure Class: Permanent-Failure
Code: 6 Code: 6
Additional Info: None Additional Info: None
This message is sent if a router receives a directly addressed This message is sent if a router receives a directly addressed
message for an NSLP which it does not support. message for an NSLP which it does not support.
skipping to change at page 106, line 11 skipping to change at page 110, line 11
message containing multiple instances of an object which may only message containing multiple instances of an object which may only
appear once in a message (in the current specification this appear once in a message (in the current specification this
applies to all objects). applies to all objects).
1: Unrecognised Object: This subcode is used if a GIST node receive a 1: Unrecognised Object: This subcode is used if a GIST node receive a
message containing an object which it does not support, and the message containing an object which it does not support, and the
extensibility flags AB=00. extensibility flags AB=00.
2: Missing Object: This subcode is used if a GIST node receives a 2: Missing Object: This subcode is used if a GIST node receives a
message which is missing one or more mandatory objects. This message which is missing one or more mandatory objects. This
message is also sent if a Stack Proposal is sent without a message is also sent if a Stack-Proposal is sent without a
matching Stack Configuration Data object when one was necessary, matching Stack-Configuration-Data object when one was necessary,
or vice versa. or vice versa.
3: Invalid Object: This subcode is used if the object type is known, 3: Invalid Object: This subcode is used if the object type is known,
but it is not valid for this particular GIST message type. but it is not valid for this particular GIST message type.
4: Untranslated Object: This subcode is used if the object type is 4: Untranslated Object: This subcode is used if the object type is
known, but it is mandatory to interpret, contains addressing data, known and is mandatory to interpret, but it contains addressing
but has not been translated by an intervening NAT. data which has not been translated by an intervening NAT.
A.4.4.10. Object Value Error A.4.4.10. Object Value Error
Class: Protocol-Error Class: Protocol-Error
Code: 10 Code: 10
Additional Info: Object Value Info Additional Info: Object Value Info
This message is sent if a router receives a packet containing an This message is sent if a router receives a packet containing an
object which cannot be properly parsed. The message contains a object which cannot be properly parsed. The message contains a
single Object Value Info object, unless otherwise stated below. This single Object Value Info object, unless otherwise stated below. This
skipping to change at page 106, line 44 skipping to change at page 110, line 44
length calculated from the object contents. length calculated from the object contents.
1: Value Not Supported: The value of a field is not supported by the 1: Value Not Supported: The value of a field is not supported by the
GIST node. GIST node.
2: Invalid Flag-Field Combination: An object contains an invalid 2: Invalid Flag-Field Combination: An object contains an invalid
combination of flags and/or fields. At the moment this only combination of flags and/or fields. At the moment this only
relates to the Path-Coupled MRM object, but in future there may be relates to the Path-Coupled MRM object, but in future there may be
more. more.
3: Empty List: At the moment this only relates to Stack Proposals. 3: Empty List: At the moment this only relates to Stack-Proposals.
The error message is sent if a stack proposal with a length > 0 (a The error message is sent if a stack proposal with a length > 0 (a
length of 0 is handled as "Value Not Supported") contains only length of 0 is handled as "Value Not Supported") contains only
null bytes. null bytes.
4: Invalid Cookie: The message contains a cookie which could not be 4: Invalid Cookie: The message contains a cookie which could not be
verified by the node. verified by the node.
5: SP-SCD Mismatch: This subcode is used if a GIST node receives a 5: SP-SCD Mismatch: This subcode is used if a GIST node receives a
message in which the data in the Stack Proposal object is message in which the data in the Stack-Proposal object is
inconsistent with the information in the Stack Configuration Data inconsistent with the information in the Stack Configuration Data
object. In this case, both the Stack Proposal object and Stack object. In this case, both the Stack-Proposal object and Stack-
Configuration Data object are included in the message, in separate Configuration-Data object are included in the message, in separate
Object Value Info fields. Object Value Info fields.
A.4.4.11. Invalid IP TTL A.4.4.11. Invalid IP TTL
Class: Permanent-Failure Class: Permanent-Failure
Code: 11 Code: 11
Additional Info: None Additional Info: None
This error indicates that a message was received with an IP-TTL This error indicates that a message was received with an IP-TTL
outside an acceptable range; for example, that an upstream Query was outside an acceptable range; for example, that an upstream Query was
received with an IP-TTL of less than 254 (i.e. more than one IP hop received with an IP-TTL of less than 254 (i.e. more than one IP hop
from the sender). The actual IP distance can be derived from the IP- from the sender). The actual IP distance can be derived from the IP-
TTL information in the NLI object carried in the same message. TTL information in the NLI object carried in the same message.
A.4.4.12. MRI Too Wild A.4.4.12. MRI Validation Failure
Class: Permanent-Failure Class: Permanent-Failure
Code: 12 Code: 12
Additional Info: Object Value Info Additional Info: Object Value Info
This error indicates that a message was received with an MRI that This error indicates that a message was received with an MRI that
contained too much wildcarding (e.g. too short a destination address could not be accepted, e.g. because of too much wildcarding or
prefix) to be forwarded correctly down a single path. The Object failing some validation check (cf. Section 5.8.1.2). The Object
Value Info includes the MRI so the error originator can indicate a Value Info includes the MRI so the error originator can indicate the
part of the MRI which includes too much wildcarding. part of the MRI which caused the problem. The error code is divided
into subcodes as follows:
Appendix B. API between GIST and NSLP 0: MRI Too Wild: The MRI contained too much wildcarding (e.g. too
short a destination address prefix) to be forwarded correctly down
a single path.
This appendix provides an abstract API between GIST and NSLPs. It 1: IP Version Mismatch: The MRI in a path-coupled Query message uses
should not constrain implementors, but rather help clarify the an IP version which is not implemented on the interface used.
interface between the different layers of the NSIS protocol suite.
In addition, although some of the data types carry the information 2: Ingress Filter Failure: The MRI in a path-coupled Query message
from GIST information elements, this does not imply that the format describes a flow which would not pass ingress filtering on the
of that data as sent over the API has to be the same. interface used.
Appendix B. API between GIST and Signaling Applications
This appendix provides an abstract API between GIST and signaling
applications. It should not constrain implementors, but rather help
clarify the interface between the different layers of the NSIS
protocol suite. In addition, although some of the data types carry
the information from GIST information elements, this does not imply
that the format of that data as sent over the API has to be the same.
Conceptually the API has similarities to the sockets API, Conceptually the API has similarities to the sockets API,
particularly that for unconnected UDP sockets. An extension for an particularly that for unconnected UDP sockets. An extension for an
API like that for UDP connected sockets could be considered. In this API like that for UDP connected sockets could be considered. In this
case, for example, the only information needed in a SendMessage case, for example, the only information needed in a SendMessage
primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle
(which can be null). Other information which was persistent for a (which can be null). Other information which was persistent for a
group of messages could be configured once for the socket. Such group of messages could be configured once for the socket. Such
extensions may make a concrete implementation more efficient but do extensions may make a concrete implementation more efficient but do
not change the API semantics, and so are not considered further here. not change the API semantics, and so are not considered further here.
B.1. SendMessage B.1. SendMessage
This primitive is passed from an NSLP to GIST. It is used whenever This primitive is passed from a signaling application to GIST. It is
the NSLP wants to initiate sending a message. used whenever the signaling application wants to initiate sending a
message.
SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle,
NSLP-Id, Session-ID, MRI, NSLPID, Session-ID, MRI,
SII-Handle, Transfer-Attributes, Timeout, IP-TTL, GHC ) SII-Handle, Transfer-Attributes, Timeout, IP-TTL, GHC )
The following arguments are mandatory. The following arguments are mandatory.
NSLP-Data: The NSLP message itself. NSLP-Data: The NSLP message itself.
NSLP-Data-Size: The length of NSLP-Data. NSLP-Data-Size: The length of NSLP-Data.
NSLP-Message-Handle: A handle for this message, that can be used NSLP-Message-Handle: A handle for this message, that can be used by
later by GIST to reference it in MessageStatus notifications GIST as a reference in subsequent MessageStatus notifications
(Appendix B.3), in particular about errors or what security (Appendix B.3). Notifications could be about error conditions or
attributes will be used for the message. A NULL handle may be about the security attributes that will be used for the message.
supplied if the NSLP is not interested in notifications. A NULL handle may be supplied if the NSLP is not interested in
such notifications.
NSLP-Id: An identifier indicating which NSLP this is. NSLPID: An identifier indicating which NSLP this is.
Session-ID: The NSIS session identifier. Note that it is assumed Session-ID: The NSIS session identifier. Note that it is assumed
that the signaling application provides this to GIST rather than that the signaling application provides this to GIST rather than
GIST providing a value itself. GIST providing a value itself.
MRI: Message routing information for use by GIST in determining the MRI: Message routing information for use by GIST in determining the
correct next GIST hop for this message. The MRI implies the correct next GIST hop for this message. The MRI implies the
message routing method to be used and the message direction. message routing method to be used and the message direction.
The following arguments are optional. The following arguments are optional.
skipping to change at page 109, line 26 skipping to change at page 113, line 26
handled (see Section 4.1.2). The following attributes can be handled (see Section 4.1.2). The following attributes can be
considered: considered:
Reliability: Values 'unreliable' or 'reliable'. Reliability: Values 'unreliable' or 'reliable'.
Security: This attribute allows the NSLP to specify what level of Security: This attribute allows the NSLP to specify what level of
security protection is requested for the message (selected from security protection is requested for the message (selected from
'integrity' and 'confidentiality'), and can also be used to 'integrity' and 'confidentiality'), and can also be used to
specify what authenticated signaling source and destination specify what authenticated signaling source and destination
identities should be used to send the message. The identities should be used to send the message. The
possibilities can be learned by the NSLP from prior possibilities can be learned by the signaling application from
MessageStatus or RecvMessage notifications. If an NSLP- prior MessageStatus or RecvMessage notifications. If an NSLP-
Message-Handle is provided, GIST will inform the NSLP of what Message-Handle is provided, GIST will inform the signaling
values it has actually chosen for this attribute via a application of what values it has actually chosen for this
MessageStatus callback. This might take place either attribute via a MessageStatus callback. This might take place
synchronously (where GIST is selecting from available messaging either synchronously (where GIST is selecting from available
associations), or asynchronously (when a new messaging messaging associations), or asynchronously (when a new
association needs to be created). messaging association needs to be created).
Local Processing: This attribute contains hints from the NSLP Local Processing: This attribute contains hints from the signaling
about what local policy should be applied to the message; in application about what local policy should be applied to the
particular, its transmission priority relative to other message; in particular, its transmission priority relative to
messages, or whether GIST should attempt to set up or maintain other messages, or whether GIST should attempt to set up or
forward routing state. maintain forward routing state.
Timeout: Length of time GIST should attempt to send this message Timeout: Length of time GIST should attempt to send this message
before indicating an error. before indicating an error.
IP-TTL: The value of the IP TTL that should be used when sending this IP-TTL: The value of the IP TTL that should be used when sending this
message (may be overridden by GIST for particular messages). message (may be overridden by GIST for particular messages).
GHC: The value for the GIST hop count when sending the message. GHC: The value for the GIST hop count when sending the message.
B.2. RecvMessage B.2. RecvMessage
This primitive is passed from GIST to an NSLP. It is used whenever This primitive is passed from GIST to a signaling application. It is
GIST receives a message from the network, including the case of used whenever GIST receives a message from the network, including the
'null' messages (zero length NSLP payload), typically initial Query case of 'null' messages (zero length NSLP payload), typically initial
messages. This primitive can return a value from the NSLP which Query messages. For Queries, the results of invoking this primitive
indicates whether GIST should retain message routing state. are used by GIST to check whether message routing state should be
created (see the discussion of the 'Routing-State-Check' argument
below).
RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Id, Session-ID, MRI, RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLPID, Session-ID, MRI,
Adjacency-Check, SII-Handle, Transfer-Attributes, Routing-State-Check, SII-Handle, Transfer-Attributes,
IP-TTL, IP-Distance, GHC ) IP-TTL, IP-Distance, GHC )
NSLP-Data: The NSLP message itself (may be empty). NSLP-Data: The NSLP message itself (may be empty).
NSLP-Data-Size: The length of NSLP-Data (may be zero). NSLP-Data-Size: The length of NSLP-Data (may be zero).
NSLP-Id: An identifier indicating which NSLP this is message is for. NSLPID: An identifier indicating which NSLP this is message is for.
Session-ID: The NSIS session identifier. Session-ID: The NSIS session identifier.
MRI: Message routing information that was used by GIST in forwarding MRI: Message routing information that was used by GIST in forwarding
this message. Implicitly defines the message routing method that this message. Implicitly defines the message routing method that
was used and the direction of the message relative to the MRI. was used and the direction of the message relative to the MRI.
Adjacency-Check: This boolean is True if GIST is checking with the Routing-State-Check: This boolean is True if GIST is checking with
NSLP to see if a signaling adjacency should be formed (see the signaling application to see if routing state should be
Section 4.3.2). If True, the signaling application should return created with the peer or the message should be forwarded further
the following values via the RecvMessage call: (see Section 4.3.2). If True, the signaling application should
return the following values via the RecvMessage call:
A boolean indicating whether to form the adjacency. A boolean indicating whether to set up the state.
Optionally, an NSLP-Payload to carry in the generated GIST- Optionally, an NSLP-Payload to carry in the generated GIST-
Response or forwarded Query/Data message respectively. Response or forwarded Query message respectively.
This mechanism could be extended to enable the signaling
application to indicate to GIST whether state installation should
be immediate or deferred (see Section 5.3.3 and Section 6.3 for
further discussion).
SII-Handle: A handle to a data structure, identifying a peer address SII-Handle: A handle to a data structure, identifying a peer address
and interface. Can be used to identify route changes and for and interface. Can be used to identify route changes and for
explicit routing to a particular GIST next hop. explicit routing to a particular GIST next hop.
Transfer-Attributes: The reliability and security attributes that Transfer-Attributes: The reliability and security attributes that
were associated with the reception of this particular message. As were associated with the reception of this particular message. As
well as the attributes associated with SendMessage, GIST may well as the attributes associated with SendMessage, GIST may
indicate the level of verification of the addresses in the MRI. indicate the level of verification of the addresses in the MRI.
Three attributes can be indicated: Three attributes can be indicated:
skipping to change at page 111, line 18 skipping to change at page 115, line 27
IP-Distance: The number of IP hops from the peer signaling node which IP-Distance: The number of IP hops from the peer signaling node which
sent this message along the path, or 0 if this information is not sent this message along the path, or 0 if this information is not
available. available.
GHC: The value of the GIST hop count the message was received with, GHC: The value of the GIST hop count the message was received with,
after being decremented in the GIST receive-side processing. after being decremented in the GIST receive-side processing.
B.3. MessageStatus B.3. MessageStatus
This primitive is passed from GIST to an NSLP. It is used to notify This primitive is passed from GIST to a signaling application. It is
the NSLP that a message that it requested to be sent could not be used to notify the signaling application that a message that it
dispatched, or to inform the NSLP about the transfer attributes that requested to be sent could not be dispatched, or to inform the
have been selected for the message (specifically, security signaling application about the transfer attributes that have been
attributes). The NSLP can respond to this message with a return code selected for the message (specifically, security attributes). The
signaling application can respond to this message with a return code
to abort the sending of the message if the attributes are not to abort the sending of the message if the attributes are not
acceptable. acceptable.
MessageStatus (NSLP-Message-Handle, Transfer-Attributes, Error-Type) MessageStatus (NSLP-Message-Handle, Transfer-Attributes, Error-Type)
NSLP-Message-Handle: A handle for the message provided by the NSLP in NSLP-Message-Handle: A handle for the message provided by the
SendMessage. signaling application in SendMessage.
Transfer-Attributes: The reliability and security attributes that Transfer-Attributes: The reliability and security attributes that
will be used to transmit this particular message. will be used to transmit this particular message.
Error-Type: Indicates the type of error that occurred. For example, Error-Type: Indicates the type of error that occurred. For example,
'no next node found'. 'no next node found'.
B.4. NetworkNotification B.4. NetworkNotification
This primitive is passed from GIST to an NSLP. It indicates that a This primitive is passed from GIST to a signaling application. It
network event of possible interest to the NSLP occurred. indicates that a network event of possible interest to the signaling
application occurred.
NetworkNotification ( MRI, Network-Notification-Type ) NetworkNotification ( NSLPID, MRI, Network-Notification-Type )
NSLPID: An identifier indicating which NSLP this is message is for.
MRI: Provides the message routing information to which the network MRI: Provides the message routing information to which the network
notification applies. notification applies.
Network-Notification-Type: Indicates the type of event that caused Network-Notification-Type: Indicates the type of event that caused
the notification and associated additional data. Two events have the notification and associated additional data. Two events have
been identified: been identified:
Last Node: GIST has detected that this is the last NSLP-aware node Last Node: GIST has detected that this is the last NSLP-aware node
in the path. See Section 4.3.4. in the path. See Section 4.3.4.
Routing Status Change: GIST has detected that the routing state Routing Status Change: GIST has installed new routing state, or
may no longer be valid, or has re-established the routing has detected that the routing state may no longer be valid, or
state. See Section 7.1.3. The new status is reported; if the has re-established the routing state. See Section 7.1.3. The
status is Good, the SII-Handle of the peer is also reported, as new status is reported; if the status is Good, the SII-Handle
for RecvMessage. of the peer is also reported, as for RecvMessage.
B.5. SetStateLifetime B.5. SetStateLifetime
This primitive is passed from an NSLP to GIST. It indicates the This primitive is passed from a signaling application to GIST. It
lifetime for which GIST should retain its routing state. It can also indicates the duration for which the signaling application would like
give a hint that the NSLP is no longer interested in the state. GIST to retain its routing state. It can also give a hint that the
signaling application is no longer interested in the state.
SetStateLifetime ( MRI, State-Lifetime ) SetStateLifetime ( NSLPID, MRI, State-Lifetime )
NSLPID: Provides the NSLPID to which the routing state lifetime
applies.
MRI: Provides the message routing information to which the routing MRI: Provides the message routing information to which the routing
state lifetime applies; includes the direction (in the D flag). state lifetime applies; includes the direction (in the D flag).
State-Lifetime: Indicates the lifetime for which the NSLP wishes GIST State-Lifetime: Indicates the lifetime for which the signaling
to retain its routing state (may be zero, indicating that the NSLP application wishes GIST to retain its routing state (may be zero,
has no further interest in the GIST state). indicating that the signaling application has no further interest
in the GIST state).
B.6. InvalidateRoutingState B.6. InvalidateRoutingState
This primitive is passed from an NSLP to GIST. It indicates that the This primitive is passed from a signaling application to GIST. It
NSLP has knowledge that the next signaling hop known to GIST may no indicates that the signaling application has knowledge that the next
longer be valid, either because of changes in the network routing or signaling hop known to GIST may no longer be valid, either because of
the processing capabilities of NSLP nodes. See Section 7.1. changes in the network routing or the processing capabilities of
signaling application nodes. See Section 7.1.
InvalidateRoutingState ( NSLP-Id, MRI, Status, Urgent ) InvalidateRoutingState ( NSLPID, MRI, Status, Urgent )
NSLP-Id: The NSLP originating the message. May be null (in which NSLPID: The NSLP originating the message. May be null (in which case
case the invalidation applies to all signaling applications). the invalidation applies to all signaling applications).
MRI: The flow for which routing state should be invalidated; includes MRI: The flow for which routing state should be invalidated; includes
the direction of the change (in the D flag). 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).
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 signaling message. immediately, or only with the next signaling message.
skipping to change at page 114, line 5 skipping to change at page 119, line 5
node C does not process NSLP2 at all, so the peer state for NSLP2 is node C does not process NSLP2 at all, so the peer state for NSLP2 is
a pointer to a messaging association that runs directly from B to D. a pointer to a messaging association that runs directly from B to D.
Note that E is not visible in the state table (except implicitly in Note that E is not visible in the state table (except implicitly in
the address in the message routing information); routing state is the address in the message routing information); routing state is
stored only for adjacent peers. (In addition to the peer stored only for adjacent peers. (In addition to the peer
identification, IP hop counts are stored for each peer where the identification, IP hop counts are stored for each peer where the
state itself if not null; this is not shown in the table.) state itself if not null; this is not shown in the table.)
Figure 11 shows the message sequence for a GIST handshake that sets Figure 11 shows the message sequence for a GIST handshake that sets
up the messaging association for B-D signaling. It shows the up the messaging association for B-D signaling. It shows the
exchange of Stack Proposals and higher layer configuration data in exchange of Stack Proposals and MA-protocol-options data in each
each direction. Then the Querying node selects TLS/TCP as the stack direction. Then the Querying node selects TLS/TCP as the stack
configuration to use and sets up the messaging association over which configuration to use and sets up the messaging association over which
it sends the Confirm. it sends the Confirm.
-----------------------GIST-Query ---------------------> -----------------------GIST-Query --------------------->
IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=GIST; Dst=0x6789) IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST)
GIST(Header(Type=Query; NSLPID=NSLP2; R=1; S=0) GIST(Header(Type=Query; NSLPID=NSLP2; R=1; S=0)
MRI(MRM=Path-Coupled; Flow=F; Direction=down) MRI(MRM=Path-Coupled; Flow=F; Direction=down)
SessionID(0x1234) SessionID(0x1234)
NLI(Peer='string1'; IA=IP#B) 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(#HLI=2; StackConfigurationData(#MPO=2;
TCP(Applicable: all; Data: null) TCP(Applicable: all; Data: null)
SCTP(Applicable: all; Data: null))) SCTP(Applicable: all; Data: null)))
<---------------------GIST-Response--------------------- <---------------------GIST-Response---------------------
IP(Src=IP#D; Dst=IP#B); UDP(Src=0x6789; Dst=GIST) IP(Src=IP#D; Dst=IP#B); UDP(Src=GIST; Dst=6789)
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) SessionID(0x1234)
NLI(Peer='stringr2, IA=IP#D) 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(#HLI=3; StackConfigurationData(#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)))
-------------------------TCP SYN-----------------------> -------------------------TCP SYN----------------------->
<----------------------TCP SYN/ACK---------------------- <----------------------TCP SYN/ACK----------------------
-------------------------TCP ACK-----------------------> -------------------------TCP ACK----------------------->
TCP connect(IP Src=IP#B; IP Dst=IP#D; Src Port=91234; Dst Port=6123) TCP connect(IP Src=IP#B; IP Dst=IP#D; Src Port=9166; Dst Port=6123)
<-----------------------TLS INIT-----------------------> <-----------------------TLS INIT----------------------->
----------------------GIST-Confirm---------------------> ----------------------GIST-Confirm--------------------->
[Sent within messaging association] [Sent within messaging association]
GIST(Header(Type=Confirm; NSLPID=NSLP2; R=0; S=1) GIST(Header(Type=Confirm; NSLPID=NSLP2; R=0; S=1)
MRI(MRM=Path-Coupled; Flow=F; Direction=down) MRI(MRM=Path-Coupled; Flow=F; Direction=down)
SessionID(0x1234) SessionID(0x1234)
NLI(Peer='string1'; IA=IP#R) NLI(Peer='string1'; IA=IP#B)
ResponderCookie(0xacdefedcdfaeeeded) ResponderCookie(0xacdefedcdfaeeeded)
StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)) StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP))
Figure 11: GIST Handshake Message Sequence Figure 11: GIST Handshake Message Sequence
Appendix D. Change History Appendix D. Change History
D.1. Changes In Version -08 D.1. Changes In Version -09
1. Added a new Section 3.5 clarifying the relationship between
signaling applications and NSLPIDs; modified terminology in the
remainder of the document likewise.
2. Added a new Section 8.6 explaining the rationale behind the
downgrade attack prevention mechanism.
3. Re-wrote parts of Section 4.3.2, Section 6.1 and Appendix B.2 to
clarify the way that GIST is assumed to interact with signaling
applications to exercise policy control over whether or not two
nodes become signaling peers during a GIST handshake.
4. Generalised an error message Appendix A.4.4.12 to cover
additional MRI validation checks in Section 4.3.4 and
Section 5.8.1.2.
5. Allowed an optional Stack-Configuration-Data object in Confirm
messages to allow messaging association lifetime to be
negotiated even in the case of late state installation at the
Responding node (see Section 4.4.1 and Section 4.4.3).
6. Removed the option in Section 4.4.2 of allowing a node to treat
messaging associations with the same authenticated end points as
equivalent.
7. Include additional guidance in Section 4.4.3 to prevent routing
state being erroneously refreshed in the case of rerouting
events; also included general guidance notes on timer setting.
8. Clarified that the Stack-Proposal lists protocols in top-to-
bottom order (see Section 5.7.1).
9. Enhanced the definition of TLS usage in Section 5.7.3 with
details on ciphersuite requirements and authentication methods.
10. Tidied up terminology and discussion of how protocol options
data is carried in the SCD; renamed higher-layer-addressing to
MA-protocol-options.
D.2. 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 116, line 32 skipping to change at page 122, line 26
(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 C) to include a 18. Extended the routing state example (Appendix C) 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.
D.2. Changes In Version -07 D.3. 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 117, line 9 skipping to change at page 122, line 51
path-coupled MRM, Section 5.8.1.3, including rationale for and path-coupled MRM, Section 5.8.1.3, including rationale for and
restrictions on its use. restrictions on its use.
5. The formal description of the protocol in Section 6 has been 5. The formal description of the protocol in Section 6 has been
significantly updated and extended in terms of detail. significantly updated and extended in terms of detail.
6. Modified the description of the interaction between NSLPs and 6. Modified the description of the interaction between NSLPs and
GIMPS for handling inbound messages for which no routing state GIMPS for handling inbound messages for which no routing state
exists, to allow the NSLP to indicate whether state setup should exists, to allow the NSLP to indicate whether state setup should
proceed and to provide NSLP payloads for the Response or proceed and to provide NSLP payloads for the Response or
forwarded message (Section 3.5, Section 4.3.2 and Appendix B). forwarded message (Section 3.6, Section 4.3.2 and Appendix B).
7. Included new text, Section 5.6, on the processing and 7. Included new text, Section 5.6, on the processing and
encapsulation of error messages. Also added formats and an error encapsulation of error messages. Also added formats and an error
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.
D.3. Changes In Version -06 D.4. 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.4 which explains the concept 2. Added a new high level Section 3.4 which explains the concept
skipping to change at page 118, line 15 skipping to change at page 124, line 8
6. Added specific message types for errors and MA-Refresh in 6. Added specific message types for errors and MA-Refresh in
Section 5.1. The error object is now GIMPS-specific Section 5.1. The error object is now GIMPS-specific
(Appendix A.4.1). (Appendix A.4.1).
7. Moved the Flow-Identifier information about the message routing 7. Moved the Flow-Identifier information about the message routing
method from the general description of the object to the path- method from the general description of the object to the path-
coupled MRM section (Section 5.8.1.1), and made a number of coupled MRM section (Section 5.8.1.1), and made a number of
clarifications to the bit format (Appendix A.3.1.1). clarifications to the bit format (Appendix A.3.1.1).
8. Removed text about assumptions on the version numbering of 8. Removed text about assumptions on the version numbering of
NSLPs, and restricted the scope of the description of TLV objct NSLPs, and restricted the scope of the description of TLV object
formats and extensibility flags to GIMPS rather than the whole formats and extensibility flags to GIMPS rather than the whole
of NSIS (Appendix A). of NSIS (Appendix A).
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.6). and residual threats (Section 8.7).
D.4. Changes In Version -05 D.5. 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 119, line 31 skipping to change at page 125, line 25
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.
D.5. Changes In Version -04 D.6. 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 120, line 37 skipping to change at page 126, line 30
8. The ABNF for message formats in Section 5.1 has been re-written 8. The ABNF for message formats in Section 5.1 has been re-written
with a grammar structured around message purpose rather than with a grammar structured around message purpose rather than
message direction, and additional explanation added to the message direction, and additional explanation added to the
information element descriptions in Section 5.2. information element descriptions in Section 5.2.
9. The description of the datagram mode transport in Section 5.3 9. The description of the datagram mode transport in Section 5.3
has been updated. The encapsulation rules (covering IP has been updated. The encapsulation rules (covering IP
addressing and UDP port allocation) have been corrected, and a addressing and UDP port allocation) have been corrected, and a
new subsection on message retransmission and rate limiting has new subsection on message retransmission and rate limiting has
been added, superceding the old open issue on the same subject been added, superseding the old open issue on the same subject
(section 8.10). (section 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).
D.6. Changes In Version -03 D.7. 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 signaling applications (Section 4.1), in between GIMPS and signaling applications (Section 4.1), in
particular the message transfer attributes that signaling particular the message transfer attributes that signaling
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 121, line 36 skipping to change at page 127, line 30
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.1. configurations for various transport protocols in Section 5.4.1.
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.
D.7. Changes In Version -02 D.8. 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 which summarises restrictions on scope 1. Added a new Section 1.1 which summarises restrictions on scope
and applicability; some corresponding changes in terminology in and applicability; some corresponding changes in terminology in
Section 2. Section 2.
skipping to change at page 122, line 49 skipping to change at page 128, line 42
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.
D.8. Changes In Version -01 D.9. 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 signaling 'intermediaries', i.e. imposing the constraint that signaling
application peers are also GIMPS peers. This has the consequence application peers are also GIMPS peers. This has the consequence
that if a signaling application wishes to use two classes of that if a signaling application wishes to use two classes of
signaling transport for a given flow, maybe reaching different signaling transport for a given flow, maybe reaching different
subsets of nodes, it must do so by running different signaling subsets of nodes, it must do so by running different signaling
sessions; and it also means that signaling adaptations for passing sessions; and it also means that signaling adaptations for passing
through NATs which are not signaling application aware must be through NATs which are not signaling application aware must be
carried out in datagram mode. On the other hand, it allows the carried out in datagram mode. On the other hand, it allows the
elimination of significant complexity in the connection mode handling elimination of significant complexity in the connection mode handling
and also various other protocol features (such as general route and also various other protocol features (such as general route
recording). recording).
The full set of changes is as follows: The full set of changes is as follows:
1. Added a worked example in Section 3.5. 1. Added a worked example in Section 3.6.
2. Stated that nodes which do not implement the signaling 2. Stated that nodes which do not implement the signaling
application should bypass the message (Section 4.3). application should bypass the message (Section 4.3).
3. Decoupled the state handling logic for routing state and 3. Decoupled the state handling logic for routing state and
messaging association state in Section 4.4. Also, allow messaging association state in Section 4.4. Also, allow
messaging associations to be used immediately in both directions messaging associations to be used immediately in both directions
once they are opened. once they are opened.
4. Added simple ABNF for the various GIMPS message types in a new 4. Added simple ABNF for the various GIMPS message types in a new
skipping to change at page 124, line 8 skipping to change at page 129, line 50
and more clearly distinguishing between upstream and downstream and more clearly distinguishing between upstream and downstream
route changes. Included further details on GIMPS/NSLP route changes. Included further details on GIMPS/NSLP
interactions, including where notifications are delivered and interactions, including where notifications are delivered and
how local repair storms could be avoided. Removed old how local repair storms could be avoided. Removed old
discussion of propagating notifications through signaling discussion of propagating notifications through signaling
application unaware nodes (since these are now bypassed application unaware nodes (since these are now bypassed
automatically). Added discussion on how to route messages for automatically). Added discussion on how to route messages for
local state removal on the old path. local state removal on the old path.
9. Revised discussion of policy-based forwarding (old Section 7.2) 9. Revised discussion of policy-based forwarding (old Section 7.2)
to account for actual FLow-Routing-Information definition, and to account for actual Flow-Routing-Information definition, and
also how wildcarding should be allowed and handled. also how wildcarding should be allowed and handled.
10. Removed old route recording section (old Section 6.3). 10. Removed old route recording section (old Section 6.3).
11. Extended the discussion of NAT handling (Section 7.2) with an 11. Extended the discussion of NAT handling (Section 7.2) with an
extended outline on processing rules at a GIMPS-aware NAT and a extended outline on processing rules at a GIMPS-aware NAT and a
pointer to implications for C-mode processing and state pointer to implications for C-mode processing and state
management. management.
12. Clarified the definition of 'correct routing' of signaling 12. Clarified the definition of 'correct routing' of signaling
skipping to change at page 126, line 41 skipping to change at page 132, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 293 change blocks. 
837 lines changed or deleted 1099 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/