idnits 2.17.1 draft-ietf-nsis-ntlp-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 6409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 6420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6433. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 32. Fixed rfc2119 capitalisation of MUST not in Appendix A.3.5 [AD review comment N8]. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 31, 2006) is 6448 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Data' on line 259 -- Looks like a reference, but probably isn't: 'Flow' on line 273 -- Looks like a reference, but probably isn't: 'Adjacent' on line 283 -- Looks like a reference, but probably isn't: 'Initialisation' on line 3036 ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2765 (ref. '6') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2246 (ref. '7') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4234 (ref. '9') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4346 (ref. '10') (Obsoleted by RFC 5246) -- Possible downref: Normative reference to a draft: ref. '11' -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '15') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '16') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. '18') (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '23') (Obsoleted by RFC 5389) == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-01 -- Obsolete informational reference (is this intentional?): RFC 3682 (ref. '25') (Obsoleted by RFC 5082) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-12 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-11 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-06 == Outdated reference: A later version (-05) exists of draft-pashalidis-nsis-gimps-nattraversal-03 -- Obsolete informational reference (is this intentional?): RFC 4347 (ref. '41') (Obsoleted by RFC 6347) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Next Steps in Signaling H. Schulzrinne 3 Internet-Draft Columbia U. 4 Intended status: Standards Track R. Hancock 5 Expires: March 4, 2007 Siemens/RMR 6 August 31, 2006 8 GIST: General Internet Signaling Transport 9 draft-ietf-nsis-ntlp-11 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 4, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies protocol stacks for the routing and transport 43 of per-flow signaling messages along the path taken by that flow 44 through the network. The design uses existing transport and security 45 protocols under a common messaging layer, the General Internet 46 Signaling Transport (GIST), which provides a universal service for 47 diverse signaling applications. GIST does not handle signaling 48 application state itself, but manages its own internal state and the 49 configuration of the underlying transport and security protocols to 50 enable the transfer of messages in both directions along the flow 51 path. The combination of GIST and the lower layer transport and 52 security protocols provides a solution for the base protocol 53 component of the "Next Steps in Signaling" framework. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Restrictions on Scope . . . . . . . . . . . . . . . . . . 5 59 2. Requirements Notation and Terminology . . . . . . . . . . . . 6 60 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 9 62 3.2. Modes and Messaging Associations . . . . . . . . . . . . 10 63 3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 12 64 3.4. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 13 65 3.5. Signaling Sessions . . . . . . . . . . . . . . . . . . . 14 66 3.6. Signaling Applications and NSLPIDs . . . . . . . . . . . 15 67 3.7. Example of Operation . . . . . . . . . . . . . . . . . . 15 68 4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 18 69 4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 18 70 4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 20 71 4.3. Basic GIST Message Processing . . . . . . . . . . . . . . 21 72 4.4. Routing State and Messaging Association Maintenance . . . 27 73 5. Message Formats and Transport . . . . . . . . . . . . . . . . 35 74 5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 35 75 5.2. Information Elements . . . . . . . . . . . . . . . . . . 37 76 5.3. D-mode Transport . . . . . . . . . . . . . . . . . . . . 41 77 5.4. C-mode Transport . . . . . . . . . . . . . . . . . . . . 44 78 5.5. Message Type/Encapsulation Relationships . . . . . . . . 46 79 5.6. Error Message Processing . . . . . . . . . . . . . . . . 47 80 5.7. Messaging Association Setup . . . . . . . . . . . . . . . 48 81 5.8. Specific Message Routing Methods . . . . . . . . . . . . 52 82 6. Formal Protocol Specification . . . . . . . . . . . . . . . . 57 83 6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 59 84 6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 60 85 6.3. Responder Node Processing . . . . . . . . . . . . . . . . 63 86 6.4. Messaging Association Processing . . . . . . . . . . . . 66 88 7. Advanced Protocol Features . . . . . . . . . . . . . . . . . 70 89 7.1. Route Changes and Local Repair . . . . . . . . . . . . . 70 90 7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 77 91 7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 80 92 7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 80 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 83 94 8.1. Message Confidentiality and Integrity . . . . . . . . . . 83 95 8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 84 96 8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 85 97 8.4. Denial of Service Prevention . . . . . . . . . . . . . . 86 98 8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 87 99 8.6. Security Protocol Selection Policy . . . . . . . . . . . 89 100 8.7. Residual Threats . . . . . . . . . . . . . . . . . . . . 90 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 97 104 11.1. Normative References . . . . . . . . . . . . . . . . . . 97 105 11.2. Informative References . . . . . . . . . . . . . . . . . 97 106 Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 100 107 A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 100 108 A.2. General Object Format . . . . . . . . . . . . . . . . . . 101 109 A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 102 110 A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 111 111 Appendix B. API between GIST and Signaling Applications . . . . 119 112 B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 119 113 B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 121 114 B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 122 115 B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 123 116 B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 123 117 B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 124 118 Appendix C. Example Routing State Table and Handshake Message 119 Sequence . . . . . . . . . . . . . . . . . . . . . . 125 120 Appendix D. Change History . . . . . . . . . . . . . . . . . . . 127 121 D.1. Changes In Version -11 . . . . . . . . . . . . . . . . . 127 122 D.2. Changes In Version -10 . . . . . . . . . . . . . . . . . 128 123 D.3. Changes In Version -09 . . . . . . . . . . . . . . . . . 131 124 D.4. Changes In Version -08 . . . . . . . . . . . . . . . . . 132 125 D.5. Changes In Version -07 . . . . . . . . . . . . . . . . . 134 126 D.6. Changes In Version -06 . . . . . . . . . . . . . . . . . 135 127 D.7. Changes In Version -05 . . . . . . . . . . . . . . . . . 136 128 D.8. Changes In Version -04 . . . . . . . . . . . . . . . . . 137 129 D.9. Changes In Version -03 . . . . . . . . . . . . . . . . . 138 130 D.10. Changes In Version -02 . . . . . . . . . . . . . . . . . 139 131 D.11. Changes In Version -01 . . . . . . . . . . . . . . . . . 140 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143 133 Intellectual Property and Copyright Statements . . . . . . . . . 144 135 1. Introduction 137 Signaling involves the manipulation of state held in network 138 elements. 'Manipulation' could mean setting up, modifying and 139 tearing down state; or it could simply mean the monitoring of state 140 which is managed by other mechanisms. 142 This specification concentrates mainly on path-coupled signaling, 143 which involves network elements which are located on the path taken 144 by a particular data flow, possibly including but not limited to the 145 flow endpoints. Indeed, there are almost always more than two 146 participants in a path-coupled signaling session, although there is 147 no need for every node on the path to participate. Path-coupled 148 signaling thus excludes end-to-end higher-layer application 149 signaling. In the context of path-coupled signaling, examples of 150 state management include network resource reservation, firewall 151 configuration, and state used in active networking; examples of state 152 monitoring are the discovery of instantaneous path properties, such 153 as available bandwidth or cumulative queuing delay. Each of these 154 different uses of signaling is referred to as a signaling 155 application. Note that GIST can be extended to cover other types of 156 signaling pattern, where the message routing is not related to any 157 end-to-end flow in the network, in which case the distinction between 158 GIST and end-to-end higher-layer signaling will be drawn differently 159 or not at all. 161 Every signaling application requires a set of state management rules, 162 as well as protocol support to exchange messages along the data path. 163 Several aspects of this protocol support are common to all or a large 164 number of signaling applications, and hence can be developed as a 165 common protocol. The NSIS framework given in [26] provides a 166 rationale for a function split between the common and application 167 specific protocols, and gives outline requirements for the former, 168 the 'NSIS Transport Layer Protocol' (NTLP). The application specific 169 protocols are referred to as 'NSIS Signaling Layer Protocols' 170 (NSLPs), and are defined in separate documents. 172 This specification provides a concrete solution for the NTLP. It is 173 based on the use of existing transport and security protocols under a 174 common messaging layer, the General Internet Signaling Transport 175 (GIST). GIST does not handle signaling application state itself; in 176 that crucial respect, it differs from application signaling protocols 177 such as SIP, RTSP, and the control component of FTP. Instead, GIST 178 manages its own internal state and the configuration of the 179 underlying transport and security protocols to ensure the transfer of 180 signaling messages on behalf of signaling applications in both 181 directions along the flow path. 183 The structure of this specification is as follows. Section 2 defines 184 terminology, and Section 3 gives an informal overview of the protocol 185 design principles and operation. The normative specification is 186 contained mainly in Section 4 to Section 8. Section 4 describes the 187 message sequences and Section 5 their format and contents. Note that 188 the detailed bit formats are given in Appendix A. The protocol 189 operation is captured in the form of state machine language in 190 Section 6. Section 7 describes some more advanced protocol features 191 and security considerations are contained in Section 8. In addition, 192 Section 9 gives the IANA considerations, Appendix B describes an 193 abstract API for the service which GIST provides to signaling 194 applications, and Appendix C provides an example message flow. 196 1.1. Restrictions on Scope 198 This section briefly lists some important restrictions on GIST 199 applicability and functionality. In some cases, these are implicit 200 consequences of the functionality split developed in the NSIS 201 framework; in others, they are restrictions on the types of scenario 202 in which GIST can operate correctly. 204 Flow splitting: In some cases, e.g. where packet-level load sharing 205 has been implemented, the path taken by a single flow in the 206 network may not be well defined. If this is the case, GIST cannot 207 route signaling meaningfully. In some circumstances, GIST 208 implementations could detect this condition, but even this cannot 209 be guaranteed. 211 Multicast: GIST does not handle multicast flows. This includes 212 classical IP multicast and any of the small group multicast 213 schemes recently proposed. 215 Legacy NATs: GIST messages will generally pass through NATs, but 216 unless the NAT is GIST-aware, any addressing data carried in the 217 payload will not be handled correctly. There is a dual problem of 218 whether the GIST peers either side of the boundary can work out 219 how to address each other, and whether they can work out what 220 translation to apply to the signaling packet payloads. The 221 fundamental problem is that GIST messages contain three or four 222 interdependent addresses which all have to be consistently 223 translated, and existing generic NAT traversal techniques such as 224 STUN [23] or TURN [24] can process only two. Appropriate 225 behaviour for a GIST-aware NAT is discussed in Section 7.2. 227 2. Requirements Notation and Terminology 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in RFC 2119 [2]. 233 The terminology used in this specification is defined in this 234 section. The basic entities relevant at the GIST level are shown in 235 Figure 1. In particular, this diagram distinguishes the different 236 address types as being associated with a flow (end-to-end addresses) 237 or signaling (addresses of adjacent signaling peers). 239 Source GIST (adjacent) peer nodes Destination 241 IP address IP addresses = Signaling IP address 242 = Flow Source/Destination Addresses = Flow 243 Source (depending on signaling direction) Destination 244 Address | | Address 245 V V 246 +--------+ +------+ Data Flow +------+ +--------+ 247 | Flow |-----------|------|-------------|------|-------->| Flow | 248 | Sender | | | | | |Receiver| 249 +--------+ | GIST |============>| GIST | +--------+ 250 | Node |<============| Node | 251 +------+ Signaling +------+ 252 GN1 Flow GN2 254 >>>>>>>>>>>>>>>>> = Downstream direction 255 <<<<<<<<<<<<<<<<< = Upstream direction 257 Figure 1: Basic Terminology 259 [Data] Flow: A set of packets identified by some fixed combination 260 of header fields. Flows are unidirectional; a bidirectional 261 communication is considered a pair of unidirectional flows. 263 Session: A single application layer flow of information for which 264 some state information is to be manipulated or monitored. See 265 Section 3.5 for further detailed discussion. 267 Session Identifier (SID): A long, opaque identifier for a session. 269 [Flow] Sender: The node in the network which is the source of the 270 packets in a flow. A sender could be a host, or a router if for 271 example the flow is actually an aggregate. 273 [Flow] Receiver: The node in the network which is the sink for the 274 packets in a flow. 276 Downstream: In the same direction as the data flow. 278 Upstream: In the opposite direction to the data flow. 280 GIST Node: Any node along the data path supporting GIST, regardless 281 of what signaling applications it supports. 283 [Adjacent] Peer: The next node along the data path, in the upstream 284 or downstream direction, with which a GIST node explicitly 285 interacts. The GIST peer discovery mechanisms implicitly 286 determine whether two nodes will be adjacent. It is possible for 287 adjacencies to skip over intermediate nodes which decide not to 288 take part in the signaling exchange at the NTLP layer; even if 289 such nodes process parts of the signaling messages, they store no 290 state about the session and are never visible at the GIST level to 291 the nodes on either side. 293 Datagram Mode (D-mode): A mode of sending GIST messages between 294 nodes without using any transport layer state or security 295 protection. Datagram mode uses UDP encapsulation, with source and 296 destination IP addresses derived either from the flow definition 297 or previously discovered adjacency information. 299 Connection Mode (C-mode): A mode of sending GIST messages directly 300 between nodes using point-to-point messaging associations (see 301 below). Connection mode allows the re-use of existing transport 302 and security protocols where such functionality is required. 304 Messaging Association (MA): A single connection between two 305 explicitly identified GIST adjacent peers, i.e. between a given 306 signaling source and destination address. A messaging association 307 may use a specific transport protocol and known ports. If 308 security protection is required, it may use a specific network 309 layer security association, or use a transport layer security 310 association internally. A messaging association is bidirectional; 311 signaling messages can be sent over it in either direction, and 312 can refer to flows of either direction. 314 Message Routing Method (MRM): There can be different algorithms for 315 discovering the route that signaling messages should take. These 316 are referred to as message routing methods, and GIST supports 317 alternatives within a common protocol framework. See Section 3.3. 319 Message Routing Information (MRI): The set of data item values which 320 is used to route a signaling message according to a particular 321 MRM; for example, for routing along a flow path, the MRI includes 322 flow source and destination addresses, protocol and port numbers. 323 See Section 3.3. 325 Transfer Attributes: A description of the requirements which a 326 signaling application has for the delivery of a particular 327 message; for example, whether the message should be delivered 328 reliably. See Section 4.1.2. 330 Router Alert Option (RAO): An option that can be included in IP v4 331 and v6 headers to assist in the packet interception process; see 332 [1] and [5]. 334 3. Design Overview 336 3.1. Overall Design Approach 338 The generic requirements identified in the NSIS framework [26] for 339 transport of signaling messages are essentially two-fold: 341 Routing: Determine how to reach the adjacent signaling node along 342 each direction of the data path (the GIST peer), and if necessary 343 explicitly establish addressing and identity information about 344 that peer; 346 Transport: Deliver the signaling information to that peer. 348 To meet the routing requirement, one possibility is for the node to 349 use local routing state information to determine the identity of the 350 GIST peer explicitly. GIST defines a three-way handshake which 351 probes the network to set up the necessary routing state between 352 adjacent peers, during which signaling applications can also exchange 353 data. Once the routing decision has been made, the node has to 354 select a mechanism for transport of the message to the peer. GIST 355 divides the transport problems into two categories, the easy and the 356 difficult. It handles the easy cases internally, and uses well- 357 understood transport protocols for the harder cases. Here, with 358 details discussed later, "easy" messages are those that are sized 359 well below the lowest maximum transmission unit (MTU) along a path, 360 are infrequent enough not to cause concerns about congestion and flow 361 control, and do not need security protection or guaranteed delivery. 363 In [26] all of these routing and transport requirements are assigned 364 to a single notional protocol, the NSIS Transport Layer Protocol 365 (NTLP). The strategy of splitting the transport problem leads to a 366 layered structure for the NTLP, of a specialised GIST messaging layer 367 running over standard transport and security protocols, as shown in 368 Figure 2. This also shows GIST offering its services to upper layers 369 at an abstract interface, the GIST API, further discussed in 370 Section 4.1. 372 ^^ +-------------+ 373 || | Signaling | 374 NSIS +------------|Application 2| 375 Signaling | Signaling +-------------+ 376 Application |Application 1| | 377 Level +-------------+ | 378 || | | 379 VV | | 380 ========|===================|===== <-- GIST API 381 | | 382 ^^ +------------------------------------------------+ 383 || |+-----------------------+ +--------------+ | 384 || || GIST | | GIST State | | 385 || || Encapsulation |<<<>>>| Maintenance | | 386 || |+-----------------------+ +--------------+ | 387 || | GIST: Messaging Layer | 388 || +------------------------------------------------+ 389 NSIS | | | | 390 Transport .................................. 391 Level . Transport Layer Security (TLS) . 392 (NTLP) .................................. 393 || | | | | 394 || +----+ +----+ +----+ +----+ 395 || |UDP | |TCP | |SCTP| |DCCP| ... other 396 || +----+ +----+ +----+ +----+ protocols 397 || | | | | 398 || ............................. 399 || . IP Layer Security . 400 || ............................. 401 VV | | | | 402 ========================|=======|=======|=======|=============== 403 | | | | 404 +----------------------------------------------+ 405 | IP | 406 +----------------------------------------------+ 408 Figure 2: Protocol Stacks for Signaling Transport 410 3.2. Modes and Messaging Associations 412 Internally, GIST has two modes of operation: 414 Datagram mode (D-mode): used for small, infrequent messages with 415 modest delay constraints and no security requirements; it must 416 also be used when no routing state exists. 418 Connection mode (C-mode): used for larger data objects or where fast 419 state setup in the face of packet loss is desirable, or where 420 channel security is required. 422 D-mode uses UDP, as this is the only encapsulation which does not 423 require per-message shared state to be maintained between the peers. 424 C-mode can in principle use any stream or message-oriented transport 425 protocol; this specification defines TCP as the initial choice. It 426 can in principle employ specific network layer security associations, 427 or an internal transport layer security association; this 428 specification defines TLS as the initial choice. When GIST messages 429 are carried in C-mode, they are treated just like any other traffic 430 by intermediate routers between the GIST peers. Indeed, it would be 431 impossible for intermediate routers to carry out any processing on 432 the messages without terminating the transport and security protocols 433 used. 435 It is possible to mix these two modes along a path. This allows, for 436 example, the use of D-mode at the edges of the network and C-mode in 437 the core of the network. Such combinations may make operation more 438 efficient for mobile endpoints, while allowing multiplexing of 439 signaling messages across shared security associations and transport 440 connections between core routers. 442 It must be understood that the routing and transport decisions made 443 by GIST are not independent. If the message transfer has 444 requirements that require C-mode, for example if the message is so 445 large that fragmentation is required, this can only be used between 446 explicitly identified nodes. In such cases, GIST carries out the 447 three-way handshake initially in D-mode to identify the peer and then 448 sets up the necessary connections if they do not already exist. It 449 must also be understood that the signaling application does not make 450 the D-mode/C-mode selection directly; rather, this decision is made 451 by GIST on the basis of the message characteristics and the transfer 452 attributes stated by the application. The distinction is not visible 453 at the GIST service interface. 455 In general, the state associated with C-mode messaging to a 456 particular peer (signaling destination address, protocol and port 457 numbers, internal protocol configuration and state information) is 458 referred to as a messaging association (MA). There may be any number 459 of MAs between two GIST peers although the usual case is zero or one. 460 They are set up and torn down by management actions within GIST 461 itself. 463 3.3. Message Routing Methods 465 The baseline message routing functionality in GIST is that signaling 466 messages follow a route defined by an existing flow in the network, 467 visiting a subset of the nodes through which it passes. This is the 468 appropriate behaviour for application scenarios where the purpose of 469 the signaling is to manipulate resources for that flow. However, 470 there are scenarios for which other behaviours are applicable. Two 471 examples are: 473 Predictive Routing: Here, the intent is to signal along a path that 474 the data flow may follow in the future. Possible cases are pre- 475 installation of state on the backup path that would be used in the 476 event of a link failure, and predictive installation of state on 477 the path that will be used after a mobile node handover. 479 NAT Address Reservations: This applies to the case where a node 480 behind a NAT wishes to reserve an address at which it can be 481 reached by a sender on the other side. This requires a message to 482 be sent outbound from what will be the flow receiver although no 483 reverse routing state for the flow yet exists. 485 Most of the details of GIST operation are independent of which 486 alternative is being used. Therefore, the GIST design encapsulates 487 the routing-dependent details as a message routing method (MRM), and 488 allows multiple MRMs to be defined. The default is the path-coupled 489 MRM, which corresponds to the baseline functionality described above; 490 a second MRM for the NAT Address Reservation case is also defined. 492 The content of a MRM definition is as follows, using the path-coupled 493 MRM as an example: 495 o The format of the information that describes the path that the 496 signaling should take, the Message Routing Information (MRI). For 497 the path-coupled MRM, this is just the Flow Identifier (see 498 Section 5.8.1.1) and some additional control information. 499 Specifically, the MRI always includes a flag to distinguish 500 between the two directions that signaling messages can take, 501 denoted 'upstream' and 'downstream'. 503 o A specification of the IP-level encapsulation of the messages 504 which probe the network to discover the adjacent peers. A 505 downstream encapsulation must be defined; an upstream 506 encapsulation is optional. For the path-coupled MRM, this 507 information is given in Section 5.8.1.2 and Section 5.8.1.3. 509 o A specification of what validation checks GIST should apply to the 510 probe messages, for example to protect against IP address spoofing 511 attacks. The checks may be dependent on the direction (upstream 512 or downstream) of the message. For the path-coupled MRM, the 513 downstream validity check is basically a form of ingress 514 filtering, also discussed in Section 5.8.1.2. 516 o The mechanism(s) available for route change detection, i.e. any 517 change in the neighbour relationships that the MRM discovers. The 518 default case for any MRM is soft-state refresh, but additional 519 supporting techniques may be possible; see Section 7.1.2. 521 In addition, it should be noted that NAT traversal may require 522 translation of fields in the MRI object carried in GIST messages (see 523 Section 7.2). The generic MRI format includes a flag that must be 524 given as part of the MRM definition, to indicate if some kind of 525 translation is necessary. Development of a new MRM therefore 526 includes updates to the GIST specification, and may include updates 527 to specifications of NAT behaviour. These updates may be done in 528 separate documents as is the case for the base GIST specification, as 529 described in Section 7.2.2. 531 The MRI is passed explicitly between signaling applications and GIST; 532 therefore, signaling application specifications must define which 533 MRMs they require. Signaling applications may use fields in the MRI 534 in their packet classifiers; if they use additional information for 535 packet classification, this would be carried at the NSLP level and so 536 would be invisible to GIST. Any node hosting a particular signaling 537 application MUST use a GIST implementation that supports the 538 corresponding MRMs. The GIST processing rules enforce that nodes 539 which do not host the signaling application are not forced to handle 540 messages for it at the GIST level, so it does not matter if they 541 support the MRM or not. 543 3.4. GIST Messages 545 GIST has six message types: Query, Response, Confirm, Data, Error, 546 and MA-Hello. Apart from the invocation of the messaging association 547 protocols, all GIST communication consists of these messages. In 548 addition, all signaling application data is carried as additional 549 payloads in these messages, alongside the GIST information. 551 The first three messages implement the handshake that GIST uses to 552 set up routing state and messaging associations. The handshake is 553 initiated from the Querying node towards the Responding node. The 554 first message is the Query, which is encapsulated in a special way 555 depending on the message routing method, in order to probe the 556 network infrastructure so that the correct peer will intercept it and 557 become the Responding node. A Query always triggers a Response in 558 the reverse direction as the second message of the handshake. As 559 part of the defence against denial of service attacks, the Responding 560 node can delay state installation until a return routability check, 561 and require the Querying node to complete the handshake with the 562 Confirm. All of these three messages can optionally carry signaling 563 application data. 565 The Data message is used purely to encapsulate signaling application 566 data. Usually it is sent using pre-established routing state. 567 However, if there are no security or transport requirements and no 568 need for persistent reverse routing state, it can also be sent in the 569 same way as the Query. Finally, Error messages are used to indicate 570 error conditions at the GIST level, and the MA-Hello message can be 571 used as a keepalive for the messaging association protocols. 573 3.5. Signaling Sessions 575 GIST allows signaling applications to associate each of their 576 messages with a signaling session. Informally, given an application 577 layer exchange of information for which some network control state 578 information is to be manipulated or monitored, the corresponding 579 signaling messages should be associated with the same session. 580 Signaling applications provide the session identifier (SID) whenever 581 they wish to send a message, and GIST reports the SID when a message 582 is received. 584 Most GIST processing and state information is related to the flow 585 (defined by the MRI, see above) and signaling application (given by 586 the NSLP identifier, see below). There are several possible 587 relationships between flows and sessions, for example: 589 o The simplest case is that all messages for the same flow have the 590 same SID. 592 o Messages for more than one flow may use the same SID, for example 593 because one flow is replacing another in a mobility or multihoming 594 scenario. 596 o A single flow may have messages for different SIDs, for example 597 from independently operating signaling applications. 599 Because of this range of options, GIST does not perform any 600 validation on how signaling applications map between flows and 601 sessions, nor does it perform any validation on the properties of the 602 SID itself. In particular, when a new SID is needed, logically it 603 should be generated by the signaling application. NSIS 604 implementations could provide common functionality to generate SIDs 605 for use by any signaling application, but this is not part of GIST. 606 GIST only defines the syntax of the SID as an opaque 128-bit 607 identifier. 609 The SID assignment has the following impact on GIST processing: 611 o Messages with the same SID that are to be delivered reliably 612 between the same GIST peers are delivered in order. 614 o All other messages are handled independently. 616 o GIST identifies routing state (upstream and downstream peer) by 617 the triplet (MRI, NSLP, SID). 619 Strictly, the routing state should not depend on the SID. However, 620 if the routing state is keyed only by (MRI, NSLP), there is a trivial 621 denial of service attack (see Section 8.3) where a malicious off-path 622 node asserts that it is the peer for a particular flow. Instead, the 623 routing state is also segregated between different SIDs, which means 624 that the attacking node can only disrupt a signaling session if it 625 can guess the corresponding SID. A consequence of this design is 626 that signaling applications SHOULD choose SIDs so that they are 627 cryptographically random, and SHOULD NOT use several SIDs for the 628 same flow, to avoid additional load from routing state maintenance. 629 Guidance on secure randomness generation can be found in [28]. 631 3.6. Signaling Applications and NSLPIDs 633 The functionality for signaling applications is supported by NSIS 634 signaling layer protocols (NSLPs). Each NSLP is identified by a 16 635 bit NSLP identifier (NSLPID), assigned by IANA (Section 9). A single 636 signaling application, such as resource reservation, may define a 637 family of NSLPs to implement its functionality, for example to carry 638 out signaling operations at different levels in a hierarchy (cf. 639 [19]). However, the interactions between the different NSLPs (for 640 example, to relate aggregation levels or aggregation region 641 boundaries in the resource management case) are handled at the 642 signaling application level; the NSLPID is the only information 643 visible to GIST about the signaling application being used. 645 3.7. Example of Operation 647 This section presents an example of GIST usage in a relatively simple 648 (in particular, NAT-free) signaling scenario, to illustrate its main 649 features. 651 Consider the case of an RSVP-like signaling application which 652 allocates resources for a single unicast flow. We will consider how 653 GIST transfers messages between two adjacent peers along the path, 654 GN1 and GN2 (see Figure 1 in Section 2). In this example, the end- 655 to-end exchange is initiated by the signaling application instance in 656 the sender; we take up the story at the point where the first message 657 is being processed above the GIST layer by the signaling application 658 in GN1. 660 1. The signaling application in GN1 determines that this message is 661 a simple description of resources that would be appropriate for 662 the flow. It determines that it has no special security or 663 transport requirements for the message, but simply that it should 664 be transferred to the next downstream signaling application peer 665 on the path that the flow will take. 667 2. The message payload is passed to the GIST layer in GN1, along 668 with a definition of the flow and description of the message 669 transfer attributes {unsecured, unreliable}. GIST determines 670 that this particular message does not require fragmentation and 671 that it has no knowledge of the next peer for this flow and 672 signaling application; however, it also determines that this 673 application is likely to require secured upstream and downstream 674 transport of large messages in the future. This determination is 675 a function of node-local policy interactions between GIST and the 676 signaling application. 678 3. GN1 therefore constructs a GIST Query carrying the NSLP payload, 679 and additional payloads at the GIST level to be used to initiate 680 a messaging association. The Query is encapsulated in a UDP 681 datagram and injected into the network, addressed towards the 682 flow destination and with an IP Router Alert Option (RAO) 683 included. 685 4. The Query passes through the network towards the flow receiver, 686 and is seen by each router in turn. GIST-unaware routers will 687 not recognise the RAO value and will forward the message 688 unchanged; GIST-aware routers which do not support the NSLP in 689 question will also forward the message basically unchanged, 690 although they may need to process more of the message to decide 691 this. 693 5. The message is intercepted at GN2. The GIST layer identifies the 694 message as relevant to a local signaling application, and passes 695 the NSLP payload and flow description upwards to it. The 696 signaling application in GN2 indicates to GIST that it will peer 697 with GN1 and so GIST should proceed to set up any routing state. 698 In addition, the signaling application continues to process the 699 message as in GN1 (compare step 1), forwarding the message 700 downstream, and this will eventually result in the message 701 reaching the flow receiver. 703 6. In parallel, the GIST instance in GN2 now knows that it should 704 maintain routing state and a messaging association for future 705 signaling with GN1. This is recognised because the message is a 706 Query, and because the local signaling application has indicated 707 that it will peer with GN1. There are two possible cases for 708 sending back the necessary GIST Response: 710 Association Exists: GN1 and GN2 already have an appropriate MA. 711 GN2 simply records the identity of GN1 as its upstream peer 712 for that flow and NSLP, and sends a Response back to GN1 over 713 the MA identifying itself as the peer for this flow. 715 No Association: No MA exists. GN2 sends the Response in D-mode 716 directly to GN1, identifying itself and agreeing to the 717 association setup. The protocol exchanges needed to complete 718 this will proceed in parallel with the following stages. 720 7. Eventually, another NSLP message works its way upstream from the 721 receiver to GN2. This message contains a description of the 722 actual resources requested, along with authorisation and other 723 security information. The signaling application in GN2 passes 724 this payload to the GIST level, along with the flow definition 725 and transfer attributes {secured, reliable}. 727 8. The GIST layer in GN2 identifies the upstream peer for this flow 728 and NSLP as GN1, and determines that it has an MA with the 729 appropriate properties. The message is queued on the MA for 730 transmission; this may incur some delay if the procedures begun 731 in step 6.B have not yet completed. 733 Further messages can be passed in each direction in the same way. 734 The GIST layer in each node can in parallel carry out maintenance 735 operations such as route change detection (see Section 7.1). 737 It should be understood that several of these details of GIST 738 operations can be varied, either by local policy or according to 739 signaling application requirements. The authoritative details are 740 contained in the remainder of this document. 742 4. GIST Processing Overview 744 This section defines the basic structure and operation of GIST. 745 Section 4.1 describes the way in which GIST interacts with local 746 signaling applications in the form of an abstract service interface. 747 Section 4.2 describes the per-flow and per-peer state that GIST 748 maintains for the purpose of transferring messages. Section 4.3 749 describes how messages are processed in the case where any necessary 750 messaging associations and routing state already exist; this includes 751 the simple scenario of pure D-mode operation, where no messaging 752 associations are necessary in the first place. Finally, Section 4.4 753 describes how routing state and messaging associations are created 754 and managed. 756 4.1. GIST Service Interface 758 This section defines the service interface that GIST presents to 759 signaling applications in terms of abstract properties of the message 760 transfer. Note that the same service interface is presented at every 761 GIST node; however, applications may invoke it differently at 762 different nodes, depending for example on local policy. In addition, 763 the service interface is defined independently of any specific 764 transport protocol, or even the distinction between D-mode and 765 C-mode. The initial version of this specification defines how to 766 support the service interface using a C-mode based on TCP; if 767 additional protocol support is added, this will support the same 768 interface and so the change will be invisible to applications, except 769 as a possible performance improvement. A more detailed description 770 of this service interface is given in Appendix B. 772 4.1.1. Message Handling 774 Fundamentally, GIST provides a simple message-by-message transfer 775 service for use by signaling applications: individual messages are 776 sent, and individual messages are received. At the service 777 interface, the NSLP payload, which is opaque to GIST, is accompanied 778 by control information expressing the application's requirements 779 about how the message should be routed, and the application also 780 provides the session identifier (see Section 3.5). Additional 781 message transfer attributes control the specific transport and 782 security properties that the signaling application desires. 784 The distinction between GIST D- and C-mode is not visible at the 785 service interface. In addition, the functionality to handle 786 fragmentation and reassembly, bundling together of small messages for 787 efficiency, and congestion control are not directly visible at the 788 service interface; GIST will take whatever action is necessary based 789 on the properties of the messages and local node state. 791 4.1.2. Message Transfer Attributes 793 Message transfer attributes are used to define certain performance 794 and security related aspects of message processing. The attributes 795 available are as follows: 797 Reliability: This attribute may be 'true' or 'false'. When 'true', 798 messages MUST be delivered to the signaling application in the 799 peer exactly once or not at all; if there is a chance that the 800 message was not delivered, an error MUST be indicated to the local 801 signaling application identifying the routing information for the 802 message in question. GIST implements reliability by using an 803 appropriate transport protocol within a messaging association, so 804 mechanisms for the detection of message loss depend on the 805 protocol in question; for the current specification, the case of 806 TCP is considered in Section 5.7.2. Messages with the same SID to 807 the same peer MUST be delivered in order. When 'false', a message 808 may be delivered, once, several times or not at all, with no error 809 indications in any case. 811 Security: This attribute defines the security properties that the 812 signaling application requires for the message, including the type 813 of protection required, and what authenticated identities should 814 be used for the signaling source and destination. This 815 information maps onto the corresponding properties of the security 816 associations established between the peers in C-mode. It can be 817 specified explicitly by the signaling application, or reported by 818 GIST to the signaling application. The latter can take place 819 either on receiving a message, or just before sending a message 820 but after configuring or selecting the messaging association to be 821 used for it. This attribute can also be used to convey 822 information about any address validation carried out by GIST, such 823 as whether a return routability check has been carried out. 824 Further details are discussed in Appendix B. 826 Local Processing: An NSLP may provide hints to GIST to enable more 827 efficient or appropriate processing. For example, the NSLP may 828 select a priority from a range of locally defined values to 829 influence the sequence in which messages leave a node. Any 830 priority mechanism MUST respect the ordering requirements for 831 reliable messages within a session, and priority values are not 832 carried in the protocol or available at the signaling peer or 833 intermediate nodes. An NSLP may also indicate that reverse path 834 routing state will not be needed for this flow, to inhibit the 835 node requesting its downstream peer to create it. 837 4.2. GIST State 839 4.2.1. Message Routing State 841 For each flow, the GIST layer can maintain message routing state to 842 manage the processing of outgoing messages. This state is 843 conceptually organised into a table with the following structure. 844 The primary key (index) for the table is the combination of the 845 information about how the message is to be routed, the session being 846 signaled for, and the signaling application itself: 848 Message Routing Information (MRI): This defines the method to be 849 used to route the message, the direction in which to send the 850 message, and any associated addressing information; see 851 Section 3.3. 853 Session Identification (SID): The signaling session with which this 854 message should be associated; see Section 3.5. 856 NSLP Identification (NSLPID): This is an IANA-assigned identifier 857 associated with the NSLP which is generating messages for this 858 flow. The inclusion of this identifier allows the routing state 859 to be different for different NSLPs, for example because of 860 different adjacencies. 862 The information associated with a given key consists of the routing 863 state to reach the peer in the direction given by the MRI. For any 864 flow, there will usually be two entries, one each for the upstream 865 and downstream MRI. The routing state includes information about the 866 peer identity (see Section 4.4.2), and a UDP port number for D-mode, 867 or a reference to one or more MAs for C-mode. All of this 868 information is learned from prior GIST exchanges. 870 It is also possible for the state information for either direction to 871 be empty. There are several possible cases: 873 o The signaling application has indicated that no messages will 874 actually be sent in that direction. 876 o The node is a flow endpoint, so there can be no signaling peer in 877 one or other direction. 879 o The node is the endpoint of the signaling path, for example 880 because it is acting as a proxy, or because it has determined that 881 there are no further signaling nodes in that direction. 883 o The node is using other techniques to route the message. For 884 example, it can encapsulate it the same way as a Query and rely on 885 the peer to intercept it. 887 Each entry in the routing state table has an associated validity 888 timer for how long it can be considered accurate; when this timer 889 expires, the entry MUST be purged if it has not been refreshed. 890 Installation and maintenance of routing state is described in more 891 detail in Section 4.4. 893 Note also that the routing state is described as a table of per-flow 894 entries, but that there is no implied constraint on how the 895 information is stored. However, in general, and especially if GIST 896 peers are several IP hops away, there is no way to identify the 897 correct downstream peer for a flow and signaling application from the 898 local forwarding table using prefix matching, and the same applies 899 always to upstream peer state because of the possibility of 900 asymmetric routing: prefix aggregation is not possible, and per-flow 901 state has to be stored, just as for RSVP [12]. 903 4.2.2. Peer-Peer Messaging Association State 905 The per-flow message routing state is not the only state stored by 906 GIST. There is also the state required to manage the MAs. Since 907 these are not per-flow, they are stored separately from the routing 908 state, including the following per-MA information: 910 o a queue of messages pending transmission while an MA is being 911 established; 913 o a timer for how long since the peer re-stated its desire to keep 914 the MA open (see Section 4.4.3). 916 In addition, per-MA state is held in the messaging association 917 protocols themselves. However, the details of this state are not 918 directly visible to GIST, and they do not affect the rest of the 919 protocol description. 921 4.3. Basic GIST Message Processing 923 This section describes how signaling application messages are 924 processed in the case where any necessary messaging associations and 925 routing state are already in place. The description is divided into 926 several parts. Firstly, message reception, local processing and 927 message transmission are described for the case where the node hosts 928 the NSLPID identified in the message. Secondly, the case where the 929 message is handled directly in the IP or GIST layer (because there is 930 no matching signaling application on the node) is given. An overview 931 is given in Figure 3. 933 +---------------------------------------------------------+ 934 | >> Signaling Application Processing >> | 935 | | 936 +--------^---------------------------------------V--------+ 937 ^ V 938 ^ NSLP Payloads V 939 ^ V 940 +--------^---------------------------------------V--------+ 941 | >> GIST >> | 942 | ^ ^ ^ Processing V V V | 943 +--x-----------N--Q---------------------Q--N-----------x--+ 944 x N Q Q N x 945 x N Q>>>>>>>>>>>>>>>>>>>>>Q N x 946 x N Q Bypass at Q N x 947 +--x-----+ +--N--Q--+ GIST level +--Q--N--+ +-----x--+ 948 | C-mode | | D-mode | | D-mode | | C-mode | 949 |Handling| |Handling| |Handling| |Handling| 950 +--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+ 951 x N Q Q N x 952 x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x 953 x N Q Bypass at Q N x 954 +--x--N--+ +-----Q--+ IP (router +--Q-----+ +--N--x--+ 955 |IP Host | | RAO | alert) level | RAO | |IP Host | 956 |Handling| |Handling| |Handling| |Handling| 957 +--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+ 958 x N Q Q N x 959 +--x--N-----------Q--+ +--Q-----------N--x--+ 960 | IP Layer | | IP Layer | 961 | (Receive Side) | | (Transmit Side) | 962 +--x--N-----------Q--+ +--Q-----------N--x--+ 963 x N Q Q N x 964 x N Q Q N x 966 NNNNNNNNNNNNNN = Normal D-mode messages 967 QQQQQQQQQQQQQQ = D-mode messages which are Q-mode encapsulated 968 xxxxxxxxxxxxxx = C-mode messages 969 RAO = Router Alert Option 971 Figure 3: Message Paths through a GIST Node 973 4.3.1. Message Reception 975 Messages can be received in C-mode or D-mode. In the D-mode case, 976 there are two possible message encapsulations, described below. 978 Reception in C-mode is simple: incoming packets undergo the security 979 and transport treatment associated with the MA, and the MA provides 980 complete messages to the GIST layer for further processing. 982 Reception in D-mode depends on the message type. 984 Normal encapsulation: Normal messages arrive UDP-encapsulated and 985 addressed directly to the receiving signaling node, at an address 986 and port learned previously. Each datagram contains a single 987 message which is passed to the GIST layer for further processing, 988 just as in the C-mode case. 990 Q-mode encapsulation: Where GIST is sending messages to be 991 intercepted by the appropriate peer rather than directly addressed 992 to it (in particular, Query messages), these are UDP encapsulated, 993 usually with an IP router alert option. Each signaling node will 994 therefore see all such messages. Several RAO values may be used 995 by NSIS; the assignment rationale is discussed in [11]. The case 996 where the NSLPID does not match a local signaling application at 997 all is considered below in Section 4.3.4; otherwise, the message 998 is again passed up to the GIST layer for further processing. 1000 4.3.2. Local Processing and Validation 1002 Once a message has been received, it is processed locally within the 1003 GIST layer. The GIST hop count, which every message contains to 1004 prevent looping, MUST be checked and decremented immediately the 1005 message has been received. Further processing depends on the message 1006 type and payloads carried; most of the GIST payloads are associated 1007 with state maintenance and details are covered in Section 4.4. 1009 In the case of a Query, there is an interaction with signaling 1010 application policy to determine which of two courses to follow: 1012 1. The receiving signaling application wishes to become a signaling 1013 peer with the Querying node. GIST MUST continue with the 1014 handshake process to set up message routing state, as described 1015 in Section 4.4.1. The application MAY provide an NSLP payload 1016 for the same NSLPID, which GIST will transfer in the Response. 1018 2. The signaling application does not wish to set up state with the 1019 Querying node and become its peer. GIST MUST propagate the 1020 Query, similar to the case described in Section 4.3.4. No 1021 message is sent back to the Querying node. The application MAY 1022 provide an updated NSLP payload for the same NSLPID, which will 1023 be used in the Query forwarded by GIST. 1025 This interaction with the signaling application, including the 1026 generation or update of an NSLP payload, SHOULD take place 1027 synchronously as part of the Query processing. In terms of the GIST 1028 service interface, this can be implemented by providing appropriate 1029 return values for the primitive that is triggered when such a message 1030 is received; see Appendix B.2 for further discussion. 1032 For all other message types, the GIST payloads are processed as 1033 described in Section 4.4. The remainder of the GIST message consists 1034 of an NSLP payload, which is delivered locally to the signaling 1035 application identified by the NSLPID. The format of the payload is 1036 not constrained by GIST, and the content is not interpreted. 1037 Delivery is subject to the following validation checks: 1039 o if the message was explicitly routed (see Section 7.1.4) or is a 1040 Data message delivered without routing state (see Section 5.3.2), 1041 the payload is delivered but flagged to the receiving NSLP to 1042 indicate that routing state was not validated; 1044 o else, if there is no routing state for the MRI/SID/NSLPID the 1045 message MUST be rejected with a "No Routing State" error message 1046 (Appendix A.4.4.5); 1048 o else, if the message arrived on an association which is not 1049 associated with the MRI/NSLPID/SID combination given in the 1050 message, the message MUST be rejected with an "Incorrectly 1051 Delivered Message" error message (Appendix A.4.4.4); 1053 o else, the payload is delivered as normal. 1055 4.3.3. Message Transmission 1057 Signaling applications can generate their messages for transmission, 1058 either asynchronously, or in response to a normal input message, and 1059 GIST can also generate messages autonomously. When a message is 1060 available for transmission, GIST uses internal policy and the stored 1061 routing state to determine how to handle it. The following 1062 processing applies equally to locally generated messages and messages 1063 forwarded from within the GIST or signaling application levels. 1064 However, see Section 5.6 for special rules applying to the 1065 transmission of error messages by GIST. 1067 The main decision is whether the message must be sent in C-mode or 1068 D-mode. Reasons for using the former are: 1070 o signaling application requirements: for example, it has requested 1071 channel secured delivery, or reliable delivery; 1073 o protocol specification: a message that requires fragmentation MUST 1074 be sent over a messaging association; 1076 o local policy: for example, a node MAY send messages over a 1077 messaging association to benefit from adaptive congestion control. 1079 In principle, as well as determining that some messaging association 1080 must be used, GIST MAY select between a set of alternatives, e.g. for 1081 load sharing or because different messaging associations provide 1082 different transport or security attributes. 1084 If the use of a messaging association is selected, the message is 1085 queued on the association found from the routing state table, and 1086 further output processing is carried out according to the details of 1087 the protocol stacks used. If no appropriate association exists, the 1088 message is queued while one is created (see Section 4.4.1). If no 1089 association can be created, this is an error condition, and should be 1090 indicated back to the local signaling application. 1092 If a messaging association is not required, the message is sent in 1093 D-mode. The processing in this case depends on the message type and 1094 whether routing state exists or not. 1096 o If the message is not a Query, and routing state exists, it is UDP 1097 encapsulated and sent directly to the address from the routing 1098 state table. 1100 o If the message is a Query, then it is UDP encapsulated with IP 1101 address and if necessary router alert option determined from the 1102 MRI and NSLPID; the details depend on the message routing method. 1104 o If no routing state exists, GIST can attempt to use the same 1105 Q-mode encapsulation as in the Query case. If this is not 1106 possible, e.g. because the encapsulation for the MRM is only 1107 defined for one message direction, then this is an error condition 1108 which is reported back to the local signaling application. 1110 4.3.4. Nodes not Hosting the NSLP 1112 A node may receive messages where it has no signaling application 1113 corresponding to the message NSLPID. There are several possible 1114 cases depending mainly on the encapsulation: 1116 1. A Q-mode encapsulated message contains an RAO value which is 1117 relevant to NSIS but not to the specific node, but the IP layer 1118 is unable to recognise whether it needs to be passed to GIST for 1119 further processing or whether the packet should be forwarded just 1120 like a normal IP datagram. 1122 2. A Q-mode encapsulated message contains an RAO value which is 1123 relevant to the node, but the specific signaling application for 1124 the NSLPID in the message is not processed there. 1126 3. A directly addressed message (in D-mode or C-mode) is delivered 1127 to a node for which there is no corresponding signaling 1128 application. With the current specification, this should never 1129 happen. While future versions might find a use for such a 1130 feature, currently this MUST cause an "Unknown NSLPID" error 1131 message, Appendix A.4.4.6. 1133 4. A Q-mode encapsulated message arrives at the end-system which 1134 does not handle the signaling application. This is possible in 1135 normal operation, and MUST be indicated to the sender with an 1136 "Endpoint Found" informational message (Appendix A.4.4.7). The 1137 end-system includes the MRI and SID from the original message in 1138 the error message without interpreting them. 1140 5. The node is GIST-aware NAT. See Section 7.2. 1142 In cases (1) and (2), the role of GIST is to forward the message 1143 essentially unchanged, and it will not become a peer to the node 1144 sending the message. Forwarding with modified NSLP payloads is 1145 covered above in Section 4.3.2. However, a GIST implementation must 1146 ensure that the IP-layer TTL field and GIST hop count are managed 1147 correctly to prevent message looping, and this should be done 1148 consistently independently of whether the processing takes place on 1149 the fast path or in GIST-specific code. The rules are that in cases 1150 (1) and (2), the IP-layer TTL MUST be decremented just as if the 1151 message was a normal IP forwarded packet; in case (2) the GIST hop 1152 count MUST be decremented as in the case of normal input processing, 1153 which indeed applies to cases (3) and (4). 1155 A GIST node processing Q-mode encapsulated messages in this way 1156 SHOULD make the routing decision based on the full contents of the 1157 MRI and not only the IP destination address. It MAY also apply a 1158 restricted set of sanity checks and under certain conditions return 1159 an error message rather than forward the message. These conditions 1160 are: 1162 1. The message is so large that it would be fragmented on downstream 1163 links, for example because the downstream MTU is very small. The 1164 error "Message Too Large" (Appendix A.4.4.8) SHOULD be returned 1165 to the sender, which SHOULD begin messaging association setup. 1167 2. The GIST hop count has reached zero. The error "Hop Limit 1168 Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender, 1169 which MAY retry with a larger initial hop count if it is clear 1170 that a loop has not been formed. 1172 3. The MRI represents a flow definition which is too general to be 1173 forwarded along a unique path (e.g. the destination address 1174 prefix is too short). The error "MRI Validation Failure" 1175 (Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be 1176 returned to the sender, which MAY retry with restricted MRIs, 1177 possibly starting additional signaling sessions to do so. If the 1178 GIST node does not understand the MRM in question it MUST NOT 1179 apply this check, instead forwarding the message transparently. 1181 In the first two cases, only the common header of the GIST message is 1182 examined; in the third case, the MRI is also examined. The rest of 1183 the message MUST never be inspected or modified. 1185 Note that the GIST hop count is only intended to prevent message 1186 looping at the GIST level, and by default NSLPs must take their own 1187 measures to prevent looping at the application level. However, the 1188 GIST API (Appendix B) provides the incoming hop count to the NSLPs, 1189 which can preserve it on outgoing messages as they are forwarded 1190 further along the path. This provides a lightweight loop-prevention 1191 mechanism for NSLPs which do not define anything more sophisticated. 1193 4.4. Routing State and Messaging Association Maintenance 1195 The main responsibility of GIST is to manage the routing state and 1196 messaging associations which are used in the message processing 1197 described above. Routing state is installed and maintained by 1198 specific GIST messages. Messaging associations depend on the 1199 existence of routing state, but are actually set up by the normal 1200 procedures of the transport and security protocols that comprise 1201 them. Timers control routing state and messaging association refresh 1202 and expiration. 1204 There are two different cases for state installation and refresh: 1206 1. Where routing state is being discovered or a new association is 1207 to be established; and 1209 2. Where an existing association can be re-used, including the case 1210 where routing state for the flow is being refreshed. 1212 These cases are now considered in turn, followed by the case of 1213 background general management procedures. 1215 4.4.1. State Setup 1217 The complete sequence of possible messages for GIST state setup 1218 between adjacent peers is shown in Figure 4 and described in detail 1219 in the following text. The figure informally summarises the contents 1220 of each message, including optional elements in []. An example is 1221 given in Appendix C. 1223 +----------+ +----------+ 1224 | Querying | |Responding| 1225 | Node | | Node | 1226 +----------+ +----------+ 1227 Query 1228 ----------------------> ............. 1229 Router Alert Option . Routing . 1230 MRI/SID/NSLPID . state . 1231 Q-Node Network Layer Info . installed . 1232 Query Cookie . at . 1233 [Q-Node Stack-Proposal . R-node(1) . 1234 Q-Node Stack-Config-Data] ............. 1235 [NSLP Payload] 1237 ...................................... 1238 . The responder can use an existing . 1239 . messaging association if available . 1240 . from here onwards to short-circuit . 1241 . messaging association setup . 1242 ...................................... 1244 Response 1245 ............. <---------------------- 1246 . Routing . MRI/SID/NSLPID 1247 . state . R-Node Network Layer Info (D-mode only) 1248 . installed . Query cookie 1249 . at . [Responder Cookie 1250 . Q-Node . [R-Node Stack-Proposal 1251 ............. R-Node Stack-Config-Data]] 1252 [NSLP Payload] 1254 .................................... 1255 . If a messaging association needs . 1256 . to be created, it is set up here . 1257 . and the Confirm uses it . 1258 .................................... 1260 Confirm 1261 ----------------------> 1262 MRI/SID/NSLPID ............. 1263 Q-Node Network Layer Info . Routing . 1264 [Responder Cookie . state . 1265 [R-Node Stack-Proposal . installed . 1266 [Q-Node Stack-Config-Data]]] . at . 1267 [NSLP Payload] . R-node(2) . 1268 ............. 1270 Figure 4: Message Sequence at State Setup 1272 The initial message in any routing state maintenance operation is a 1273 Query, sent from the querying node and intercepted at the responding 1274 node. This message has addressing and other identifiers appropriate 1275 for the flow and signaling application that state maintenance is 1276 being done for, addressing information about the node itself, and it 1277 MAY contain an NSLP payload. It also includes a Query Cookie, and 1278 optionally capability information about messaging association 1279 protocol stacks. The role of the cookies in this and subsequent 1280 messages is to protect against certain denial of service attacks and 1281 to correlate the various events in the message sequence (see 1282 Section 8.5 for further details). 1284 Provided that the signaling application has indicated that message 1285 routing state should be set up (see Section 4.3.2), reception of a 1286 Query MUST elicit a Response. This is a normally encapsulated D-mode 1287 message with additional payloads. It contains network layer 1288 information about the responding node, echoes the Query Cookie, and 1289 MAY contain an NSLP payload, possibly a response to the NSLP payload 1290 in the initial message. In case a messaging association was 1291 requested, it MUST also contain a Responder Cookie and its own 1292 capability information about messaging association protocol stacks. 1293 Even if a messaging association is not requested, the Response MAY 1294 still include a Responder Cookie if the node's routing state setup 1295 policy requires it (see below). 1297 Setup of a new messaging association begins when peer addressing 1298 information is available and a new messaging association is actually 1299 needed. Any setup MUST take place immediately after the specific 1300 Query/Response exchange, because the addressing information used may 1301 have a limited lifetime, either because it depends on limited 1302 lifetime NAT bindings or because it refers to agile destination ports 1303 for the transport protocols. The Stack-Proposal and Stack- 1304 Configuration-Data objects carried in the exchange carry capability 1305 information about what messaging association protocols can be used, 1306 and the processing of these objects is described in more detail in 1307 Section 5.7. With the protocol options currently defined, setup of 1308 the messaging association always starts from the Querying node, 1309 although more flexible configurations are possible within the overall 1310 GIST design. In any case, once set up, the association itself can be 1311 used equally in both directions. 1313 Finally, after any necessary messaging association setup has 1314 completed, a Confirm MUST be sent if the Response requested it. If a 1315 messaging association is being used, the Confirm MUST be sent over it 1316 before any other messages for the same flow, and it echoes the 1317 Responder Cookie and Stack-Proposal from the Response. The former is 1318 used to allow the receiver to validate the contents of the message 1319 (see Section 8.5), and the latter is to prevent certain bidding-down 1320 attacks on messaging association security (see Section 8.6). The 1321 Confirm MAY also contain an abbreviated form of the original Stack- 1322 Configuration-Data to finalise details of the messaging association 1323 configuration. The association can be used in the upstream direction 1324 for the MRI and NSLPID carried in the Confirm, after the Confirm has 1325 been received. 1327 The querying node MUST install the responder address, derived from 1328 the R-Node Network Layer info, as routing state information after 1329 verifying the Query Cookie in the Response. The responding node MAY 1330 install the querying address as peer state information at two points 1331 in time: 1333 1. after the receipt of the initial Query, or 1335 2. after a Confirm containing the Responder Cookie. 1337 The responding node SHOULD derive the peer address from the Q-Node 1338 Network Layer Info if this was decoded successfully. Otherwise, it 1339 MAY be derived from the IP source address of the message if the 1340 common header flags this as being the signalling source address. The 1341 precise constraints on when state information is installed are a 1342 matter of security policy considerations on prevention of denial-of- 1343 service attacks and state poisoning attacks, which are discussed 1344 further in Section 8. Because the responding node MAY choose to 1345 delay state installation as in case (2), the Confirm must contain 1346 sufficient information to allow it to be processed in the same way as 1347 the original Query. This places some special requirements on NAT 1348 traversal and cookie functionality, which are discussed in 1349 Section 7.2 and Section 8 respectively. 1351 4.4.2. Messaging Association Re-use 1353 It is a design goal of GIST that, as far as possible, messaging 1354 associations should be re-used for multiple flows and sessions, 1355 rather than setting up a new MA for each. This is to ensure that the 1356 MA cost scales only with the number of peers, and to avoid the 1357 latency of new MA setup where possible. 1359 However, re-use requires the identification of an existing MA which 1360 matches the same routing state and desired properties that would be 1361 the result of a full handshake in D-mode, and this identification 1362 must be done as reliably and securely as continuing with the full 1363 procedure. Note that this requirement is complicated by the fact 1364 that NATs may remap the node addresses in D-mode messages, and also 1365 interacts with the fact that some nodes may peer over multiple 1366 interfaces (and thus with different addresses). 1368 MA re-use is controlled by the Network-Layer-Information (NLI) 1369 object, which is carried in Query/Confirm and optionally Response 1370 messages. The NLI object includes: 1372 Peer-Identity: For a given node, this is an interface independent 1373 value with opaque syntax. It MUST be chosen so as to have a high 1374 probability of uniqueness between peers, and SHOULD be stable at 1375 least until the next node restart. Note that there is no 1376 cryptographic protection of this identity; attempting to provide 1377 this would essentially duplicate the functionality in the 1378 messaging association security protocols. 1380 Interface-Address: This is an IP address through which the signaling 1381 node can be reached. There may be several choices available for 1382 the Interface-Address, and further discussion of this is contained 1383 in Section 5.2.2. 1385 By default, a messaging association is associated with the NLI object 1386 that was provided by the peer in the Query/Response/Confirm at the 1387 time the association was set up. There may be more than one 1388 association for a given NLI object, for example with different 1389 security or transport properties. 1391 MA re-use is controlled by matching the NLI provided in a GIST 1392 message with those associated with existing MAs. This can be done on 1393 receiving either a Query or Response, although the former is more 1394 likely: 1396 o If there is a perfect match to the NLI of an existing association, 1397 that association SHOULD be re-used, provided it has the 1398 appropriate properties in other respects. This is indicated by 1399 sending the remaining messages in the handshake over that 1400 association. This will only fail, that is, lead to re-use of an 1401 association to the wrong node, if signaling nodes have colliding 1402 Peer-Identities and one is reachable at the same Interface-Address 1403 as another. This could be done by an on-path attacker. 1405 o In all other cases, the full handshake MUST be executed in D-mode 1406 as usual. There are in fact four possibilities: 1408 1. Nothing matches: this is clearly a new peer. 1410 2. Only the Peer-Identity matches: this may be either a new 1411 interface on an existing peer, or a changed address mapping 1412 behind a NAT, or an attacker attempting to hijack the Peer- 1413 Identity. These should be rare events, so the expense of a 1414 new association setup is acceptable. 1416 3. Only the Interface-Address matches: this is probably a new 1417 peer behind the same NAT as an existing one. A new 1418 association setup is required. 1420 4. The full NLI object matches: this is a degenerate case, where 1421 one node recognises an existing peer, but wishes to allow the 1422 option to set up a new association in any case, for example to 1423 create an association with different properties. 1425 4.4.3. State Maintenance Procedures 1427 Refresh and expiration of all types of GIST state is controlled by 1428 timers. 1430 Each item of routing state expires after a lifetime which is 1431 negotiated during the Query/Response/Confirm handshake. The Network 1432 Layer Info (NLI) object in the Query contains a proposal for the 1433 lifetime value, and the NLI in the Response contains the value the 1434 Responding node requires. A default timer value of 30 seconds is 1435 RECOMMENDED. Nodes which can exploit alternative, more powerful, 1436 route change detection methods such as those described in 1437 Section 7.1.2 MAY choose to use much longer times. Nodes MAY use 1438 shorter times to provide more rapid change detection, but MUST take 1439 into account the fact that the Query messages generated may stress 1440 the rate limits applied to D-mode traffic (Section 5.3.3). 1442 The Querying node MUST generate a Query before this timer expires, if 1443 it believes that the signaling session is still active; otherwise, 1444 the Responding node MAY delete the state. Receipt of the message at 1445 the Responding node will refresh peer addressing state for one 1446 direction, and receipt of a Response at the querying node will 1447 refresh it for the other. There is no mechanism at the GIST level 1448 for explicit teardown of routing state. However, GIST MUST NOT 1449 refresh routing state if a signaling session is known to be inactive, 1450 either because upstream state has expired, or because the signaling 1451 application has indicated via the GIST API (Appendix B.5) that the 1452 state is no longer required, because this would prevent correct state 1453 repair in the case of network rerouting. 1455 Unneeded MAs are torn down by GIST, using the teardown mechanisms of 1456 the underlying transport or security protocols if available, for 1457 example by simply closing a TCP connection. The teardown can be 1458 initiated by either end. Whether an MA is needed is a combination of 1459 two factors: 1461 o local policy, which could take into account the cost of keeping 1462 the messaging association open, the level of past activity on the 1463 association, and the likelihood of future activity, e.g. if there 1464 is routing state still in place which might generate messages to 1465 use it. 1467 o whether the peer still wants the MA in place. During MA setup, 1468 each node indicates its own MA-Hold-Time as part of the Stack- 1469 Configuration-Data. A node MUST NOT tear down the MA if it has 1470 received traffic from its peer over that period. A peer which has 1471 generated no traffic but still wants the MA retained may use a 1472 special null message (MA-Hello) to indicate the fact. A default 1473 value for MA-Hold-Time of 30 seconds is RECOMMENDED. Nodes MAY 1474 use shorter times to achieve more rapid peer failure detection, 1475 but need to take into account the load on the network created by 1476 the MA-Hello messages. Nodes MAY use longer times, but need to 1477 take into account the cost of retaining idle MAs for extended 1478 periods. 1480 Because the Responding node can choose not to retain state until a 1481 Confirm, an abbreviated Stack-Configuration-Data object containing 1482 just this information MUST be repeated by the Querying node in the 1483 first Confirm sent on a new MA. 1485 Messaging associations can always be set up on demand, and messaging 1486 association status is not made directly visible outside the GIST 1487 layer. Therefore, even if GIST tears down and later re-establishes a 1488 messaging association, signaling applications cannot distinguish this 1489 from the case where the MA is kept permanently open. To maintain the 1490 transport semantics described in Section 4.1, GIST MUST close 1491 transport connections carrying reliable messages gracefully or report 1492 an error condition, and MUST NOT open a new association for a given 1493 session and peer while messages on a previous association may still 1494 be outstanding. 1496 This specification defines precisely only the time at which routing 1497 state or messaging associations expire; it does not define when 1498 refresh handshakes or keepalives should be initiated. 1499 Implementations MUST select timer settings which take at least the 1500 following into account: 1502 o The transmission latency between source and destination; 1504 o The need for retransmissions, either explicitly or within the 1505 messaging association protocols; 1507 o The need to avoid network synchronisation of control traffic (cf. 1508 [39]). 1510 In most cases, a reasonable policy is to initiate the refresh process 1511 when between 1/2 and 3/4 of the appropriate validity time has elapsed 1512 since the last successful refresh. The actual moment is chosen 1513 randomly within this interval to avoid synchronisation effects. 1515 5. Message Formats and Transport 1517 5.1. GIST Messages 1519 All GIST messages begin with a common header, followed by a sequence 1520 of type-length-value (TLV) objects. This subsection describes the 1521 various GIST messages and their contents at a high level in ABNF [9]; 1522 a more detailed description of the header and each object is given in 1523 Section 5.2. Note that the NAT traversal mechanism for GIST involves 1524 the insertion of an additional NAT-Traversal-Object in Query, 1525 Response, and some Data and Error messages; the rules for this are 1526 given in Section 7.2. 1528 GIST-Message: The primary messages are either one of the stages in 1529 the three-way handshake, or a simple message carrying NSLP data. 1530 Additional types are defined for errors and keeping messaging 1531 associations alive. 1533 GIST-Message = Query / Response / Confirm / 1534 Data / Error / MA-Hello 1536 The common header includes a version number, message type and size, 1537 and NSLPID. It also carries a hop count to prevent message looping 1538 and various control flags, including one (the R flag) to indicate if 1539 a reply of some sort is requested. The objects following the common 1540 header MUST be carried in a fixed order, depending on message type. 1541 Messages with missing, duplicate or invalid objects for the message 1542 type MUST be rejected with an "Object Type Error" error message with 1543 the appropriate subcode (Appendix A.4.4.9). 1545 Query: A Query MUST be sent in D-mode, in fact with the special 1546 Q-mode encapsulation. In addition to the common header, it contains 1547 certain mandatory control objects, and MAY contain a signaling 1548 application payload. A stack proposal and configuration data MUST be 1549 included if the message exchange relates to setup of a messaging 1550 association. The R flag MUST always be set (R=1) in a Query, since 1551 this message always elicits a Response. 1553 Query = Common-Header 1554 [ NAT-Traversal-Object ] 1555 Message-Routing-Information 1556 Session-Identification 1557 Network-Layer-Information 1558 Query-Cookie 1559 [ Stack-Proposal Stack-Configuration-Data ] 1560 [ NSLP-Data ] 1562 Response: A Response may be sent in D-mode, or C-mode if a messaging 1563 association is being re-used. It MUST echo the MRI SID and Query- 1564 Cookie of the Query, and in D-mode carries its own Network-Layer- 1565 Information; if the message exchange relates to setup of a messaging 1566 association, which can only take place in D-mode, a Responder cookie 1567 MUST be included, as well as its own stack proposal and configuration 1568 data. The R flag MUST be set (R=1) if a Responder cookie is present 1569 but otherwise is optional; if the R flag is set, a Confirm MUST be 1570 sent as a reply. Note that the direction of this MRI will be 1571 inverted compared to that in the Query, that is, an upstream MRI 1572 becomes downstream and vice versa (see Section 3.3). 1574 Response = Common-Header 1575 [ NAT-Traversal-Object ] 1576 Message-Routing-Information 1577 Session-Identification 1578 [ Network-Layer-Information ] 1579 Query-Cookie 1580 [ Responder-Cookie 1581 [ Stack-Proposal Stack-Configuration-Data ] ] 1582 [ NSLP-Data ] 1584 Confirm: A Confirm may be sent in D-mode, or C-mode if a messaging 1585 association has been re-used. It MUST echo the MRI (with inverted 1586 direction), SID, and Responder-Cookie if the Response carried one; if 1587 the message exchange relates to setup of a new messaging association 1588 or re-use of an existing one (which can only take place in C-mode), 1589 the message MUST also echo the Stack-Proposal from the Response so it 1590 can be verified that this has not been tampered with. The first 1591 message on an association MUST also repeat the Stack-Configuration- 1592 Data from the original Query in an abbreviated form, just containing 1593 the MA-Hold-Time. 1595 Confirm = Common-Header 1596 Message-Routing-Information 1597 Session-Identification 1598 Network-Layer-Information 1599 [ Responder-Cookie 1600 [ Stack-Proposal 1601 [ Stack-Configuration-Data ] ] ] 1602 [ NSLP-Data ] 1604 Data: The Data message is used to transport NSLP data without 1605 modifying GIST state. It contains no control objects, but only the 1606 MRI and SID associated with the NSLP data being transferred. 1607 Network-Layer-Information (NLI) MUST be carried in the D-mode case, 1608 but MUST NOT be included otherwise. 1610 Data = Common-Header 1611 [ NAT-Traversal-Object ] 1612 Message-Routing-Information 1613 Session-Identification 1614 [ Network-Layer-Information ] 1615 NSLP-Data 1617 Error: An Error message reports a problem determined at the GIST 1618 level. (Errors generated by signaling applications are reported in 1619 NSLP-Data payloads and are not treated specially by GIST.) The 1620 message includes a Network-Layer-Information object for the 1621 originator of the error message if it is being sent in D-mode; all 1622 other information related to the error is carried in a GIST-Error- 1623 Data object. 1625 Error = Common-Header 1626 [ NAT-Traversal-Object ] 1627 [ Network-Layer-Information ] 1628 GIST-Error-Data 1630 MA-Hello: This message MUST be sent only in C-mode to indicate that a 1631 node wishes to keep a messaging association open. It contains only 1632 the common header, with a NSLPID of zero. The R flag MAY be set 1633 (R=1); if so, the peer MUST send another message back along the 1634 messaging association. This allows a node to test the liveness of 1635 the peer. 1637 MA-Hello = Common-Header 1639 5.2. Information Elements 1641 This section describes the content of the various objects that can be 1642 present in each GIST message, both the common header, and the 1643 individual TLVs. The bit formats are provided in Appendix A. 1645 5.2.1. The Common Header 1647 Each message begins with a fixed format common header, which contains 1648 the following information: 1650 Version: The version number of the GIST protocol. This 1651 specification defines GIST version 1. 1653 Length: The number of 32 bit words in the message following the 1654 common header. 1656 Upper layer identifier (NSLPID): This gives the specific NSLP that 1657 this message is used for. 1659 GIST hop count: A hop count to prevent a message from looping. 1661 Message type: The message type (Query, Response, etc.) 1663 Source addressing mode: If set (S=1), this indicates that the IP 1664 source address of the message is the same as the IP address of the 1665 signaling peer, so replies to this message can be sent safely to 1666 this address. S is always set in C-mode. It is cleared (S=0) if 1667 the IP source address was derived from the message routing 1668 information in the payload and this is different from the 1669 signaling source address. 1671 Response requested: A flag which if set (R=1) indicates that a GIST 1672 message should be sent in response to this message. The 1673 appropriate message type for the response depends on the type of 1674 the initial message. 1676 Explicit routing: A flag which if set (E=1) indicates that the 1677 message was explicitly routed (see Section 7.1.4). 1679 5.2.2. TLV Objects 1681 All data following the common header is encoded as a sequence of 1682 type-length-value objects. Currently, each object can occur at most 1683 once; the set of required and permitted objects is determined by the 1684 message type and encapsulation (D-mode or C-mode). 1686 Message-Routing-Information (MRI): Information sufficient to define 1687 how the signaling message should be routed through the network. 1689 Message-Routing-Information = message-routing-method 1690 method-specific-information 1692 The format of the method-specific-information depends on the 1693 message-routing-method requested by the signaling application. 1694 Note that it always includes a flag defining the direction as 1695 either 'upstream' or 'downstream' (see Section 3.3). It is 1696 provided by the NSLP in the message sender and used by GIST to 1697 select the message routing. 1699 Session-Identification (SID): The GIST session identifier is a 128 1700 bit, cryptographically random identifier chosen by the node which 1701 originates the signaling exchange. See Section 3.5. 1703 Network-Layer-Information (NLI): This object carries information 1704 about the network layer attributes of the node sending the 1705 message, including data related to the management of routing 1706 state. This includes a peer identity and IP address for the 1707 sending node. It also includes IP-TTL information to allow the IP 1708 hop count between GIST peers to be measured and reported, and a 1709 validity time (RS-validity-time) for the routing state. 1711 Network-Layer-Information = peer-identity 1712 interface-address 1713 RS-validity-time 1714 IP-TTL 1716 The use of the RS-validity-time field is described in 1717 Section 4.4.3. The peer-identity and interface-address are used 1718 for matching existing associations, as discussed in Section 4.4.2. 1720 The interface-address must be routable, i.e. it MUST be usable as 1721 a destination IP address for packets to be sent back to the node 1722 generating the signaling message, whether in D-mode or C-mode. If 1723 this object is carried in a Query or Confirm, the interface- 1724 address MUST specifically be set to an address bound to the 1725 interface associated with the MRI, to allow its use in route 1726 change handling as discussed in Section 7.1. A suitable choice is 1727 the interface that is carrying the outbound flow. A node may have 1728 several choices for which of its addresses to use as the 1729 interface-address. For example, there may be a choice of IP 1730 versions, or addresses of limited scope (e.g. link-local), or 1731 addresses bound to different interfaces in the case of a router or 1732 multi-homed host. However, some of these interface addresses may 1733 not be usable by the peer. A node MUST follow a policy of using a 1734 global address of the same IP version as in the MRI, unless it can 1735 establish that an alternative address would also be usable. 1737 The setting and interpretation of the IP-TTL field depends on the 1738 message direction (upstream/downstream as determined from the MRI 1739 as described above) and encapsulation. 1741 * If the message is sent downstream, if the TTL that will be set 1742 in the IP header for the message can be determined, the IP-TTL 1743 value MUST be set to this value, or else set to 0. 1745 * On receiving a downstream message in D-mode, a non-zero IP-TTL 1746 is compared to the TTL in the IP header, and the difference is 1747 stored as the IP-hop-count-to-peer for the upstream peer in the 1748 routing state table for that flow. Otherwise, the field is 1749 ignored. 1751 * If the message is sent upstream, the IP-TTL MUST be set to the 1752 value of the IP-hop-count-to-peer stored in the routing state 1753 table, or 0 if there is no value yet stored. 1755 * On receiving an upstream message, the IP-TTL is stored as the 1756 IP-hop-count-to-peer for the downstream peer. 1758 In all cases, the IP-TTL value reported to signaling applications 1759 is the one stored with the routing state for that flow, after it 1760 has been updated if necessary from processing the message in 1761 question. 1763 Stack-Proposal: This field contains information about which 1764 combinations of transport and security protocols are available for 1765 use in messaging associations, and is also discussed further in 1766 Section 5.7. 1768 Stack-Proposal = 1*stack-profile 1770 stack-profile = 1*protocol-layer 1772 Each protocol-layer field identifies a protocol with a unique tag; 1773 any additional data, such as higher-layer addressing or other 1774 options data associated with the protocol, will be carried in a 1775 MA-protocol-options field in the Stack-Configuration-Data TLV (see 1776 below). 1778 Stack-Configuration-Data (SCD): This object carries information 1779 about the overall configuration of a messaging association. 1781 Stack-Configuration-Data = MA-Hold-Time 1782 0*MA-protocol-options 1784 The MA-Hold-Time field indicates how long a node will hold open an 1785 inactive association; see Section 4.4.3 for more discussion. The 1786 MA-protocol-options fields give the configuration of the protocols 1787 (e.g. TCP, TLS) to be used for new messaging associations, and 1788 they are described in more detail in Section 5.7. 1790 Query-Cookie/Responder-Cookie: A Query-Cookie is contained in a 1791 Query and MUST be echoed in a Response; a Responder-Cookie MAY be 1792 sent in a Response, and if present MUST be echoed in the following 1793 Confirm. Cookies are variable length bit strings, chosen by the 1794 cookie generator. See Section 8.5 for further details on 1795 requirements and mechanisms for cookie generation. 1797 NSLP-Data: The NSLP payload to be delivered to the signaling 1798 application. GIST does not interpret the payload content. 1800 GIST-Error-Data: This contains all the information to determine the 1801 cause and context of an error. 1803 GIST-Error-Data = error-class error-code error-subcode 1804 common-error-header 1805 [ Message-Routing-Information-content ] 1806 [ Session-Identification-content ] 1807 0*additional-information 1808 [ comment ] 1810 The error-class indicates the severity level, and the error-code 1811 and error-subcode identify the specific error itself. A full list 1812 of GIST errors and their severity levels is given in Appendix A.4. 1813 The common-error-header carries the Common-Header from the 1814 original message, and contents of the Message-Routing-Information 1815 (MRI) and Session-Identification (SID) objects are also included 1816 if they were successfully decoded. For some errors, additional 1817 information fields must be included according to a fixed format; 1818 finally, an optional free-text comment may be added. 1820 5.3. D-mode Transport 1822 This section describes the various encapsulation options for D-mode 1823 messages. Although there are several possibilities, depending on 1824 message type, MRM, and local policy, the general design principle is 1825 that the sole purpose of the encapsulation is to ensure that the 1826 message is delivered to or intercepted at the correct peer. Beyond 1827 that, minimal significance is attached to the type of encapsulation 1828 or the values of addresses or ports used for it. This allows new 1829 options to be developed in the future to handle particular deployment 1830 requirements without modifying the overall protocol specification. 1832 5.3.1. Normal Encapsulation 1834 Normal encapsulation MUST be used for all D-mode messages where the 1835 signaling peer is already known from previous signaling. This 1836 includes Response and Confirm messages, and Data messages except if 1837 these are being sent without using local routing state. Normal 1838 encapsulation is simple: the complete set of GIST payloads is 1839 concatenated together with the common header, and placed in the data 1840 field of a UDP datagram. UDP checksums MUST be enabled. The message 1841 is IP addressed directly to the adjacent peer as given by the routing 1842 state table. Where the message is a direct reply to a Query and no 1843 routing state exists, the destination address is derived from the 1844 input message using the same rules as in Section 4.4.1. The UDP port 1845 numbering MUST be compatible with that used on Query messages (see 1846 below), that is, the same for messages in the same direction and with 1847 port numbers swapped for messages in the opposite direction. 1849 5.3.2. Q-mode Encapsulation 1851 Q-mode encapsulation MUST be used for messages where no routing state 1852 is available or where the routing state is being refreshed, in 1853 particular for Query messages. Q-mode encapsulation is similar to 1854 normal encapsulation, with changes in IP address selection, IP 1855 options, and a defined method for selecting UDP ports. 1857 In general, the IP addresses are derived from information in the MRI; 1858 the exact rules depend on the MRM. For all current MRMs, the IP 1859 header is given a Router Alert Option ([1] and [5]) to assist the 1860 peer in intercepting the message depending on the NSLPID. Each 1861 NSLPID maps to a unique RAO value, but one RAO value may refer to 1862 multiple NSLPIDs; further details are discussed in [11]. 1864 The source UDP port is selected by the message sender as the port at 1865 which it is prepared to receive UDP messages in reply, and a 1866 destination UDP port is allocated for GIST by IANA (see Section 9). 1867 Note that for some MRMs, GIST nodes anywhere along the path can 1868 generate GIST packets with source addresses that spoof the source 1869 address of the data flow. Therefore, destinations cannot distinguish 1870 these packets from genuine end-to-end data purely on address 1871 analysis. Instead, it must be possible to distinguish such GIST 1872 packets by port analysis; furthermore, the mechanism to do so must 1873 remain valid even if the destination is GIST-unaware. GIST solves 1874 this problem by using a fixed destination UDP port from the "well 1875 known" space for the Q-mode encapsulation. This port should never be 1876 allocated on a GIST-unaware host, and therefore Q-mode encapsulated 1877 messages will always be rejected with an ICMP error. 1879 5.3.3. Retransmission and Rate Control 1881 D-mode uses UDP, and hence has no automatic reliability or congestion 1882 control capabilities. Signaling applications requiring reliability 1883 should be serviced using C-mode, which should also carry the bulk of 1884 signaling traffic. However, some form of messaging reliability is 1885 required for the GIST control messages themselves, as is rate control 1886 to handle retransmissions and also bursts of unreliable signaling or 1887 state setup requests from the signaling applications. 1889 Query messages which do not receive Responses MAY be retransmitted; 1890 retransmissions MUST use a binary exponential backoff. The initial 1891 timer value is T1, which the backoff process can increase up to a 1892 maximum value of T2 seconds. The default value for T1 is 500 ms. T1 1893 is an estimate of the round-trip time between the querying and 1894 responding nodes. Elements MAY use smaller values of T1 if it is 1895 known that the Query should be answered within the local network. T1 1896 MAY be chosen larger, and this is RECOMMENDED if it is known in 1897 advance (such as on high latency access links) that the round-trip 1898 time is larger. The default value of T2 is 64*T1. 1900 Note that Queries may go unanswered either because of message loss 1901 (in either direction), or because there is no reachable GIST peer. 1902 Therefore, implementations MAY trade off reliability (large T2) 1903 against promptness of error feedback to applications (small T2). If 1904 the NSLP has indicated a timeout on the validity of this payload (see 1905 Appendix B.1), T2 MUST be chosen so that the process terminates 1906 within this timeout. 1908 Retransmitted Queries MUST use different Query-Cookie values. If the 1909 Query carries NSLP data, it may be delivered multiple times to the 1910 signaling application. These rules apply equally to the message that 1911 first creates routing state, and those that refresh it. 1913 This algorithm is sufficient to handle lost Queries and Responses. 1914 The case of a lost Confirm is more subtle. Notionally, we can 1915 distinguish between two cases: 1917 1. Where the Responding node is already prepared to store per-flow 1918 state after receiving a single (Query) message. This would 1919 include any cases where the node has NSLP data queued to send. 1920 Here, the Responding node MAY run a retransmission timer to 1921 resend the Response until a Confirm is received, since the node 1922 is already managing state for that flow. The problem of an 1923 amplification attack stimulated by a malicious Query is handled 1924 by requiring the cookie mechanism to enable the node receiving 1925 the Response to discard it efficiently if it does not match a 1926 previously sent Query. 1928 2. Where the responding node is not prepared to store per-flow state 1929 until receiving a properly formed Confirm. 1931 Case (2) should be handled without requiring a retransmission timer, 1932 since this would require per-flow state at the Responding node. 1933 However, we can assume that the next signaling message will be in the 1934 direction Querying Node -> Responding Node (if there is no next 1935 signaling message, the fact that the Confirm has been lost is moot). 1936 In this case, the responding node will start to receive messages at 1937 the GIST level for a MRI/NSLP combination for which there is no 1938 stored routing state, since this state is only created on receipt of 1939 a Confirm. 1941 Therefore, the error condition is detected at the Responding node 1942 when such a message arrives, without the need for a specific timer. 1943 Recovery requires a Confirm to be transmitted and successfully 1944 received. The mechanism to cause this is that the Responding node 1945 MUST reject the incoming message with a "No Routing State" error 1946 message (Appendix A.4.4.5) back to the Querying node, which MUST 1947 interpret this as caused by a lost Confirm; the Querying node MUST 1948 regenerate the Confirm purely from local state. In particular, it 1949 needs to remember a valid Responder Cookie. 1951 In all cases, Responses MUST be sent promptly to avoid spurious 1952 retransmissions. Nodes generating any type of retransmission MUST be 1953 prepared to receive and match a reply to any of them, not just the 1954 one most recently sent. 1956 The basic rate-control requirements for D-mode traffic are 1957 deliberately minimal. A single rate limiter applies to all traffic, 1958 for all interfaces and message types. It applies to retransmissions 1959 as well as new messages, although an implementation MAY choose to 1960 prioritise one over the other. Rate-control applies only to locally 1961 generated D-mode messages, not to messages which are being forwarded. 1962 When the rate limiter is in effect, D-mode messages MUST be queued 1963 until transmission is re-enabled, or an error condition MAY be 1964 indicated back to local signaling applications. The rate limiting 1965 mechanism is implementation-defined, but it is RECOMMENDED that a 1966 token bucket limiter as described in [31] be used. The token bucket 1967 MUST be sized to ensure that a node cannot saturate the network with 1968 D-mode traffic, for example when re-probing the network for multiple 1969 flows after a route change. A suitable approach is to restrict the 1970 token bucket parameters so that the mean output rate is a small 1971 fraction, such as 5%, of the node's lowest-speed interface. 1973 5.4. C-mode Transport 1975 Encapsulation in C-mode is more complex, because of the variation in 1976 available transport functionality. This issue is treated in 1977 Section 5.4.1. The actual encapsulation is given in Section 5.4.2. 1979 5.4.1. Choice of Transport Protocol 1981 It is a general requirement of the NTLP defined in [26] that it 1982 should be able to support bundling of small messages, fragmentation 1983 of large messages, and message boundary delineation. Not all 1984 transport protocols natively support all these features. 1986 TCP provides both bundling and fragmentation, but not message 1987 boundaries. However, the length information in the GIST common 1988 header allows the message boundary to be discovered during 1989 parsing. 1991 SCTP [16] satisfies all requirements. 1993 DCCP [30] is message-based but does not provide bundling or 1994 fragmentation, nor does it provide reliability. Bundling can be 1995 carried out by the GIST layer sending multiple messages in a 1996 single datagram; because the common header includes length 1997 information, the message boundaries within the datagram can be 1998 discovered during parsing. Fragmentation of GIST messages over 1999 multiple datagrams should be avoided, because of amplification of 2000 message loss rates that this would cause. 2002 The bundling together of small messages is either built into the 2003 transport protocol or can be carried out by the GIST layer during 2004 message construction. Either way, two approaches can be 2005 distinguished: 2007 1. As messages arrive for transmission they are gathered into a 2008 bundle until a size limit is reached or a timeout expires (cf. 2009 the Nagle algorithm of TCP or similar optional functionality in 2010 SCTP). This provides maximal efficiency at the cost of some 2011 latency. 2013 2. Messages awaiting transmission are gathered together while the 2014 node is not allowed to send them, for example because it is 2015 congestion controlled. 2017 The second type of bundling is always appropriate. For GIST, the 2018 first type MUST NOT be used for trigger messages (i.e. messages that 2019 update GIST or signaling application state), but may be appropriate 2020 for refresh messages (i.e. messages that just extend timers). These 2021 distinctions are known only to the signaling applications, but MAY be 2022 indicated (as an implementation issue) by setting the priority 2023 transfer attribute (Section 4.1.2). 2025 It can be seen that all of these transport protocol options can be 2026 supported by the basic GIST message format already presented. GIST 2027 messages requiring fragmentation must be carried using a reliable 2028 transport protocol, TCP or SCTP. This specification defines only the 2029 use of TCP, but other possibilities could be included without 2030 additional work on message formatting. 2032 5.4.2. Encapsulation Format 2034 The GIST message, consisting of common header and TLVs, is carried 2035 directly in the transport protocol, possibly incorporating transport 2036 layer security protection. Further messages can be carried in a 2037 continuous stream (for TCP), or up to the next transport layer 2038 message boundary (for SCTP, DCCP, or UDP). This is shown in 2039 Figure 5. 2041 +---------------------------------------------+ 2042 | L2 Header | 2043 +---------------------------------------------+ 2044 | IP Header | ^ 2045 | Source address = signaling source | ^ 2046 | Destination address = signaling destination | . 2047 +---------------------------------------------+ . 2048 | L4 Header | . ^ 2049 | (Standard TCP/SCTP/DCCP/UDP header) | . ^ 2050 +---------------------------------------------+ . . 2051 | GIST Message | . . ^ 2052 | (Common header and TLVs as in section 5.1) | . . ^ Scope of 2053 +---------------------------------------------+ . . . security 2054 | Additional GIST messages, each with its | . . . protection 2055 | own common header, either as a continuous | . . . (depending 2056 | stream, or continuing to the next L4 | . . . on channel 2057 . message boundary . . . . security 2058 . . V V V mechanism 2059 . . V V V in use) 2061 Figure 5: C-mode Encapsulation 2063 5.5. Message Type/Encapsulation Relationships 2065 GIST has four primary message types (Query, Response, Confirm, and 2066 Data) and three possible encapsulation methods (normal D-mode, 2067 Q-mode, and C-mode). The possible combinations of message type and 2068 encapsulation are given in the table below. In some cases there are 2069 several possible choices, depending on the existence of routing state 2070 or messaging associations. The rules governing GIST policy, 2071 including whether or not to create such state to handle a message, 2072 are described normatively in the other sections of this 2073 specification. If a message arrives with an invalid encapsulation 2074 (e.g. a Query arrives over a messaging association), this MUST be 2075 rejected with an "Incorrect Encapsulation" error message 2076 (Appendix A.4.4.3). However, it should be noted that the processing 2077 of the message at the receiver is not otherwise affected by the 2078 encapsulation method used, except that that the decapsulation process 2079 may provide additional information, such as translated addresses or 2080 IP hop count to be used in the subsequent message processing. 2082 +----------+-----------------+---------------------+----------------+ 2083 | Message | Normal D-mode | Query D-mode | C-mode | 2084 | | | (Q-mode) | | 2085 +----------+-----------------+---------------------+----------------+ 2086 | Query | Never | Always | Never | 2087 | | | | | 2088 | Response | Unless a | Never | If a messaging | 2089 | | messaging | | association is | 2090 | | association is | | being re-used | 2091 | | being re-used | | | 2092 | | | | | 2093 | Confirm | Unless a | Never | If a messaging | 2094 | | messaging | | association | 2095 | | association has | | has been set | 2096 | | been set up or | | up or is being | 2097 | | is being | | re-used | 2098 | | re-used | | | 2099 | | | | | 2100 | Data | If routing | If no routing state | If a messaging | 2101 | | state exists | exists and the MRI | association | 2102 | | for the flow | can be used to | exists | 2103 | | but no | derive the Q-mode | | 2104 | | messaging | encapsulation | | 2105 | | association | | | 2106 +----------+-----------------+---------------------+----------------+ 2108 5.6. Error Message Processing 2110 Special rules apply to the encapsulation and transmission of error 2111 messages. 2113 GIST only generates error messages in response to incoming messages. 2114 Error messages MUST NOT be generated in response to incoming error 2115 messages. The routing and encapsulation of the error message is 2116 derived from that of the message that caused the error; in 2117 particular, local routing state is not consulted. Routing state and 2118 messaging association state MUST NOT be created to handle the error, 2119 and error messages MUST NOT be retransmitted explicitly by GIST, 2120 although they are subject to the same rate control as other messages. 2122 o If the incoming message was received in D-mode, the error MUST be 2123 sent in D-mode using the normal encapsulation, using the 2124 addressing information from the NLI object in the incoming 2125 message. If the NLI could not be determined, the error MUST be 2126 sent to the IP source of the incoming message if the S flag was 2127 set in it. The NLI object in the Error message reports 2128 information about the originator of the error. 2130 o If the incoming message was received over a messaging association, 2131 the error MUST be sent back over the same messaging association. 2133 The NSLPID in the common header of the Error message has the value 2134 zero. If for any reason the message cannot be sent, for example, 2135 because it is too large to send in D-mode, an error SHOULD be logged 2136 locally. 2138 5.7. Messaging Association Setup 2140 5.7.1. Overview 2142 A key attribute of GIST is that it is flexible in its ability to use 2143 existing transport and security protocols. Different transport 2144 protocols may have performance attributes appropriate to different 2145 environments; different security protocols may fit appropriately with 2146 different authentication infrastructures. Even given an initial 2147 default mandatory protocol set for GIST, the need to support new 2148 protocols in the future cannot be ruled out, and secure feature 2149 negotiation cannot be added to an existing protocol in a backwards- 2150 compatible way. Therefore, some sort of capability discovery is 2151 required. 2153 Capability discovery is carried out in Query and Response messages, 2154 using Stack-Proposal and Stack-Configuration-Data objects. If a new 2155 messaging association is required it is then set up, followed by a 2156 Confirm. Messaging association re-use is achieved by short- 2157 circuiting this exchange by sending the Response or Confirm messages 2158 on an existing association (Section 4.4.2); whether to do this is a 2159 matter of local policy. The end result of this process is a 2160 messaging association which is a stack of protocols. If multiple 2161 associations exist, it is a matter of local policy how to distribute 2162 messages over them, subject to respecting the transfer attributes 2163 requested for each message. 2165 Every possible protocol for a messaging association has the following 2166 attributes: 2168 o MA-Protocol-ID, a 1-byte IANA assigned value (see Section 9). 2170 o A specification of the (non-negotiable) policies about how the 2171 protocol should be used; for example, in which direction a 2172 connection should be opened. 2174 o [Depending on the specific protocol:] Formats for an MA-protocol- 2175 options field to carry the protocol addressing and other 2176 configuration information in the Stack-Configuration-Data object. 2177 The format may differ depending on whether the field is present in 2178 the Query or Response. Some protocols do not require the 2179 definition of such additional data, in which case no corresponding 2180 MA-protocol-options field will occur in the SCD object. 2182 A Stack-Proposal object is simply a list of profiles; each profile is 2183 a sequence of MA-Protocol-IDs. A profile lists the protocols in 'top 2184 to bottom' order (e.g. TLS over TCP, or TCP over IPsec). A Stack- 2185 Proposal is generally accompanied by a Stack-Configuration-Data 2186 object which carries an MA-protocol-options field for any protocol 2187 listed in the Stack-Proposal which needs it. An MA-protocol-options 2188 field may apply globally, to all instances of the protocol in the 2189 Stack-Proposal; or it can be tagged as applying to a specific 2190 instance. The latter approach can be used to carry different port 2191 numbers for TCP depending on whether it is to be used with or without 2192 TLS. An MA-protocol-options field may also be flagged as not usable; 2193 for example, a NAT which could not handle SCTP would set this in an 2194 MA-protocol-options field about SCTP. A protocol flagged this way 2195 MUST NOT be used for a messaging association. If the Stack-Proposal 2196 and Stack-Configuration-Data are both present but not consistent, for 2197 example, if they refer to different protocols, or an MA-protocol- 2198 options field refers to a non-existent profile, an "Object Value 2199 Error" error message (Appendix A.4.4.10) with subcode 5 ("Stack- 2200 Proposal - Stack-Configuration-Data Mismatch") MUST be returned and 2201 the message dropped. 2203 A node generating a Stack-Configuration-Data object MUST honour the 2204 implied protocol configurations for the period during which a 2205 messaging association might be set up; in particular, it MUST be 2206 immediately prepared to accept incoming datagrams or connections at 2207 the protocol/port combinations advertised. This MAY require the 2208 creation of listening endpoints for the transport and security 2209 protocols in question, or a node MAY keep a pool of such endpoints 2210 open for extended periods. However, the received object contents 2211 MUST be retained only for the duration of the Query/Response exchange 2212 and to allow any necessary association setup to complete. They may 2213 become invalid because of expired bindings at intermediate NATs, or 2214 because the advertising node is using agile ports. Once the setup is 2215 complete, or if it is not necessary, or fails for some reason, the 2216 object contents MUST be discarded. A default time of 30 seconds to 2217 keep the contents is RECOMMENDED. 2219 A Query requesting association setup always contains a Stack-Proposal 2220 and Stack-Configuration-Data object. The Stack-Proposal MUST only 2221 include protocol configurations that are suitable for the transfer 2222 attributes of the messages that the Querying node wishes use the 2223 messaging association for. For example, it should not simply include 2224 all configurations that the Querying node is capable of supporting. 2226 The Response always contains a Stack-Proposal and Stack- 2227 Configuration-Data object, unless re-use (where the Responder decides 2228 to use an existing association) occurs. For such a Response, the 2229 Stack-Proposal MUST NOT depend on the Query. A node MAY make 2230 different proposals depending on the combination of interface and 2231 NSLPID. If re-use does occur, which is indicated by sending the 2232 Response over an existing messaging association, the following rules 2233 apply: 2235 o The re-used messaging association MUST NOT have weaker security 2236 properties than would have been offered in the full Response that 2237 would have been sent without re-use. 2239 o The re-used messaging association MUST have equivalent or better 2240 transport and security characteristics as at least one of the 2241 protocol configurations that was offered in the Query. 2243 Once the messaging association is set up, the querying node repeats 2244 the responder's Stack-Proposal over it in the Confirm. The 2245 responding node MUST verify that this has not been changed as part of 2246 bidding-down attack prevention. If a difference is detected, the 2247 responding node MUST terminate the messaging association and SHOULD 2248 log an error condition locally. See Section 8.6 for further 2249 discussion. 2251 5.7.2. Protocol Definition: Forwards-TCP 2253 This MA-Protocol-ID denotes a basic use of TCP between peers. 2254 Support for this protocol is REQUIRED. If this protocol is offered, 2255 MA-protocol-options data MUST also be carried in the SCD object. The 2256 MA-protocol-options field formats are: 2258 o in a Query: no information apart from the field header. 2260 o in a Response: 2 byte port number at which the connection will be 2261 accepted, followed by 2 pad bytes. 2263 The connection is opened in the forwards direction, from the querying 2264 node towards the responder. The querying node MAY use any source 2265 address and source port. The destination information MUST be derived 2266 from information in the Response: the address from the interface- 2267 address from the Network-Layer-Information object and the port from 2268 the SCD object as described above. 2270 Associations using Forwards-TCP can carry messages with the transfer 2271 attribute Reliable=True. If an error occurs on the TCP connection 2272 such as a reset, as can be detected for example by a socket exception 2273 condition, GIST MUST report this to NSLPs as discussed in 2274 Section 4.1.2. 2276 5.7.3. Protocol Definition: Transport Layer Security 2278 This MA-Protocol-ID denotes a basic use of transport layer channel 2279 security. Support for this protocol is mandatory; associations using 2280 it can carry messages with the transfer attribute Secure=True. For 2281 use with TCP, implementation of TLS1.0 [7] is REQUIRED and 2282 implementation of TLS1.1 [10] is RECOMMENDED. (If an unreliable 2283 transport such as DCCP or UDP is defined for GIST in the future, this 2284 MA-Protocol-ID would be implemented for it using DTLS [41].) GIST 2285 nodes supporting TLS1.0 or TLS1.1 MUST be able to negotiate the TLS 2286 ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD be able to 2287 negotiate the TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. 2289 The default mode of TLS authentication, which applies in particular 2290 to the above ciphersuites, uses a client/server certificate exchange. 2291 The Querying node acts as a TLS client, and the Responding node acts 2292 as a TLS server. Where one of the above ciphersuites is negotiated, 2293 the GIST node acting as a server MUST provide a certificate, and MUST 2294 request one from the GIST node acting as a TLS client. This allows 2295 either server-only or mutual authentication, depending on the 2296 certificates available to the client and the policy applied at the 2297 server. 2299 GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the 2300 negotiation of alternative ciphersuites is used to trigger 2301 alternative authentication procedures, such as the use of pre-shared 2302 keys [29]. The use of other authentication procedures may require 2303 additional specification work to define how they can be used as part 2304 of TLS within the GIST framework, and may or may not require the 2305 definition of additional MA-Protocol-IDs. 2307 No MA-protocol-options field is required for this use of TLS. 2309 5.7.4. Additional Protocol Options 2311 Further protocols or configurations could be defined in the future 2312 for additional performance or flexibility. Examples are: 2314 o SCTP or DCCP as alternatives to TCP, with essentially the same 2315 configuration. 2317 o SigComp [21] for message compression. 2319 o IPsec [35], ssh [36], or HIP/IPsec [37] for channel security. 2321 o Alternative modes of TCP operation, for example where it is set up 2322 from the responder to the querying node. 2324 5.8. Specific Message Routing Methods 2326 Each message routing method (see Section 3.3) requires the definition 2327 of the format of the message routing information (MRI) and Q-mode 2328 encapsulation rules. These are given in the following subsections 2329 for the various possible MRMs. 2331 5.8.1. The Path-Coupled MRM 2333 5.8.1.1. Message Routing Information 2335 For the path-coupled MRM, this is conceptually the Flow Identifier as 2336 in the NSIS Framework [26]. Minimally, this could just be the flow 2337 destination address; however, to account for policy based forwarding 2338 and other issues a more complete set of header fields SHOULD be 2339 specified if possible (see Section 4.3.4 and Section 7.2 for further 2340 discussion). 2342 MRI = network-layer-version 2343 source-address prefix-length 2344 destination-address prefix-length 2345 IP-protocol 2346 diffserv-codepoint 2347 [ flow-label ] 2348 [ ipsec-SPI / L4-ports] 2350 Additional control information defines whether the flow-label, IPsec 2351 Security Parameters Index (SPI), and port information are present, 2352 and whether the IP-protocol and diffserv-codepoint fields should be 2353 interpreted as significant. The source and destination addresses 2354 MUST be real node addresses, but prefix lengths other than 32/128 2355 (for IPv4/6) MAY be used to implement address wildcarding, allowing 2356 the MRI to refer to traffic to or from a wider address range. 2358 The MRI format allows a potentially very large number of different 2359 flag and field combinations. A GIST implementation that cannot 2360 interpret the MRI in a message MUST return an "Object Value Error" 2361 message (Appendix A.4.4.10) with subcodes 1 ("Value Not Supported") 2362 or 2 ("Invalid Flag-Field Combination") and drop the message. 2364 5.8.1.2. Downstream Q-mode Encapsulation 2366 Where the signaling message is travelling in the same ('downstream') 2367 direction as the flow defined by the MRI, the IP addressing for 2368 Q-mode encapsulated messages is as follows. Support for this 2369 encapsulation is REQUIRED. 2371 o The destination IP address MUST be the flow destination address as 2372 given in the MRI of the message payload. 2374 o By default, the source address is the flow source address, again 2375 from the MRI. This provides the best likelihood that the message 2376 will be correctly routed through any region performing per-packet 2377 policy-based forwarding or load balancing which takes the source 2378 address into account. However, there may be circumstances where 2379 the use of the signaling source address is preferable, such as: 2381 * In order to receive ICMP error messages about the signaling 2382 message (such as unreachable port or address). If these are 2383 delivered to the flow source rather than the signaling source, 2384 it will be very difficult for the querying node to detect that 2385 it is the last GIST node on the path. 2387 * In order to receive GIST Error messages where the error message 2388 sender could not interpret the NLI in the original message. 2390 * In order to attempt to run GIST through an unmodified NAT, 2391 which will only process and translate IP addresses in the IP 2392 header. 2394 Because of these considerations, use of the signaling source 2395 address is allowed as an option, with use based on local policy. 2396 A node SHOULD use the flow source address for initial Query 2397 messages, but SHOULD transition to the signaling source address 2398 for some retransmissions or as a matter of static configuration, 2399 for example if a NAT is known to be in the path out of a certain 2400 interface. The S-flag in the common header tells the message 2401 receiver which option was used. 2403 A router alert option is also included in the IP header. The option 2404 value depends on the NSLP being signaled for. In addition, it is 2405 vital that the Query mimics the actual data flow as closely as 2406 possible, since this is the basis of how the signaling message is 2407 attached to the data path. To this end, GIST SHOULD set the DiffServ 2408 codepoint and (for IPv6) flow label to match the values in the MRI. 2410 Any message sent in D-mode MUST have a size below a conservative 2411 estimate of the path MTU, for which this specification takes the 2412 value 512 bytes as a default. It is possible that fragmented 2413 datagrams including an RAO will not be correctly handled in the 2414 network, so the sender MAY set the Don't Fragment (DF) bit in the 2415 IPv4 header in order to detect that a message has encountered a link 2416 with an unusually low MTU. If the sender sets DF for any reason, it 2417 SHOULD use the signaling source address for the IP source address in 2418 order to receive the ICMP error. 2420 A GIST implementation SHOULD apply validation checks to the MRI, to 2421 reject Query messages that are being injected by nodes with no 2422 legitimate interest in the flow being signalled for. In general, if 2423 the GIST node can detect that no flow could arrive over the same 2424 interface as the Query, it MUST be rejected with an appropriate error 2425 message. Such checks apply only to messages with the Q-mode 2426 encapsulation, since only those messages are required to track the 2427 flow path. The main checks are that the IP version should match the 2428 version(s) used on that interface, and that the full range of source 2429 addresses (the source-address masked with its prefix-length) would 2430 pass ingress filtering checks. For these cases, the error message is 2431 "MRI Validation Failure" (Appendix A.4.4.12) with subcodes 1 or 2 2432 ("IP Version Mismatch" or "Ingress Filter Failure") respectively. 2434 5.8.1.3. Upstream Q-mode Encapsulation 2436 In some deployment scenarios it is desirable to set up routing state 2437 in the upstream direction, (i.e. from flow receiver towards the 2438 sender). This could be used to support firewall signaling to control 2439 traffic from an un-cooperative sender, or signaling in general where 2440 the flow sender was not NSIS-capable. This capability is 2441 incorporated into GIST by defining an encapsulation and processing 2442 rules for sending Query messages upstream. 2444 In general, it is not possible to determine the hop-by-hop route 2445 upstream because of asymmetric routing. However, in particular 2446 cases, the upstream peer can be discovered with a high degree of 2447 confidence, for example: 2449 o The upstream GIST peer is 1 IP hop away, and can be reached by 2450 tracing back through the interface on which the flow arrives. 2452 o The upstream peer is a border router of a single-homed (stub) 2453 network. 2455 This section defines an upstream Q-mode encapsulation and validation 2456 checks for when it can be used. The functionality to generate 2457 upstream Queries is OPTIONAL, but if received they MUST be processed 2458 in the normal way. No special functionality is needed for this. 2460 It is possible for routing state at a given node, for a specific MRI 2461 and NSLPID, to be created by both an upstream Query exchange 2462 (initiated by the node itself), and a downstream Query exchange 2463 (where the node is the responder). If the SIDs are different, these 2464 items of routing state MUST be considered as independent; if the SIDs 2465 match, the routing state installed by the downstream exchange MUST 2466 take precedence, provided that the downstream Query passed ingress 2467 filtering checks. The rationale for this is that the downstream 2468 Query is in general a more reliable way to install state, since it 2469 directly probes the routing infrastructure along the flow path, 2470 whereas use of the upstream Query depends on the correctness of the 2471 Querying node's understanding of the topology. 2473 The details of the encapsulation are as follows: 2475 o The destination address SHOULD be the flow source address as given 2476 in the MRI of the message payload. An implementation with more 2477 detailed knowledge of local routing MAY use an alternative 2478 destination address (e.g. the address of its default router). 2480 o The source address SHOULD be the signaling node address. 2482 o A router alert option is included as in the downstream case. 2484 o The DiffServ codepoint and (for IPv6) flow label MAY be set to 2485 match the values from the MRI, as in the downstream case. The 2486 same considerations about message size and fragmentation also 2487 apply as in the downstream case, and RAO setting and UDP port 2488 selection are also the same. 2490 o The IP layer TTL of the message MUST be set to 255. 2492 The sending GIST implementation SHOULD attempt to send the Query via 2493 the same interface and to the same link layer neighbour from which 2494 the data packets of the flow are arriving. 2496 The receiving GIST node MAY apply validation checks to the message 2497 and MRI, to reject Query messages which have reached a node at which 2498 they can no longer be trusted. In particular, a node SHOULD reject a 2499 message which has been propagated more than one IP hop, with an 2500 "Invalid IP layer TTL" error message (Appendix A.4.4.11). This can 2501 be determined by examining the received IP layer TTL, similar to the 2502 generalised IP TTL security mechanism described in [25]. 2503 Alternatively, receipt of an upstream Query at the flow source MAY be 2504 used to trigger setup of GIST state in the downstream direction. 2505 These restrictions may be relaxed in a future version. 2507 5.8.2. The Loose-End MRM 2509 The Loose-End MRM is used to discover GIST nodes with particular 2510 properties in the direction of a given address, for example to 2511 discover a NAT along the upstream data path as in [32]. 2513 5.8.2.1. Message Routing Information 2515 For the loose-end MRM, only a simplified version of the Flow 2516 Identifier is needed. 2518 MRI = network-layer-version 2519 source-address 2520 destination-address 2522 The source address is the address of the node initiating the 2523 discovery process, for example the node that will be the data 2524 receiver in the NAT discovery case. The destination address is the 2525 address of a node which is expected to be the other side of the node 2526 to be discovered. Additional control information defines the 2527 direction of the message relative to this flow as in the path-coupled 2528 case. 2530 5.8.2.2. Downstream Q-mode Encapsulation 2532 Only one encapsulation is defined for the loose-end MRM; by 2533 convention, this is referred to as the downstream encapsulation, and 2534 is defined as follows: 2536 o The IP destination address MUST be the destination address as 2537 given in the MRI of the message payload. 2539 o By default, the IP source address is the source address, again 2540 from the MRI. However, the use of the signaling source address is 2541 allowed as in the case of the path-coupled MRM. 2543 A router alert option is included in the IP header. The option value 2544 depends on the NSLP being signaled for. There are no special 2545 requirements on the setting of the DiffServ codepoint, IP layer TTL, 2546 or (for IPv6) the flow label. Nor are any special validation checks 2547 applied. Restrictions on message size and setting of the Don't 2548 Fragment (DF) bit apply as in the case of the path-coupled MRM. 2550 6. Formal Protocol Specification 2552 This section provides a more formal specification of the operation of 2553 GIST processing, in terms of rules for transitions between states of 2554 a set of communicating state machines within a node. The following 2555 description captures only the basic protocol specification; 2556 additional mechanisms can be used by an implementation to accelerate 2557 route change processing, and these are captured in Section 7.1. 2559 Conceptually, GIST processing at a node may be seen in terms of four 2560 types of cooperating state machine: 2562 1. There is a top-level state machine which represents the node 2563 itself (Node-SM). It is responsible for the processing of events 2564 which cannot be directed towards a more specific state machine, 2565 for example, inbound messages for which no routing state 2566 currently exists. This machine exists permanently, and is 2567 responsible for creating per-MRI state machines to manage the 2568 GIST handshake and routing state maintenance procedures. 2570 2. For each flow and signaling direction where the node is 2571 responsible for the creation of routing state, there is an 2572 instance of a Query-Node state machine (Querying-SM). This 2573 machine sends Query and Confirm messages and waits for Responses, 2574 according to the requirements from local API commands or timer 2575 processing, such as message repetition or routing state refresh. 2577 3. For each flow and signaling direction where the node has accepted 2578 the creation of routing state by a peer, there is an instance of 2579 a Responding-Node state machine (Responding-SM). This machine is 2580 responsible for managing the status of the routing state for that 2581 flow. Depending on policy, it MAY be responsible for 2582 [re]transmission of Response messages, or this MAY be handled by 2583 the Node-SM, and a Responding-SM is not even created for a flow 2584 until a properly formatted Confirm has been accepted. 2586 4. Messaging associations have their own lifecycle, represented by 2587 MA-SM, from when they are first created (in an incomplete state, 2588 listening for an inbound connection or waiting for outbound 2589 connections to complete), to when they are active and available 2590 for use. 2592 Apart from the fact that the various machines can be created and 2593 destroyed by each other, there is almost no interaction between them. 2594 The machines for different flows do not interact; the Querying-SM and 2595 Responding-SM for a single flow and signaling direction do not 2596 interact. That is, the Responding-SM which accepts the creation of 2597 routing state for a flow on one interface has no direct interaction 2598 with the Querying-SM which sets up routing state on the next 2599 interface along the path. This interaction is mediated instead 2600 through the NSLP. 2602 The state machine descriptions use the terminology rx_MMMM, tg_TTTT 2603 and er_EEEE for incoming messages, API/lower layer triggers and error 2604 conditions respectively. The possible events of these types are 2605 given in the table below. In addition, timeout events denoted 2606 to_TTTT may also occur; the various timers are listed independently 2607 for each type of state machine in the following subsections. 2609 +---------------------+---------------------------------------------+ 2610 | Name | Meaning | 2611 +---------------------+---------------------------------------------+ 2612 | rx_Query | A Query has been received. | 2613 | | | 2614 | rx_Response | A Response has been received. | 2615 | | | 2616 | rx_Confirm | A Confirm has been received. | 2617 | | | 2618 | rx_Data | A Data message has been received. | 2619 | | | 2620 | rx_Message | rx_Query||rx_Response||rx_Confirm||rx_Data. | 2621 | | | 2622 | rx_MA-Hello | A MA-Hello message has been received. | 2623 | | | 2624 | tg_NSLPData | A signaling application has requested data | 2625 | | transfer (via API SendMessage). | 2626 | | | 2627 | tg_Connected | The protocol stack for a messaging | 2628 | | association has completed connecting. | 2629 | | | 2630 | tg_RawData | GIST wishes to transfer data over a | 2631 | | particular messaging association. | 2632 | | | 2633 | er_NoRSM | A "No Routing State" error was received. | 2634 | | | 2635 | er_MAConnect | A messaging association protocol failed to | 2636 | | complete a connection. | 2637 | | | 2638 | er_MAFailure | A messaging association failed. | 2639 +---------------------+---------------------------------------------+ 2641 Incoming Events 2643 6.1. Node Processing 2645 The Node level state machine is responsible for processing events for 2646 which no more appropriate messaging association state or routing 2647 state exists. Its structure is trivial: there is a single state 2648 ('Idle'); all events cause a transition back to Idle. Some events 2649 cause the creation of other state machines. The only events that are 2650 processed by this state machine are incoming GIST messages (Query/ 2651 Response/Confirm/Data) and API requests to send data; no other events 2652 are possible. In addition to this event processing, the Node level 2653 machine is responsible for managing listening endpoints for messaging 2654 associations. Although these relate to Responding node operation, 2655 they cannot be handled by the Responder state machine since they are 2656 not created per flow. The processing rules for each event are as 2657 follows: 2659 Rule 1 (rx_Query): 2661 use the GIST service interface to determine the signaling application 2662 policy relating to this peer 2663 if (the signaling application indicates that routing state should 2664 be created) then 2665 if (routing state can be created without a 3-way handshake) then 2666 create Responding-SM and transfer control to it 2667 else 2668 send Response 2669 else 2670 propagate the Query with any updated NSLP payload provided 2672 Rule 2 (rx_Response): 2674 // should already have a Querying-SM to handle this 2675 discard message 2676 send "No Routing State" error message 2678 Rule 3 (rx_Confirm): 2680 if (routing state can be created before receiving a Confirm) then 2681 // we should already have Responding-SM for it, 2682 // which would handle this message 2683 discard message 2684 send "No Routing State" error message 2685 else 2686 create Responding-SM and pass message to it 2688 Rule 4 (rx_Data): 2690 if (node policy will only process Data messages with matching 2691 routing state) then 2692 send "No Routing State" error message 2693 else 2694 pass directly to NSLP 2696 Rule 5 (tg_NSLPData): 2698 if Q-mode encapsulation is not possible for this MRI 2699 reject message with an error 2700 else 2701 if (local policy & transfer attributes say routing 2702 state is not needed) then 2703 send message statelessly 2704 else 2705 create Querying-SM and pass message to it 2707 6.2. Query Node Processing 2709 The Querying-Node state machine (Querying-SM) has three states: 2711 o Awaiting Response 2713 o Established 2715 o Awaiting Refresh 2717 The Querying-SM is created by the Node-SM machine as a result of a 2718 request to send a message for a flow in a signaling direction where 2719 the appropriate state does not exist. The Query is generated 2720 immediately and the No_Response timer is started. The NSLP data MAY 2721 be carried in the Query if local policy and the transfer attributes 2722 allow it, otherwise it MUST be queued locally pending MA 2723 establishment. Then the machine transitions to the Awaiting Response 2724 state, in which timeout-based retransmissions are handled. Data 2725 messages (rx_Data events) should not occur in this state; if they do, 2726 this may indicate a lost Response and a node MAY also retransmit a 2727 Query for this reason. 2729 Once a Response has been successfully received and routing state 2730 created, the machine transitions to Established, during which NSLP 2731 data can be sent and received normally. Further Responses received 2732 in this state (which may be the result of a lost Confirm) MUST be 2733 treated the same way. The Awaiting Refresh state can be considered 2734 as a substate of Established, where a new Query has been generated to 2735 refresh the routing state (as in Awaiting Response) but NSLP data can 2736 be handled normally. 2738 The timers relevant to this state machine are as follows: 2740 Refresh_QNode: Indicates when the routing state stored by this state 2741 machine must be refreshed. It is reset whenever a Response is 2742 received indicating that the routing state is still valid. 2743 Implementations MUST set the period of this timer based on the 2744 value in the RS-validity-time field of a Response to ensure that a 2745 Query is generated before the peer's routing state expires. 2747 No_Response: Indicates that a Response has not been received in 2748 answer to a Query. This is started whenever a Query is sent and 2749 stopped when a Response is received. 2751 Inactive_QNode: Indicates that no traffic is currently being handled 2752 by this state machine. This is reset whenever the state machine 2753 handles NSLP data, in either direction. When it expires, the 2754 state machine MAY be deleted. The period of the timer can be set 2755 at any time via the API (SetStateLifetime), and if the period is 2756 reset in this way the timer itself MUST be restarted. 2758 The main events (including all those that cause state transitions) 2759 are shown in the figure below, tagged with the number of the 2760 processing rule that is used to handle the event. These rules are 2761 listed after the diagram. All events not shown or described in the 2762 text above are assumed to be impossible in a correct implementation. 2764 [Initialisation] +-----+ 2765 -------------------------|Birth| 2766 | +-----+ 2767 | rx_Response[4] 2768 | || tg_NSLPData[5] 2769 | tg_NSLPData[1] er_NoRSM[3] || rx_Data[7] 2770 | -------- ------------------ ------- 2771 | | V | V | V 2772 | | V | V | V 2773 | +----------+ | +-----------+ 2774 ---->>| Awaiting | ---------------- |Established| 2775 ------| Response |---------------------------->> | | 2776 | +----------+ rx_Response[4] +-----------+ 2777 | ^ | ^ | 2778 | ^ | ^ | 2779 | -------- | | 2780 | to_No_Response[2] | | 2781 | [!nResp_reached] tg_NSLPData[5] | | 2782 | || rx_Data[7] | | 2783 | -------- | | 2784 | | V | | 2785 | to_No_Response[2] | V | | 2786 | [nResp_reached] +-----------+ rx_Response[4] | | 2787 ---------- -----------| Awaiting |----------------- | 2788 | | | Refresh |<<------------------- 2789 | | +-----------+ to_Refresh_QNode[8] 2790 | | ^ | 2791 | | ^ | 2792 | | -------- 2793 | | to_No_Response[2] 2794 | | [!nResp_reached] 2795 V V 2796 V V 2797 +-----+ 2798 |Death|<<--------------- 2799 +-----+ to_Inactive_QNode[6] 2800 (from all states) 2802 Figure 6: Query Node State Machine 2804 The processing rules are as follows: 2806 Rule 1: Store the message for later transmission 2808 Rule 2: 2810 if number of Queries sent has reached the threshold 2811 // nQuery_isMax is true 2812 indicate No Response error to NSLP 2813 destroy self 2814 else 2815 send Query 2816 start No_Response timer with new value 2818 Rule 3: 2820 // Assume the Confirm was lost in transit so resend it 2821 // for the last Response we received 2822 send Confirm 2823 restart Refresh_QNode and Inactive_QNode timers 2825 Rule 4: 2827 if a new MA-SM is needed create one 2828 if the R flag was set send a Confirm 2829 pass any NSLP data to the NSLP 2830 send any stored Data messages 2831 stop No_Response timer 2832 start Refresh_QNode and Inactive_QNode timers 2834 Rule 5: 2836 send Data message 2837 restart Inactive_QNode timer 2839 Rule 6: Terminate 2841 Rule 7: 2843 pass any data to the NSLP 2844 (re)start Inactive_QNode timer 2846 Rule 8: 2848 send Query 2849 start No_Response timer 2850 stop Refresh_QNode timer 2852 6.3. Responder Node Processing 2854 The Responding-Node state machine (Responding-SM) has three states: 2856 o Awaiting Confirm 2857 o Established 2859 o Awaiting Refresh 2861 The policy governing the creation of the Responding-SM has three 2862 cases: 2864 1. It is created on receiving a Query, no Confirm is requested. 2866 2. It is created on receiving a Query, but a Confirm is requested. 2867 A timer is used to retransmit Response messages and the 2868 Responding-SM is destroyed if no valid Confirm is received. 2870 3. It cannot be created until a valid Confirm is received; the 2871 initial Query will have been handled by the Node level machine. 2873 In case 2 the Responding-SM is created in the Awaiting Confirm state, 2874 and remains there until a Confirm is received, at which point it 2875 transitions to Established. In cases 1 and 3 the Responding-SM is 2876 created directly in the Established state. Note that if the machine 2877 is created on receiving a Query, some of the message processing will 2878 already have been performed in the Node state machine. In the 2879 Established state the NSLP can send and receive data normally, and 2880 any additional rx_Confirm events MUST be silently ignored. The 2881 Awaiting Refresh state can be considered a substate of Established, 2882 where a Query has been received to begin the routing state refresh. 2884 In the Awaiting Refresh state the Responding-SM behaves as in the 2885 Awaiting Confirm state, except that the NSLP can still send and 2886 receive data. In particular, in both states there is timer-based 2887 retransmission of Response messages until a Confirm is received; 2888 additional rx_Query events in these states MUST also generate a 2889 response and restart the no_Confirm timer. 2891 The timers relevant to the operation of this state machine are as 2892 follows: 2894 Expire_RNode: Indicates when the routing state stored by this state 2895 machine needs to be expired. It is reset whenever a Query or 2896 Confirm (depending on local policy) is received indicating that 2897 the routing state is still valid. Note that state cannot be 2898 refreshed from the R-Node. 2900 No_Confirm: Indicates that a Confirm has not been received in answer 2901 to a Response. This is started/reset whenever a Response is sent 2902 and stopped when a Confirm is received. 2904 The detailed state transitions and processing rules are described 2905 below as in the Query node case. 2907 rx_Query[1] rx_Query[5] 2908 [confirmRequired] +-----+ [!confirmRequired] 2909 -------------------------|Birth|---------------------------- 2910 | +-----+ | 2911 | | rx_Confirm[2] | 2912 | ---------------------------- | 2913 | | | 2914 | rx_Query[5] | | 2915 | tg_NSLPData[7] [!confirmRequired] | | 2916 | || rx_Query[1] || rx_Data[4] | | 2917 | || rx_Data[6] || tg_NSLPData[3] | | 2918 | -------- -------------- | | 2919 | | V | V V V 2920 | | V | V V V 2921 | +----------+ | +-----------+ 2922 ---->>| Awaiting | rx_Confirm[8] -----------|Established| 2923 ------| Confirm |------------------------------>> | | 2924 | +----------+ +-----------+ 2925 | ^ | ^ | 2926 | ^ | tg_NSLPData[3] ^ | 2927 | -------- || rx_Query[1] | | 2928 | to_No_Confirm[9] || rx_Data[4] | | 2929 | [!nConf_reached] -------- | | 2930 | | V | | 2931 | to_No_Confirm[9] | V | | 2932 | [nConf_reached] +-----------+ rx_Confirm[8] | | 2933 ---------- ------------| Awaiting |----------------- | 2934 | | | Refresh |<<------------------- 2935 | | +-----------+ rx_Query[1] 2936 | | ^ | [confirmRequired] 2937 | | ^ | 2938 | | -------- 2939 V V to_No_Confirm[9] 2940 V V [!nConf_reached] 2941 +-----+ 2942 |Death|<<--------------------- 2943 +-----+ to_Expire_RNode[10] 2944 (from all states) 2946 Figure 7: Responder Node State Machine 2948 The processing rules are as follows: 2950 Rule 1: 2952 // a Confirm is required 2953 send Response 2954 (re)start No_Confirm timer 2956 Rule 2: 2958 pass any piggybacked data to the NSLP 2959 start Expire_RNode timer 2961 Rule 3: send the Data message 2963 Rule 4: pass data to NSLP 2965 Rule 5: 2967 // no Confirm is required 2968 send Response 2969 start Expire_RNode timer 2971 Rule 6: send "No Routing State" error message 2973 Rule 7: store Data message 2975 Rule 8: 2977 pass any piggybacked data to the NSLP 2978 send any stored Data messages 2979 stop No_Confirm timer 2980 start Expire_RNode timer 2982 Rule 9: 2984 if number of Responses sent has reached threshold 2985 // nResp_isMax is true 2986 destroy self 2987 else 2988 send Response 2989 start No_Response timer 2991 Rule 10: destroy self 2993 6.4. Messaging Association Processing 2995 Messaging associations (MAs) are modelled for use within GIST with a 2996 simple three-state process. The Awaiting Connection state indicates 2997 that the MA is waiting for the connection process(es) for every 2998 protocol in the messaging association to complete; this might involve 2999 creating listening endpoints or attempting active connects. Timers 3000 may also be necessary to detect connection failure (e.g. no incoming 3001 connection within a certain period), but these are not modelled 3002 explicitly. The Connected state indicates that the MA is open and 3003 ready to use. In addition there is an Idle state in which the local 3004 node no longer requires the messaging association but the remote node 3005 still wants it to be kept open. 3007 Clearly, many internal details of the messaging association protocols 3008 are hidden in this model, especially where the messaging association 3009 uses multiple protocol layers. Note also that although the existence 3010 of messaging associations is not directly visible to signaling 3011 applications, there is some interaction between the two because 3012 security-related information becomes available during the open 3013 process, and this may be indicated to signaling applications if they 3014 have requested it. 3016 The timers relevant to the operation of this state machine are as 3017 follows: 3019 SendHello: Indicates that an MA-Hello message should be sent to the 3020 remote node. The period of this timer is determined by the MA- 3021 Hold-Time sent by the remote node during the Query/Response/ 3022 Confirm exchange. 3024 NoHello: Indicates that no MA-Hello has been received from the 3025 remote node for a period of time. The period of this timer is 3026 sent to the remote node as the MA-Hold-Time during the Query/ 3027 Response exchange. 3029 NoActivity: Indicates that the link has been inactive for a period 3030 of time. The period of this timer is implementation-specific but 3031 is likely to be related to the period of the NoHello timer. 3033 The detailed state transitions and processing rules are described 3034 below as in the Query node case. 3036 [Initialisation] +-----+ 3037 ----------------------------|Birth| 3038 | +-----+ 3039 | tg_RawData[1] 3040 | || rx_Message[2] 3041 | || rx_MA-Hello[3] 3042 | tg_RawData[5] || to_SendHello[4] 3043 | -------- -------- 3044 | | V | V 3045 | | V | V 3046 | +----------+ +-----------+ 3047 ---->>| Awaiting | tg_Connected[6] | Connected | 3048 ------|Connection|----------------------->>| | 3049 | +----------+ +-----------+ 3050 | ^ | 3051 | tg_RawData[1] ^ | 3052 | || rx_Message[2] | |to_NoActivity[7] 3053 | | V 3054 | | V 3055 | er_MAConnect[8] +-----+ to_NoHello[8] +-----------+ 3056 ---------------->>|Death|<<----------------| Idle | 3057 +-----+ | | 3058 ^ +-----------+ 3059 ^ ^ | 3060 | ^ | 3061 --------------- -------- 3062 er_MAFailure[8] rx_MA-Hello[9] 3063 (from all states) 3065 Figure 8: Messaging Association State Machine 3067 The processing rules are as follows: 3069 Rule 1: 3071 pass message to transport layer 3072 (re)start NoActivity timer 3073 (re)start SendHello 3075 Rule 2: 3077 pass message to Node-SM 3078 (re)start NoActivity timer 3079 Rule 3: 3081 if reply requested 3082 send MA-Hello 3083 restart SendHello timer 3085 Rule 4: 3087 send MA-Hello message 3088 restart SendHello timer 3090 Rule 5: queue message for later transmission 3092 Rule 6: 3094 pass outstanding queued messages to transport layer 3095 stop any timers controlling connection establishment 3096 start NoActivity timer 3097 start SendHello timer 3099 Rule 7: 3101 stop NoActivity timer 3102 stop SendHello timer 3103 start NoHello timer 3105 Rule 8: destroy self 3107 Rule 9: 3109 if reply requested 3110 send MA-Hello 3111 restart NoHello timer 3113 7. Advanced Protocol Features 3115 7.1. Route Changes and Local Repair 3117 7.1.1. Introduction 3119 When re-routing takes place in the network, GIST and signaling 3120 application state need to be updated for all flows whose paths have 3121 changed. The updates to signaling application state depend mainly on 3122 the signaling application: for example, if the path characteristics 3123 have actually changed, simply moving state from the old to the new 3124 path is not sufficient. Therefore, GIST cannot carry out the 3125 complete path update processing. Its responsibilities are to detect 3126 the route change, update its local routing state consistently, and 3127 inform interested signaling applications at affected nodes. 3129 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 3130 x +--+ +--+ +--+ x Initial 3131 x .|C1|_.....|D1|_.....|E1| x Configuration 3132 x . +--+. .+--+. .+--+\. x 3133 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 3134 +-+ +-+ . .. .. . +-+ 3135 ...|A|_......|B|/ .. .. .|F|_.... 3136 +-+ +-+ . . . . . . +-+ 3137 . . . . . . 3138 . +--+ +--+ +--+ . 3139 .|C2|_.....|D2|_.....|E2|/ 3140 +--+ +--+ +--+ 3142 +--+ +--+ +--+ Configuration 3143 .|C1|......|D1|......|E1| after failure 3144 . +--+ .+--+ +--+ of E1-F link 3145 . \. . \. ./ 3146 +-+ +-+ . .. .. +-+ 3147 ...|A|_......|B|. .. .. .|F|_.... 3148 +-+ +-+\ . . . . . +-+ 3149 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 3150 x . +--+ +--+ +--+ . x 3151 x .|C2|_.....|D2|_.....|E2|/ x 3152 x +--+ +--+ +--+ x 3153 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 3155 ........... = physical link topology 3156 >>xxxxxxx>> = flow direction 3157 _.......... = outgoing link for flow xxxxxx given 3158 by local forwarding table 3160 Figure 9: A Re-Routing Event 3162 Route change management is complicated by the distributed nature of 3163 the problem. Consider the re-routing event shown in Figure 9. An 3164 external observer can tell that the main responsibility for 3165 controlling the updates will probably lie with nodes B and F; 3166 however, E1 is best placed to detect the event quickly at the GIST 3167 level, and C1 and D1 could also attempt to initiate the repair. 3169 On the assumption that signaling applications are soft-state based 3170 and operate end to end, and because GIST also periodically updates 3171 its picture of routing state, route changes will eventually be 3172 repaired automatically. The specification as already given includes 3173 this functionality. However, especially if upper layer refresh times 3174 are extended to reduce signaling load, the duration of inconsistent 3175 state may be very long indeed. Therefore, GIST includes logic to 3176 exchange prompt notifications with signaling applications, to allow 3177 local repair if possible. The additional mechanisms to achieve this 3178 are described in the following subsections. To a large extent, these 3179 additions can be seen as implementation issues; the protocol messages 3180 and their significance are not changed, but there are extra 3181 interactions through the API between GIST and signaling applications, 3182 and additional triggers for transitions between the various GIST 3183 states. 3185 7.1.2. Route Change Detection Mechanisms 3187 There are two aspects to detecting a route change at a single node: 3189 o Detecting that the outgoing path, in the direction of the Query, 3190 has or may have changed. 3192 o Detecting that the incoming path, in the direction of the 3193 Response, has (or may have) changed, in which case the node may no 3194 longer be on the path at all. 3196 At a single node, these processes are largely independent, although 3197 clearly a change in one direction at a node corresponds to a change 3198 the opposite direction at its peer. Note that there are two possible 3199 forms for a route change: the interface through which a flow leaves 3200 or enters a node may change, and the adjacent peer may change. In 3201 general, a route change can include one or the other or both (or 3202 indeed neither, although such changes are very hard to detect). 3204 The route change detection mechanisms available to a node depend on 3205 the MRM in use and the role the node played in setting up the routing 3206 state in the first place (i.e. as Querying or Responding node). The 3207 following discussion is specific to the case of the path-coupled MRM 3208 using downstream Queries only; other scenarios may require other 3209 methods. However, the repair logic described in the subsequent 3210 subsections is intended to be universal. 3212 There are five mechanisms for a node to detect that a route change 3213 has occurred, which are listed below. They apply differently 3214 depending on whether the change is in the Query or Response 3215 direction, and these differences are summarised in the following 3216 table. 3218 Local Trigger: In local trigger mode, GIST finds out from the local 3219 forwarding table that the next hop has changed. This only works 3220 if the routing change is local, not if it happens a few routing 3221 hops away, including the case that it happens at a GIST-unaware 3222 node. 3224 Extended Trigger: Here, GIST checks a link-state topology database 3225 to discover that the path has changed. This makes certain 3226 assumptions on consistency of route computation and only works 3227 within a single area for OSPF [13] and similar link-state 3228 protocols. Where available, this offers the most accurate and 3229 rapid indication of route changes, but requires more access to the 3230 routing internals than a typical operating system may provide. 3232 GIST C-mode Monitoring: GIST may find that C-mode packets are 3233 arriving (from either peer) with a different IP layer TTL or on a 3234 different interface. This provides no direct information about 3235 the new flow path, but indicates that routing has changed and that 3236 rediscovery may be required. 3238 Data Plane Monitoring: The signaling application on a node may 3239 detect a change in behaviour of the flow, such as IP layer TTL 3240 change, arrival on a different interface, or loss of the flow 3241 altogether. The signaling application on the node is allowed to 3242 notify this information locally to GIST (Appendix B.6). 3244 GIST Probing: According to the specification, each GIST node MUST 3245 periodically repeat the discovery (Query/Response) operation. 3246 Values for the probe frequency are discussed in Section 4.4.3. 3247 The querying node will discover the route change by a modification 3248 in the Network-Layer-Information in the Response. The period can 3249 be negotiated independently for each GIST hop, so nodes that have 3250 access to the other techniques listed above MAY use long periods 3251 for the probing operation. 3253 +-------------+--------------------------+--------------------------+ 3254 | Method | Query direction | Response direction | 3255 +-------------+--------------------------+--------------------------+ 3256 | Local | Discovers new interface | Not applicable | 3257 | Trigger | (and peer if local) | | 3258 | | | | 3259 | Extended | Discovers new interface | May determine that route | 3260 | Trigger | and may determine new | from peer will have | 3261 | | peer | changed | 3262 | | | | 3263 | C-mode | Provides hint that | Provides hint that | 3264 | Monitoring | change has occurred | change has occurred | 3265 | | | | 3266 | Data Plane | Not applicable | NSLP informs GIST that a | 3267 | Monitoring | | change may have occurred | 3268 | | | | 3269 | Probing | Discovers changed NLI in | Discovers changed NLI in | 3270 | | Response | Query | 3271 +-------------+--------------------------+--------------------------+ 3273 7.1.3. GIST Behaviour Supporting Re-Routing 3275 The GIST behaviour necessary to support re-routing can be modelled 3276 using a 3-level classification of the validity of each item of 3277 routing state. (This classification applies separately to the 3278 Querying and Responding node for each pair of GIST peers.) The 3279 levels are: 3281 Bad: The routing state is either missing altogether, or not safe to 3282 use to send data. 3284 Tentative: The routing state may have changed, but it is still 3285 usable for sending NSLP data pending verification. 3287 Good: The routing state has been established and no events affecting 3288 it have since been detected. 3290 These classifications are not identical to the states described in 3291 Section 6, but there are dependencies between them. Specifically, 3292 routing state is considered Bad until the machine first enters the 3293 Established state, at which point it becomes Good. Thereafter, the 3294 status may be invalidated for any of the reasons discussed above; it 3295 is an implementation issue to decide which techniques to implement in 3296 any given node, and how to reclassify routing state (as Bad or 3297 Tentative) for each. The status returns to Good, either when the 3298 state machine re-enters the Established state, or if GIST can 3299 determine from direct examination of the routing or forwarding tables 3300 that the peer has not changed. When the status returns to Good, GIST 3301 MUST if necessary update its routing state table so that the 3302 relationships between MRI/SID/NSLPID tuples and messaging 3303 associations are up to date. 3305 When classification of the routing state for the downstream direction 3306 changes to Bad/Tentative because of local routing indications, GIST 3307 MAY automatically change the classification in the upstream direction 3308 to Tentative unless local routing indicates that this is not 3309 necessary. This SHOULD NOT be done in the case where the initial 3310 change was indicated by the signaling application. This mechanism 3311 accounts for the fact that a routing change may affect several nodes, 3312 and so can be an indication that upstream routing may also have 3313 changed. In any case, whenever GIST updates the routing status, it 3314 informs the signaling application with the NetworkNotification API 3315 (Appendix B.4), unless the change was caused via the API in the first 3316 place. 3318 The GIST behaviour for state repair is different for the Querying and 3319 Responding node. At the Responding node, there is no additional 3320 behaviour, since the Responding node cannot initiate protocol 3321 transitions autonomously, it can only react to the Querying node. 3322 The Querying node has three options, depending on how the transition 3323 from 'Good' was initially caused: 3325 1. To inspect the routing/forwarding table and verifying that the 3326 next peer has not changed. This technique MUST NOT be used if 3327 the transition was caused by a signaling application, but SHOULD 3328 be used otherwise if available. 3330 2. To move to the 'Awaiting Refresh' state. This technique MUST NOT 3331 be used if the current status is 'Bad', since data is being 3332 incorrectly delivered. 3334 3. To move to the 'Awaiting Response' state. This technique may be 3335 used at any time, but has the effect of freezing NSLP 3336 communication while GIST state is being repaired. 3338 The second and third techniques trigger the execution of a GIST 3339 handshake to carry out the repair. It may be desirable to delay the 3340 start of the handshake process, either to wait for the network to 3341 stabilise, to avoid flooding the network with Query traffic for a 3342 large number of affected flows, or to wait for confirmation that the 3343 node is still on the path from the upstream peer. One approach is to 3344 delay the handshake until there is NSLP data to be transmitted. 3345 Implementation of such delays is a matter of local policy; however, 3346 GIST MUST begin the handshake immediately if the status change was 3347 caused by an InvalidateRoutingState API call marked as 'Urgent', and 3348 SHOULD begin it if the upstream routing state is still known to be 3349 Good. 3351 7.1.4. Signaling Application Operation 3353 Signaling applications can use these functions as provided by GIST to 3354 carry out rapid local repair following re-routing events. The 3355 signaling application instances carry out the multi-hop aspects of 3356 the procedure, including crossover node detection, and tear-down/ 3357 reinstallation of signaling application state; they also trigger GIST 3358 to carry out the local routing state maintenance operations over each 3359 individual hop. The local repair procedures depend heavily on the 3360 fact that stateful NSLP nodes are a single GIST hop apart; this is 3361 enforced by the details of the GIST peer discovery process. 3363 The following outline description of a possible set of NSLP actions 3364 takes the scenario of Figure 9 as an example. 3366 1. The signaling application at node E1 is notified by GIST of route 3367 changes affecting the downstream and upstream directions. The 3368 downstream status was updated to Bad because of a trigger from 3369 the local forwarding tables, and the upstream status changed 3370 automatically to Tentative as a consequence. The signaling 3371 application at E1 MAY begin local repair immediately, or MAY 3372 propagate a notification upstream to D1 that re-routing has 3373 occurred. 3375 2. The signaling application at node D1 is notified of the route 3376 change, either by signaling application notifications or from the 3377 GIST level (e.g. by a trigger from a link-state topology 3378 database). If the information propagates faster within the 3379 routing protocol, GIST will change the upstream/downstream 3380 routing state to Tentative/Bad automatically, and this will cause 3381 the signaling application to propagate the notification further 3382 upstream. 3384 3. This process continues until the notification reaches node A. 3385 Here, there is no downstream routing change, so GIST only learns 3386 of the update via the signaling application trigger. Since the 3387 upstream status is still Good, it therefore begins the repair 3388 handshake immediately. 3390 4. The handshake initiated by node A causes its downstream routing 3391 state to be confirmed as Good and unchanged there; it also 3392 confirms the (Tentative) upstream routing state at B as Good. 3393 This is enough to identify B as the crossover router, and the 3394 signaling application and GIST can begin the local repair 3395 process. 3397 An alternative way to reach step (4) is that node B is able to 3398 determine autonomously that there is no likelihood of an upstream 3399 route change. For example, it could be an area border router and the 3400 route change is only intra-area. In this case, the signaling 3401 application and GIST will see that the upstream state is Good and can 3402 begin the local repair directly. 3404 After a route change, a signaling application may wish to remove 3405 state at another node which is no longer on the path. However, since 3406 it is no longer on the path, in principle GIST can no longer send 3407 messages to it. In general, provided this state is soft, it will 3408 time out anyway; however, the timeouts involved may have been set to 3409 be very long to reduce signaling load. The requirement to remove 3410 state in a specific peer node is identified in [33]. 3412 This requirement can be met provided that GIST is able to use the old 3413 path to the signaling application peer for some period while the 3414 signaling application still needs it. Since NSLP peers are a single 3415 GIST hop apart, the necessary information is just the old entry in 3416 the node's routing state table for that flow. Rather than requiring 3417 GIST to maintain multiple generations of this information, it can 3418 just be provided to the signaling application in the same node in an 3419 opaque form for each message that is received. The signaling 3420 application can store it if necessary and provide it back to the GIST 3421 layer in case it needs to be used. Because this is a reference to 3422 information about the source of a prior signaling message, it is 3423 denoted 'SII-Handle' (for Source Identification Information) in the 3424 abstract API of Appendix B. Note that GIST if possible SHOULD use 3425 the same SII-Handle for multiple sessions to the same peer, since 3426 this then allows signaling applications to aggregate some signaling, 3427 such as summary refreshes or bulk teardowns. 3429 Messages sent this way MUST bypass the GIST routing state tables at 3430 the sender, and this MUST be indicated by setting the E flag in the 3431 common header (Appendix A.1). Messages other than Data messages MUST 3432 NOT be sent in this way. At the receiver, GIST MUST NOT validate the 3433 MRI/SID/NSLPID against local routing state and instead indicates the 3434 mode of reception to signaling applications through the API 3435 (Appendix B.2). Signaling applications should validate the source 3436 and effect of the message themselves, and if appropriate should in 3437 particular indicate to GIST (see Appendix B.5) that routing state is 3438 no longer required for this flow. This is necessary to prevent GIST 3439 in nodes on the old path initiating routing state refresh and thus 3440 causing state conflicts at the crossover router. 3442 7.2. NAT Traversal 3444 7.2.1. Overview 3446 GIST messages must carry packet addressing and higher layer 3447 information as payload data in order to define the flow signalled 3448 for. (This applies to all GIST messages, regardless of how they are 3449 encapsulated or which direction they are travelling in.) At an 3450 addressing boundary the data flow packets will have their headers 3451 translated; if the signaling payloads are not translated 3452 consistently, the signaling messages will refer to incorrect (and 3453 probably meaningless) flows after passing through the boundary. In 3454 addition, GIST handshake messages carry additional addressing 3455 information about the GIST nodes themselves, and this must also be 3456 processed appropriately when traversing a NAT. 3458 The simplest solution to this problem is to require that a NAT is 3459 GIST-aware, and to allow it to modify messages based on the contents 3460 of the MRI. This makes the assumption that NATs only rewrite the 3461 header fields included in this payload, and not other higher layer 3462 identifiers. Provided this is done consistently with the data flow 3463 header translation, signaling messages will be valid each side of the 3464 boundary, without requiring the NAT to be signaling application 3465 aware. Note, however, that if the NAT does not understand the MRI, 3466 and the N-flag in the MRI is clear (see Appendix A.3.1), it should 3467 reject the message with an "Object Type Error" message 3468 (Appendix A.4.4.9) with subcode 4 ("Untranslated Object"). 3470 This specification defines an additional object that a NAT inserts 3471 into all Q-mode encapsulated messages and which is echoed back in any 3472 replies, i.e. Response or Error messages. NATs apply GIST-specific 3473 processing only to Q-mode encapsulated messages or replies carrying 3474 the NAT traversal object. All other GIST messages, either in C-mode, 3475 or D-mode messages with no NAT-Traversal object, should be treated as 3476 normal data traffic by the NAT, i.e. with IP and transport layer 3477 header translation but no GIST-specific processing. 3479 The new object, the NAT-Traversal object (Appendix A.3.8), carries 3480 the translation between the MRIs which are appropriate for the 3481 internal and external sides of the NAT. It also carries a list of 3482 which other objects in the message have been translated. This should 3483 always include the NLI, and the Stack-Configuration-Data if present; 3484 if GIST is extended with further objects that carry addressing data, 3485 this list allows a message receiver to know if the new objects were 3486 supported by the NAT. Finally, the NAT-Traversal object MAY be used 3487 to carry data to be used in back-translating D-mode responses; this 3488 could be the original NLI or SCD, or opaque equivalents in the case 3489 of topology hiding. 3491 A consequence of this approach is that the routing state tables at 3492 the signaling application peers each side of the NAT are no longer 3493 directly compatible. In particular, the values for Message-Routing- 3494 Information are different, which is why the unmodified MRI is 3495 propagated in the NAT-Traversal object to allow subsequent C-mode 3496 messages to be interpreted correctly. 3498 7.2.2. Message Processing Rules 3500 This specification normatively defines the behaviour of a GIST node 3501 receiving a message containing a NAT-Traversal object. However, it 3502 does not define normative behaviour for a NAT translating GIST 3503 messages, since much of this will depend on NAT implementation and 3504 policy about allocating bindings. In addition, it is not necessary 3505 for a GIST implementation itself. Therefore, those aspects of the 3506 following description are informative; full details of NAT behaviour 3507 for handling GIST messages can be found in [40]. 3509 A possible set of operations for a NAT to process a Q-mode 3510 encapsulated message is as follows. Note that for a Data message, 3511 only a subset of the operations is applicable. 3513 1. Verify that bindings for any data flow are actually in place. 3515 2. Create a new Message-Routing-Information object with fields 3516 modified according to the data flow bindings. 3518 3. Create bindings for subsequent C-mode signaling based on the 3519 information in the Network-Layer-Information and Stack- 3520 Configuration-Data objects. 3522 4. Create new Network-Layer-Information and if necessary Stack- 3523 Configuration-Data objects with fields to force D-mode response 3524 messages through the NAT, and to allow C-mode exchanges using the 3525 C-mode signaling bindings. 3527 5. Add a NAT-Traversal object, listing the objects which have been 3528 modified and including the unmodified MRI and any other data 3529 needed to interpret the response. If a NAT-Traversal object is 3530 already present, in the case of a sequence of NATs, the list of 3531 modified objects may be updated and further opaque data added, 3532 but the MRI contained in it is left unchanged. 3534 6. Encapsulate the message according to the normal rules of this 3535 specification for the Q-mode encapsulation. If the S-flag was 3536 set in the original message, the same IP source address selection 3537 policy should be applied to the forwarded message. 3539 7. Forward the message with these new payloads. 3541 A GIST node receiving such a message MUST verify that all mandatory 3542 objects containing addressing have been translated correctly, or else 3543 reject the message with an "Object Type Error" message 3544 (Appendix A.4.4.9) with subcode 4 ("Untranslated Object"). The error 3545 message MUST include the NAT-Traversal object as the first TLV after 3546 the common header, and this is also true for any other error message 3547 generated as a response. Otherwise, the message is processed 3548 essentially as normal. If no state needs to be updated for the 3549 message, the NAT-Traversal object can be effectively ignored. The 3550 other possibility is that a Response must be returned, either because 3551 the message is the beginning of a handshake for a new flow, or it is 3552 a refresh for existing state. In both cases, the GIST node MUST 3553 create the Response in the normal way using the local form of the 3554 MRI, and its own NLI and (if necessary) SCD. It MUST also include 3555 the NAT-Traversal object as the first object in the Response after 3556 the common header. 3558 A NAT will intercept D-mode messages with the normal encapsulation 3559 containing such echoed NAT-Traversal objects. The NAT processing is 3560 a subset of the processing for the Q-mode encapsulated case: 3562 1. Verify the existence of bindings for the data flow. 3564 2. Leave the Message-Routing-Information object unchanged. 3566 3. Modify the NLI and SCD objects for the Responding node if 3567 necessary, and create or update any bindings for C-mode signaling 3568 traffic. 3570 4. Forward the message. 3572 A GIST node receiving such a message MUST use the MRI from the NAT- 3573 Traversal object as the key to index its internal routing state; it 3574 MAY also store the translated MRI for additional (e.g. diagnostic) 3575 information, but this is not used in the GIST processing. The 3576 remainder of GIST processing is unchanged. 3578 Note that Confirm messages are not given GIST-specific processing by 3579 the NAT. Thus, a Responding node which has delayed state 3580 installation until receiving the Confirm, only has available the 3581 untranslated MRI describing the flow, and the untranslated NLI as 3582 peer routing state. This would prevent the correct interpretation of 3583 the signaling messages; also, subsequent Query (refresh) messages 3584 would always be seen as route changes because of the NLI change. 3585 Therefore, a Responding node that wishes to delay state installation 3586 until receiving a Confirm must somehow reconstruct the translations 3587 when the Confirm arrives. How to do this is an implementation issue; 3588 one approach is to carry the translated objects as part of the 3589 Responder cookie which is echoed in the Confirm. Indeed, for one of 3590 the cookie constructions in Section 8.5 this is automatic. 3592 7.3. Interaction with IP Tunnelling 3594 The interaction between GIST and IP tunnelling is very simple. An IP 3595 packet carrying a GIST message is treated exactly the same as any 3596 other packet with the same source and destination addresses: in other 3597 words, it is given the tunnel encapsulation and forwarded with the 3598 other data packets. 3600 Tunnelled packets will not be identifiable as GIST messages until 3601 they leave the tunnel, since any router alert option and the standard 3602 GIST protocol encapsulation (e.g. port numbers) will be hidden within 3603 the standard tunnel encapsulation. If signaling is needed for the 3604 tunnel itself, this has to be initiated as a separate signaling 3605 session by one of the tunnel endpoints - that is, the tunnel counts 3606 as a new flow. Because the relationship between signaling for the 3607 microflow and signaling for the tunnel as a whole will depend on the 3608 signaling application in question, it is a signaling application 3609 responsibility to be aware of the fact that tunnelling is taking 3610 place and to carry out additional signaling if necessary; in other 3611 words, at least one tunnel endpoint must be signaling application 3612 aware. 3614 In some cases, it is the tunnel exit point (i.e. the node where 3615 tunnelled data and downstream signaling packets leave the tunnel) 3616 that will wish to carry out the tunnel signaling, but this node will 3617 not have knowledge or control of how the tunnel entry point is 3618 carrying out the data flow encapsulation. The information about how 3619 the inner MRI/SID relate to the tunnel MRI/SID needs to be carried in 3620 the signaling data from the tunnel entry point; this functionality is 3621 the equivalent to the RSVP SESSION_ASSOC object of [14]. In the NSIS 3622 protocol suite, these bindings are managed by the signaling 3623 applications, either implicitly (e.g. by SID re-use) or explicitly by 3624 carrying objects that bind the inner and outer SIDs as part of the 3625 NSLP payload. 3627 7.4. IPv4-IPv6 Transition and Interworking 3629 GIST itself is essentially IP version neutral: version dependencies 3630 are isolated in the formats of the Message-Routing-Information, 3631 Network-Layer-Information and Stack-Configuration-Data objects, and 3632 GIST also depends on the version independence of the protocols that 3633 support messaging associations. In mixed environments, GIST 3634 operation will be influenced by the IP transition mechanisms in use. 3636 This section provides a high level overview of how GIST is affected, 3637 considering only the currently predominant mechanisms. 3639 Dual Stack: (As described in [34].) In mixed environments, GIST 3640 MUST use the same IP version for Q-mode encapsulated messages as 3641 the flow it is signaling for, and SHOULD do so for other signaling 3642 also (see Section 5.2.2). The IP version used in D-mode is 3643 closely tied to the IP version used by the data flow, so it is 3644 intrinsically impossible for an IPv4-only or IPv6-only GIST node 3645 to support signaling for flows using the other IP version. Hosts 3646 which are dual stack for applications and routers which are dual 3647 stack for forwarding need GIST implementations which can support 3648 both IP versions. Applications with a choice of IP versions might 3649 select a version based on which could be supported in the network 3650 by GIST, which could be established by invoking parallel discovery 3651 procedures. 3653 Packet Translation: (Applicable to SIIT [6] and NAT-PT [15].) Some 3654 transition mechanisms allow IPv4 and IPv6 nodes to communicate by 3655 placing packet translators between them. From the GIST 3656 perspective, this should be treated essentially the same way as 3657 any other NAT operation (e.g. between internal and external 3658 addresses) as described in Section 7.2. The translating node 3659 needs to be GIST-aware; it will have to translate the addressing 3660 payloads between IPv4 and IPv6 formats for flows which cross 3661 between the two. The translation rules for the fields in the MRI 3662 payload (including e.g. DiffServ-codepoint and flow-label) are as 3663 defined in [6]. 3665 Tunnelling: (Applicable to 6to4 [17].) Many transition mechanisms 3666 handle the problem of how an end to end IPv6 (or IPv4) flow can be 3667 carried over intermediate IPv4 (or IPv6) regions by tunnelling; 3668 the methods tend to focus on minimising the tunnel administration 3669 overhead. 3671 From the GIST perspective, the treatment should be as similar as 3672 possible to any other IP tunnelling mechanism, as described in 3673 Section 7.3. In particular, the end to end flow signaling will 3674 pass transparently through the tunnel, and signaling for the 3675 tunnel itself will have to be managed by the tunnel endpoints. 3676 However, additional considerations may arise because of special 3677 features of the tunnel management procedures. In particular, [18] 3678 is based on using an anycast address as the destination tunnel 3679 endpoint. GIST MAY use anycast destination addresses in the 3680 Q-mode encapsulation of D-mode messages if necessary, but MUST NOT 3681 use them in the Network-Layer-Information addressing field; normal 3682 unicast addresses MUST be used instead. Note that the addresses 3683 from the IP header are not used by GIST in matching requests and 3684 responses, so there is no requirement to use anycast source 3685 addresses. 3687 8. Security Considerations 3689 The security requirement for GIST is to protect the signaling plane 3690 against identified security threats. For the signaling problem as a 3691 whole, these threats have been outlined in [27]; the NSIS framework 3692 [26] assigns a subset of the responsibilities to the NTLP. The main 3693 issues to be handled can be summarised as: 3695 Message Protection: Signaling message content can be protected 3696 against eavesdropping, modification, injection and replay while in 3697 transit. This applies both to GIST payloads, and GIST should also 3698 provide such protection as a service to signaling applications 3699 between adjacent peers. 3701 Routing State Integrity Protection: It is important that signaling 3702 messages are delivered to the correct nodes, and nowhere else. 3703 Here, 'correct' is defined as 'the appropriate nodes for the 3704 signaling given the Message-Routing-Information'. In the case 3705 where the MRI is based on the Flow Identification for path-coupled 3706 signaling, 'appropriate' means 'the same nodes that the 3707 infrastructure will route data flow packets through'. GIST has no 3708 role in deciding whether the data flow itself is being routed 3709 correctly; all it can do is ensure the signaling is routed 3710 consistently with it. GIST uses internal state to decide how to 3711 route signaling messages, and this state needs to be protected 3712 against corruption. 3714 Prevention of Denial of Service Attacks: GIST nodes and the network 3715 have finite resources (state storage, processing power, 3716 bandwidth). The protocol tries to minimise exhaustion attacks 3717 against these resources and not allow GIST nodes to be used to 3718 launch attacks on other network elements. 3720 The main additional issue is handling authorisation for executing 3721 signaling operations (e.g. allocating resources). This is assumed to 3722 be done in each signaling application. 3724 In many cases, GIST relies on the security mechanisms available in 3725 messaging associations to handle these issues, rather than 3726 introducing new security measures. Obviously, this requires the 3727 interaction of these mechanisms with the rest of the GIST protocol to 3728 be understood and verified, and some aspects of this are discussed in 3729 Section 5.7. 3731 8.1. Message Confidentiality and Integrity 3733 GIST can use messaging association functionality, specifically in 3734 this version TLS (Section 5.7.3), to ensure message confidentiality 3735 and integrity. Implementation of this functionality is REQUIRED but 3736 its use for any given flow or signaling application is OPTIONAL. In 3737 some cases, confidentiality of GIST information itself is not likely 3738 to be a prime concern, in particular since messages are often sent to 3739 parties which are unknown ahead of time, although the content visible 3740 even at the GIST level gives significant opportunities for traffic 3741 analysis. Signaling applications may have their own mechanism for 3742 securing content as necessary; however, they may find it convenient 3743 to rely on protection provided by messaging associations, since it 3744 runs unbroken between signaling application peers. 3746 8.2. Peer Node Authentication 3748 Cryptographic protection (of confidentiality or integrity) requires a 3749 security association with session keys. These can be established by 3750 an authentication and key exchange protocol based on shared secrets, 3751 public key techniques or a combination of both. Authentication and 3752 key agreement is possible using the protocols associated with the 3753 messaging association being secured. TLS incorporates this 3754 functionality directly; IKE, IKEv2 or KINK could provide it for 3755 IPsec. GIST nodes rely on these protocols to authenticate the 3756 identity of the next hop, and GIST has no authentication capability 3757 of its own. 3759 With routing state discovery, there are few effective ways to know 3760 what is the legitimate next or previous hop as opposed to an 3761 impostor. In other words, cryptographic authentication here only 3762 provides assurance that a node is 'who' it is (i.e. the legitimate 3763 owner of identity in some namespace), not 'what' it is (i.e. a node 3764 which is genuinely on the flow path and therefore can carry out 3765 signaling for a particular flow). Authentication provides only 3766 limited protection, in that a known peer is unlikely to lie about its 3767 role. Additional methods of protection against this type of attack 3768 are considered in Section 8.3 below. 3770 It is an implementation issue whether peer node authentication should 3771 be made signaling application dependent; for example, whether 3772 successful authentication could be made dependent on presenting 3773 credentials related to a particular signaling role (e.g. signaling 3774 for QoS). The abstract API of Appendix B leaves open such policy and 3775 authentication interactions between GIST and the NSLP it is serving. 3776 However, it does allow applications to inspect the authenticated 3777 identity of the peer to which a message will be sent before 3778 transmission. 3780 8.3. Routing State Integrity 3782 Internal state in a node (see Section 4.2) is used to route messages. 3783 If this state is corrupted, signaling messages may be misdirected. 3785 In the case where the MRM is path-coupled, the messages need to be 3786 routed identically to the data flow described by the MRI, and the 3787 routing state table is the GIST view of how these flows are being 3788 routed through the network in the immediate neighbourhood of the 3789 node. Routes are only weakly secured (e.g. there is no cryptographic 3790 binding of a flow to a route), and there is no authoritative 3791 information about flow routes other than the current state of the 3792 network itself. Therefore, consistency between GIST and network 3793 routing state has to be ensured by directly interacting with the 3794 routing mechanisms to ensure that the signaling peers are the 3795 appropriate ones for any given flow. An overview of security issues 3796 and techniques in this context is provided in [38]. 3798 In one direction, peer identification is installed and refreshed only 3799 on receiving a Response (compare Figure 4). This MUST echo the 3800 cookie from a previous Query, which will have been sent along the 3801 flow path with the Q-mode encapsulation, i.e. end-to-end addressed. 3802 Hence, only the true next peer or an on-path attacker will be able to 3803 generate such a message, provided freshness of the cookie can be 3804 checked at the querying node. 3806 In the other direction, peer identification MAY be installed directly 3807 on receiving a Query containing addressing information for the 3808 signaling source. However, any node in the network could generate 3809 such a message; indeed, many nodes in the network could be the 3810 genuine upstream peer for a given flow. To protect against this, 3811 three strategies are used: 3813 Filtering: the receiving node MAY reject signaling messages which 3814 claim to be for flows with flow source addresses which could be 3815 ruled out by ingress filtering. An extension of this technique 3816 would be for the receiving node to monitor the data plane and to 3817 check explicitly that the flow packets are arriving over the same 3818 interface and if possible from the same link layer neighbour as 3819 the D-mode signaling packets. If they are not, it is likely that 3820 at least one of the signaling or flow packets is being spoofed. 3822 Authentication (weak or strong): the receiving node MAY refuse to 3823 install upstream state until it has completed a Confirm handshake 3824 with the peer. This echoes the Response cookie of the Response, 3825 and discourages nodes from using forged source addresses. This 3826 also plays a role in denial of service prevention, see below. A 3827 stronger approach is to require full peer authentication within 3828 the messaging association, the reasoning being that an 3829 authenticated peer can be trusted not to pretend that it is on 3830 path when it is not. 3832 SID segregation: The routing state lookup for a given MRI and NSLPID 3833 MUST also take the SID into account. A malicious node can only 3834 overwrite existing routing state if it can guess the corresponding 3835 SID; it can insert state with random SID values, but generally 3836 this will not be used to route messages for which state has 3837 already been legitimately established. 3839 8.4. Denial of Service Prevention 3841 GIST is designed so that in general each Query only generates at most 3842 one Response which is at most only slightly larger than the Query, so 3843 that a GIST node cannot become the source of a denial of service 3844 amplification attack. (There is a special case of retransmitted 3845 Response messages, see Section 5.3.3.) 3847 However, GIST can still be subjected to denial-of-service attacks 3848 where an attacker using forged source addresses forces a node to 3849 establish state without return routability, causing a problem similar 3850 to TCP SYN flood attacks. Furthermore, an adversary might use 3851 modified or replayed unprotected signaling messages as part of such 3852 an attack. There are two types of state attacks and one 3853 computational resource attack. In the first state attack, an 3854 attacker floods a node with messages that the node has to store until 3855 it can determine the next hop. If the destination address is chosen 3856 so that there is no GIST-capable next hop, the node would accumulate 3857 messages for several seconds until the discovery retransmission 3858 attempt times out. The second type of state-based attack causes GIST 3859 state to be established by bogus messages. A related computational/ 3860 network-resource attack uses unverified messages to cause a node 3861 query an authentication or authorisation infrastructure, or attempt 3862 to cryptographically verify a digital signature. 3864 We use a combination of two defences against these attacks: 3866 1. The responding node need not establish a session or discover its 3867 next hop on receiving the Query, but MAY wait for a Confirm, 3868 possibly on a secure channel. If the channel exists, the 3869 additional delay is one one-way delay and the total is no more 3870 than the minimal theoretically possible delay of a three-way 3871 handshake, i.e., 1.5 node-to-node round-trip times. The delay 3872 gets significantly larger if a new connection needs to be 3873 established first. 3875 2. The Response to the Query contains a cookie, which is repeated in 3876 the Confirm. State is only established for messages that contain 3877 a valid cookie. The setup delay is also 1.5 round-trip times. 3878 This mechanism is similar to that in SCTP [16] and other modern 3879 protocols. 3881 Once a node has decided to establish routing state, there may still 3882 be transport and security state to be established between peers. 3883 This state setup is also vulnerable to denial of service attacks. 3884 GIST relies on the lower layer protocols that make up messaging 3885 associations to mitigate such attacks. In the current specification, 3886 the querying node is always the one wishing to establish a messaging 3887 association, so it is the responding node that needs to be protected. 3889 Signaling applications can use the services provided by GIST to 3890 defend against certain (e.g. flooding) denial of service attacks. In 3891 particular, they can elect to process only messages from peers that 3892 have passed a return routability check or been authenticated at the 3893 messaging association level (see Appendix B.2). Signaling 3894 applications that accept messages under other circumstances (in 3895 particular, before routing state has been fully established at the 3896 GIST level) need to take this into account when designing their 3897 denial of service prevention mechanisms, for example by not creating 3898 local state as a result of processing such messages. 3900 8.5. Requirements on Cookie Mechanisms 3902 The requirements on the Query cookie can be summarised as follows: 3904 Liveness: The cookie must be live, that is, it must change from one 3905 handshake to the next. To prevent replay attacks. 3907 Unpredictability: The cookie must not be guessable e.g. from a 3908 sequence or timestamp. To prevent direct forgery based on seeing 3909 a history of captured messages. 3911 Easily validated: It must be efficient for the Q-Node to validate 3912 that a particular cookie matches an in-progress handshake, for a 3913 routing state machine which already exists. To discard responses 3914 which have been randomly generated by an adversary, or to discard 3915 responses to queries which were generated with forged source 3916 addresses or an incorrect address in the included NLI object. 3918 Uniqueness: The cookie must be unique to a given handshake since it 3919 is actually used to match the Response to a handshake anyway, e.g. 3920 during messaging association re-use. 3922 Likewise, the requirements on the Responder cookie can be summarised 3923 as follows: 3925 Liveness: The cookie must be live as above. To prevent replay 3926 attacks. 3928 Creation simplicity: The cookie must be lightweight to generate. To 3929 avoid resource exhaustion at the responding node. 3931 Validation simplicity: It must be simple for the R-node to validate 3932 that an R-cookie was generated by itself and no-one else, without 3933 storing state about the handshake it was generated for. 3935 Binding: The cookie must be bound to the routing state that will be 3936 installed. To prevent use with different routing state e.g. in a 3937 modified Confirm. The routing state here includes the NLI of the 3938 Query, the MRI/NSLPID for the messaging, and the interface on 3939 which the Query was received. 3941 A suitable implementation for the Q-Cookie is a cryptographically 3942 strong random number which is unique for this routing state machine 3943 handshake. A node MUST implement this or an equivalently strong 3944 mechanism. Guidance on random number generation can be found in 3945 [28]. 3947 A suitable implementation for the R-Cookie is as follows: 3949 R-Cookie = liveness data + hash (locally known secret, 3950 Q-Node NLI, MRI, NSLPID, 3951 reception interface, 3952 liveness data) 3954 A node MUST implement this or an equivalently strong mechanism. 3955 There are several alternatives for the liveness data. One is to use 3956 a timestamp like SCTP. Another is to give the local secret a (rapid) 3957 rollover, with the liveness data as the generation number of the 3958 secret, like IKEv2. In both cases, the liveness data has to be 3959 carried outside the hash, to allow the hash to be verified at the 3960 Responder. Another approach is to replace the hash with encryption 3961 under a locally known secret, in which case the liveness data does 3962 not need to be carried in the clear. Any symmetric cipher immune to 3963 known plaintext attacks can be used. 3965 To support the validation simplicity requirement, the Responder can 3966 check the liveness data to filter out some blind (flooding) attacks 3967 before beginning any cryptographic cookie verification. To support 3968 this usage, the liveness data must be carried in the clear and not be 3969 easily guessable; this rules out the timestamp approach, and suggests 3970 the use of sequence of secrets with the liveness data identifying the 3971 position in the sequence. The secret strength and rollover frequency 3972 must be high enough that the secret cannot be brute-forced during its 3973 lifetime. Note that any node can use a Query to discover the current 3974 liveness data, so it remains hard to defend against sophisticated 3975 attacks which disguise such probes within a flood of Queries from 3976 forged source addresses. Therefore, it remains important to use an 3977 efficient hashing mechanism or equivalent. 3979 If a node receives a message for which cookie validation fails, it 3980 MAY return an "Object Value Error" error message (Appendix A.4.4.10) 3981 with subcode 4 ("Invalid Cookie") to the sender, as well as dropping 3982 the message. However, doing so in general makes a node a source of 3983 backscatter. Therefore, this MUST only be enabled selectively, e.g. 3984 during initial deployment or debugging. 3986 8.6. Security Protocol Selection Policy 3988 This specification defines a single mandatory-to-implement security 3989 protocol (TLS, Section 5.7.3). However, it is possible to define 3990 additional security protocols in the future, for example to allow re- 3991 use with other types of credentials, or migrate towards protocols 3992 with stronger security properties. In addition, use of any security 3993 protocol for a messaging association is optional. Security protocol 3994 selection is carried out as part of the GIST handshake mechanism 3995 (Section 4.4.1). 3997 The selection process may be vulnerable to downgrade attacks, where a 3998 man in the middle modifies the capabilities offered in the Query or 3999 Response to mislead the peers into accepting a lower level of 4000 protection than is achievable. There is a two part defence against 4001 such attacks (the following is based the same concepts as [22]): 4003 1. The Response does not depend on the Stack-Proposal in the Query 4004 (see Section 5.7.1). Therefore, tampering with the Query has no 4005 effect on the resulting messaging association configuration. 4007 2. The Responding node's Stack-Proposal is echoed in the Confirm. 4008 The Responding node checks this to validate that the proposal it 4009 made in the Response is the same as the one received by the 4010 Querying node. Note that as a consequence of the previous point, 4011 the Responding node does not have to remember the proposal 4012 explicitly, since it is a static function of local policy. 4014 The validity of the second part depends on the strength of the 4015 security protection provided for the Confirm. If the Querying node 4016 is prepared to create messaging associations with null security 4017 properties (e.g. TCP only), the defence is ineffective, since the 4018 man in the middle can re-insert the original Responder's Stack- 4019 Proposal, and the Responding node will assume that the minimal 4020 protection is a consequence of Querying node limitations. However, 4021 if the messaging association provides at least integrity protection 4022 that cannot be broken in real-time, the Confirm cannot be modified in 4023 this way. Therefore, if the Querying node does not apply a security 4024 policy to the messaging association protocols to be created that 4025 ensures at least this minimal level of protection is met, it remains 4026 open to the threat that a downgrade has occurred. Applying such a 4027 policy ensures capability discovery process will result in the setup 4028 of a messaging association with the correct security properties as 4029 appropriate for the two peers involved. 4031 8.7. Residual Threats 4033 Taking the above security mechanisms into account, the main residual 4034 threats against NSIS are three types of on-path attack. 4036 An on-path attacker who can intercept the initial Query can do most 4037 things it wants to the subsequent signaling. It is very hard to 4038 protect against this at the GIST level; the only defence is to use 4039 strong messaging association security to see whether the Responding 4040 node is authorised to take part in NSLP signaling exchanges. To some 4041 extent, this behaviour is logically indistinguishable from correct 4042 operation, so it is easy to see why defence is difficult. Note that 4043 an on-path attacker of this sort can do anything to the traffic as 4044 well as the signaling. Therefore, the additional threat induced by 4045 the signaling weakness seems tolerable. 4047 At the NSLP level, there is a concern about transitivity of trust of 4048 correctness of routing along the signaling chain. The NSLP at the 4049 querying node can have good assurance that it is communicating with 4050 an on-path peer or a node delegated by the on-path node. However, it 4051 has no assurance that the node beyond the responder is also on-path, 4052 or that the MRI (in particular) is not being modified by the 4053 responder to refer to a different flow. Therefore, if it sends 4054 signaling messages with payloads (e.g. authorisation tokens) which 4055 are valuable to nodes beyond the adjacent hop, it is up to the NSLP 4056 to ensure that the appropriate chain of trust exists, which must in 4057 general use strong messaging association security. 4059 There is a further residual attack by a node which is not on the path 4060 of the Query, but is on the path of the Response, or is able to use a 4061 Response from one handshake to interfere with another. The attacker 4062 modifies the Response to cause the Querying node to form an adjacency 4063 with it rather than the true peer. In principle, this attack could 4064 be prevented by including an additional cryptographic object in the 4065 Response which ties the Response to the initial Query and the routing 4066 state and can be verified by the Querying node. 4068 9. IANA Considerations 4070 This section defines the registries and initial codepoint assignments 4071 for GIST. It also defines the procedural requirements to be followed 4072 by IANA in allocating new codepoints. Note that the guidelines on 4073 the technical criteria to be followed in evaluating requests for new 4074 codepoint assignments are covered normatively in a separate document 4075 which considers the NSIS protocol suite in a unified way. That 4076 document discusses the general issue of NSIS extensibility, as well 4077 as the technical criteria for particular registries; see [11] for 4078 further details. 4080 The registry definitions that follow leave large blocks of codes 4081 reserved as unused. This is to allow a future revision of this 4082 specification to modify the allocation policies without having to 4083 retrospectively change the initial rules if they turn out to have 4084 been suboptimal, e.g. if the space for one particular policy is 4085 exhausted too quickly. 4087 The allocation policies used in this section follow the guidance 4088 given in [3]. In addition, for a number of the GIST registries, this 4089 specification also defines private/experimental ranges as discussed 4090 in [8]. Note that the only environment in which these codepoints can 4091 validly be used is a closed one in which the experimenter knows all 4092 the experiments in progress. 4094 This specification allocates the following codepoints in existing 4095 registries: 4097 Well-known UDP port XXX as the destination port for Q-mode 4098 encapsulated GIST messages (Section 5.3). 4100 This specification creates the following registries with the 4101 structures as defined below: 4103 NSLP Identifiers: Each signaling application requires the assignment 4104 of one of more NSLPIDs. The following NSLPID is allocated by this 4105 specification: 4107 +---------+---------------------------------------------------------+ 4108 | NSLPID | Application | 4109 +---------+---------------------------------------------------------+ 4110 | 0 | Used for GIST messages not related to any signaling | 4111 | | application. | 4112 +---------+---------------------------------------------------------+ 4114 Every other NSLPID MUST be associated with a specific RAO value; 4115 multiple NSLPIDs MAY be associated with the same value. The 4116 NSLPID is a 16 bit integer, and allocation policies for further 4117 values are as follows: 4119 1-32703: IESG Approval 4121 32704-32767: Private/Experimental Use 4123 32768-65536: Reserved 4125 GIST Message Type: The GIST common header (Appendix A.1) contains a 4126 1 byte message type field. The following values are allocated by 4127 this specification: 4129 +---------+----------+ 4130 | MType | Message | 4131 +---------+----------+ 4132 | 0 | Query | 4133 | | | 4134 | 1 | Response | 4135 | | | 4136 | 2 | Confirm | 4137 | | | 4138 | 3 | Data | 4139 | | | 4140 | 4 | Error | 4141 | | | 4142 | 5 | MA-Hello | 4143 +---------+----------+ 4145 Allocation policies for further values are as follows: 4147 6-63: Standards Action 4149 64-119: Expert Review 4151 120-127: Private/Experimental Use 4153 128-255: Reserved 4155 Object Types: There is a 12-bit field in the object header 4156 (Appendix A.2). The following values for object type are defined 4157 by this specification: 4159 +---------+-----------------------------+ 4160 | OType | Object Type | 4161 +---------+-----------------------------+ 4162 | 0 | Message Routing Information | 4163 | | | 4164 | 1 | Session ID | 4165 | | | 4166 | 2 | Network Layer Information | 4167 | | | 4168 | 3 | Stack Proposal | 4169 | | | 4170 | 4 | Stack Configuration Data | 4171 | | | 4172 | 5 | Query Cookie | 4173 | | | 4174 | 6 | Responder Cookie | 4175 | | | 4176 | 7 | NAT Traversal | 4177 | | | 4178 | 8 | NSLP Data | 4179 | | | 4180 | 9 | Error | 4181 +---------+-----------------------------+ 4183 Allocation policies for further values are as follows: 4185 10-1023: Standards Action 4187 1024-1999: Specification Required 4189 2000-2047: Private/Experimental Use 4191 2048-4095: Reserved 4193 When a new object type is defined, the object format MUST be 4194 provided, and the setting of the extensibility bits (A/B, see 4195 Appendix A.2.1) MUST also be defined. 4197 Message Routing Methods: GIST allows multiple message routing 4198 methods (see Section 3.3). The MRM is indicated in the leading 4199 byte of the MRI object (Appendix A.3.1). This specification 4200 defines the following values: 4202 +------------+------------------------+ 4203 | MRM-ID | Message Routing Method | 4204 +------------+------------------------+ 4205 | 0 | Path Coupled MRM | 4206 | | | 4207 | 1 | Loose End MRM | 4208 +------------+------------------------+ 4210 Allocation policies for further values are as follows: 4212 2-63: Standards Action 4214 64-119: Expert Review 4216 120-127: Private/Experimental Use 4218 128-255: Reserved 4220 When a new MRM is defined, the specification MUST provide the 4221 information described in Section 3.3. 4223 MA-Protocol-IDs: Each upper layer protocol that can be used in a 4224 messaging association is identified by a 1-byte MA-Protocol-ID 4225 (Section 5.7). This is used as a tag in the Stack-Proposal and 4226 Stack-Configuration-Data objects (Appendix A.3.4 and 4227 Appendix A.3.5). The following values are defined by this 4228 specification: 4230 +---------------------+-----------------------------------------+ 4231 | MA-Protocol-ID | Higher Layer Protocol | 4232 +---------------------+-----------------------------------------+ 4233 | 0 | Reserved - not to be allocated | 4234 | | | 4235 | 1 | TCP opened in the forwards direction | 4236 | | | 4237 | 2 | TLS initiated in the forwards direction | 4238 +---------------------+-----------------------------------------+ 4240 Allocation policies for further values are as follows: 4242 3-63: Standards Action 4244 64-119: Expert Review 4246 120-127: Private/Experimental Use 4247 128-255: Reserved 4249 Allocation of a new MA-Protocol-ID MUST define the format for the 4250 MA-protocol-options field (if any) in the Stack-Configuration-Data 4251 object that is needed to define its configuration. If a protocol 4252 is to be used for reliable message transfer, it MUST be described 4253 how delivery errors are to be detected by GIST. Note that the MA- 4254 Protocol-ID is not an IP Protocol number; indeed, some of the 4255 messaging association protocols - such as TLS - do not have an IP 4256 Protocol number. 4258 Error Codes/Subcodes: There is a 2 byte error code and 1 byte 4259 subcode in the Value field of the Error object (Appendix A.4.1). 4260 Error codes 1-12 are defined in Appendix A.4.4 together with 4261 subcodes 0-4 for code 1, 0-5 for code 9, 0-5 for code 10, and 0-2 4262 for code 12. Additional codes and subcodes are allocated on a 4263 first-come, first served basis. When a new error code/subcode 4264 combination is allocated, the Error Class and the format of any 4265 associated error-specific information MUST also be defined. 4267 10. Acknowledgements 4269 This document is based on the discussions within the IETF NSIS 4270 working group. It has been informed by prior work and formal and 4271 informal inputs from: Cedric Aoun, Attila Bader, Roland Bless, Bob 4272 Braden, Marcus Brunner, Benoit Campedel, Yoshiko Chong, Luis 4273 Cordeiro, Elwyn Davies, Christian Dickmann, Pasi Eronen, Alan Ford, 4274 Xiaoming Fu, Bo Gao, Ruediger Geib, Eleanor Hepworth, Thomas Herzog, 4275 Cheng Hong, Jia Jia, Cornelia Kappler, Georgios Karagiannis, Ruud 4276 Klaver, Chris Lang, John Loughney, Allison Mankin, Jukka Manner, Pete 4277 McCann, Andrew McDonald, Glenn Morrow, Dave Oran, Andreas Pashalidis, 4278 Henning Peters, Tom Phelan, Akbar Rahman, Takako Sanda, Charles Shen, 4279 Melinda Shore, Martin Stiemerling, Martijn Swanink, Mike Thomas, 4280 Hannes Tschofenig, Sven van den Bosch, Michael Welzl, Lars Westberg, 4281 and Mayi Zoumaro-djayoon. Parts of the TLS usage description 4282 (Section 5.7.3) were derived from the Diameter base protocol 4283 specification, RFC3588. In addition, Hannes Tschofenig provided a 4284 detailed set of review comments on the security section, and Andrew 4285 McDonald provided the formal description for the initial packet 4286 formats. Chris Lang's implementation work provided objective 4287 feedback on the clarity and feasibility of the specification, and he 4288 also provided the state machine description and the initial error 4289 catalogue and formats. Finally, Magnus Westerlund carried out a 4290 detailed AD review which identified a number of issues and led to 4291 significant clarifications. 4293 11. References 4295 11.1. Normative References 4297 [1] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 4299 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4300 Levels", BCP 14, RFC 2119, March 1997. 4302 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 4303 Considerations Section in RFCs", BCP 26, RFC 2434, 4304 October 1998. 4306 [4] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 4307 the Differentiated Services Field (DS Field) in the IPv4 and 4308 IPv6 Headers", RFC 2474, December 1998. 4310 [5] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 4311 RFC 2711, October 1999. 4313 [6] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 4314 RFC 2765, February 2000. 4316 [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 4317 RFC 2246, January 1999. 4319 [8] Narten, T., "Assigning Experimental and Testing Numbers 4320 Considered Useful", BCP 82, RFC 3692, January 2004. 4322 [9] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 4323 Specifications: ABNF", RFC 4234, October 2005. 4325 [10] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 4326 Protocol Version 1.1", RFC 4346, April 2006. 4328 [11] Loughney, J., "NSIS Extensibility Model", 4329 draft-loughney-nsis-ext-02 (work in progress), March 2006. 4331 11.2. Informative References 4333 [12] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 4334 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 4335 Specification", RFC 2205, September 1997. 4337 [13] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 4339 [14] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP 4340 Operation Over IP Tunnels", RFC 2746, January 2000. 4342 [15] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 4343 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 4345 [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 4346 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 4347 Paxson, "Stream Control Transmission Protocol", RFC 2960, 4348 October 2000. 4350 [17] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 4351 IPv4 Clouds", RFC 3056, February 2001. 4353 [18] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 4354 RFC 3068, June 2001. 4356 [19] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 4357 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 4358 September 2001. 4360 [20] Grossman, D., "New Terminology and Clarifications for 4361 Diffserv", RFC 3260, April 2002. 4363 [21] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 4364 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 4365 RFC 3320, January 2003. 4367 [22] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 4368 Haukka, "Security Mechanism Agreement for the Session 4369 Initiation Protocol (SIP)", RFC 3329, January 2003. 4371 [23] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 4372 - Simple Traversal of User Datagram Protocol (UDP) Through 4373 Network Address Translators (NATs)", RFC 3489, March 2003. 4375 [24] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 4376 of UDP Through NAT (STUN)", draft-ietf-behave-turn-01 (work in 4377 progress), June 2006. 4379 [25] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 4380 Security Mechanism (GTSM)", RFC 3682, February 2004. 4382 [26] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 4383 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 4384 June 2005. 4386 [27] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 4387 Steps in Signaling (NSIS)", RFC 4081, June 2005. 4389 [28] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 4390 Requirements for Security", BCP 106, RFC 4086, June 2005. 4392 [29] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 4393 Transport Layer Security (TLS)", RFC 4279, December 2005. 4395 [30] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion 4396 Control Protocol (DCCP)", RFC 4340, March 2006. 4398 [31] Conta, A., Deering, S., and M. Gupta, "Internet Control Message 4399 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 4400 Specification", RFC 4443, March 2006. 4402 [32] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 4403 (NSLP)", draft-ietf-nsis-nslp-natfw-12 (work in progress), 4404 June 2006. 4406 [33] Manner, J., "NSLP for Quality-of-Service Signaling", 4407 draft-ietf-nsis-qos-nslp-11 (work in progress), June 2006. 4409 [34] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 4410 IPv6 Hosts and Routers", RFC 4213, October 2005. 4412 [35] Kent, S. and K. Seo, "Security Architecture for the Internet 4413 Protocol", RFC 4301, December 2005. 4415 [36] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol 4416 Architecture", RFC 4251, January 2006. 4418 [37] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06 4419 (work in progress), June 2006. 4421 [38] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 4422 Nordmark, "Mobile IP Version 6 Route Optimization Security 4423 Design Background", RFC 4225, December 2005. 4425 [39] Floyd, S. and V. Jacobson, "The Synchronisation of Periodic 4426 Routing Messages", SIGCOMM Symposium on Communications 4427 Architectures and Protocols pp. 33--44, September 1993. 4429 [40] Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal", 4430 draft-pashalidis-nsis-gimps-nattraversal-03 (work in progress), 4431 June 2006. 4433 [41] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4434 Security", RFC 4347, April 2006. 4436 Appendix A. Bit-Level Formats and Error Messages 4438 This appendix provides formats for the various component parts of the 4439 GIST messages defined abstractly in Section 5.2. 4441 Each GIST message consists of a header and a sequence of objects. 4442 The GIST header has a specific format, described in more detail in 4443 Appendix A.1 below. An NSLP message is one object within a GIST 4444 message. Note that GIST itself provides the NSLP message length 4445 information and signaling application identification. General object 4446 formatting guidelines are provided in Appendix A.2 below, followed in 4447 Appendix A.3 by the format for each object. Finally, Appendix A.4 4448 provides the formats used for error reporting. 4450 In the following object diagrams, '//' is used to indicate a variable 4451 sized field and ':' is used to indicate a field that is optionally 4452 present. 4454 A.1. The GIST Common Header 4456 This header begins all GIST messages. It has a fixed format, as 4457 shown below. 4459 0 1 2 3 4460 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 4461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4462 | Version | GIST hops | Message Length | 4463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4464 | NSLPID | Type |S|R|E| Reserved| 4465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4467 Version (8 bits): The GIST protocol version number. 4469 GIST hops (8 bits): A hop count for the number of GIST-aware nodes 4470 this message can still pass through. 4472 Message Length (16 bits): The total number of 32-bit words in the 4473 message after the common header itself. 4475 NSLPID (16 bits): IANA assigned identifier of the signaling 4476 application the message refers to. 4478 Type (8 bits): The GIST message type (Query, Response, etc.). 4480 S flag: S=1 if the IP source address is the same as the signaling 4481 source address, S=0 if it is different. 4483 R flag: R=1 if a reply to this message is explicitly requested. 4485 E flag: E=1 if the message was explicitly routed (Section 7.1.4). 4487 The rules governing the use of the R-flag depend on the GIST message 4488 type. It MUST always be set (R=1) in Query messages, since these 4489 always elicit a Response, and never in Confirm, Data or Error 4490 messages. It is optional in an MA-Hello; if set, another MA-Hello is 4491 sent in reply. It is optional in a Response, but MUST be set if the 4492 Response contains a Responder cookie; if set, a Confirm is sent in 4493 reply. The E flag MUST NOT be set unless the message type is a Data 4494 message. 4496 Parsing failures may be caused by unknown Version or Type values, 4497 inconsistent R or E flag setting, or a Message Length inconsistent 4498 with the set of objects carried. In all cases the receiver MUST if 4499 possible return a "Common Header Parse Error" message 4500 (Appendix A.4.4.1) with the appropriate subcode, and not process the 4501 message further. 4503 A.2. General Object Format 4505 Each object begins with a fixed header giving the object Type and 4506 object Length. This is followed by the object Value, which is a 4507 whole number of 32-bit words long. 4509 0 1 2 3 4510 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 4511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4512 |A|B|r|r| Type |r|r|r|r| Length | 4513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4514 // Value // 4515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4517 A/B flags: The bits marked 'A' and 'B' are extensibility flags which 4518 are defined in Appendix A.2.1 below; the remaining bits marked 'r' 4519 are reserved. 4521 Type (12 bits): An IANA-assigned identifier for the type of object. 4523 Length (12 bits): Length has the units of 32-bit words, and measures 4524 the length of Value. If there is no Value, Length=0. If the 4525 Length is not consistent with the contents of the object, an 4526 "Object Value Error" message (Appendix A.4.4.10) with subcode 0 4527 "Incorrect Length" MUST be returned and the message dropped. 4529 Value (variable): Value is (therefore) a whole number of 32 bit 4530 words. If there is any padding required, the length and location 4531 must be defined by the object-specific format information; objects 4532 which contain variable length (e.g. string) types may need to 4533 include additional length subfields to do so. 4535 Any part of the object used for padding or defined as reserved 4536 (marked 'Reserved' or 'Rsv' or, in the case of individual bits, 'r' 4537 in the diagrams below) MUST be set to 0 on transmission and MUST be 4538 ignored on reception. 4540 A.2.1. Object Extensibility 4542 The leading two bits of the TLV header are used to signal the desired 4543 treatment for objects whose Type field is unknown at the receiver. 4544 The following three categories of object have been identified, and 4545 are described here. 4547 AB=00 ("Mandatory"): If the object is not understood, the entire 4548 message containing it MUST be rejected with an "Object Type Error" 4549 message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object"). 4551 AB=01 ("Ignore"): If the object is not understood, it MUST be 4552 deleted and the rest of the message processed as usual. 4554 AB=10 ("Forward"): If the object is not understood, it MUST be 4555 retained unchanged in any message forwarded as a result of message 4556 processing, but not stored locally. 4558 The combination AB=11 is reserved. If a message is received 4559 containing and object with AB=11, it MUST be rejected with an "Object 4560 Type Error" message (Appendix A.4.4.9) with subcode 5 ("Invalid 4561 Extensibility Flags"). 4563 A.3. GIST TLV Objects 4565 A.3.1. Message-Routing-Information 4567 Type: Message-Routing-Information 4569 Length: Variable (depends on MRM) 4570 0 1 2 3 4571 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 4572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4573 | MRM-ID |N| Reserved | | 4574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4575 // Method-specific addressing information (variable) // 4576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4578 MRM-ID (8 bits): An IANA-assigned identifier for the message routing 4579 method. 4581 N flag: If set (N=1), this means that NATs do not need to translate 4582 this MRM; if clear (N=0) it means that the method-specific 4583 information contains network or transport layer information that a 4584 NAT must process. 4586 The remainder of the object contains method-specific addressing 4587 information, which is described below. 4589 A.3.1.1. Path-Coupled MRM 4591 In the case of basic path-coupled routing, the addressing information 4592 takes the following format. The N-flag N=0 for this MRM. 4594 0 1 2 3 4595 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 4596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4597 |IP-Ver |P|T|F|S|A|B|D|Reserved | 4598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4599 // Source Address // 4600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4601 // Destination Address // 4602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4603 | Source Prefix | Dest Prefix | Protocol | DS-field |Rsv| 4604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4605 : Reserved | Flow Label : 4606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4607 : SPI : 4608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4609 : Source Port : Destination Port : 4610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4612 IP-Ver (4 bits): The IP version number, 4 or 6. 4614 Source/Destination address (variable): The source and destination 4615 addresses are always present and of the same type; their length 4616 depends on the value in the IP-Ver field. 4618 Source/Dest Prefix (each 8 bits): The length of the mask to be 4619 applied to the source and destination addresses for address 4620 wildcarding. In the normal case where the MRI refers only to 4621 traffic between specific host addresses, the Source/Dest Prefix 4622 values would both be 32/128 for IPv4/6 respectively. 4624 P flag: P=1 means that IP Protocol should be interpreted. 4626 Protocol (8 bits): The IP protocol number. Ignored if P=0. In the 4627 case of IPv6, the Protocol field refers to the true upper layer 4628 protocol carried by the packets, i.e. excluding any IP option 4629 headers. This is therefore not necessarily the same as the Next 4630 Header value from the base IPv6 header. 4632 T flag: T=1 means that DiffServ field (DS-field) should be 4633 interpreted. 4635 DS-field (6 bits): The DiffServ field. See [4] and [20]. 4637 F flag: F=1 means that flow label is present and should be 4638 interpreted. 4640 Flow Label (20 bits): The flow label; only present if F=1. If F=0, 4641 the entire 32 bit word containing the Flow Label is absent. F may 4642 only be set if IP-Ver is 6. 4644 S flag: S=1 means that the SPI field is present. Can only be set if 4645 P=1. 4647 SPI field (32 bits): The SPI field; see [35]. Only present if S=1. 4649 A/B flags: These can only be set if P=1. If either is set, the port 4650 fields are also present. 4652 Source/Destination Port (each 16 bits): If either of A, B is set the 4653 word containing the port numbers is included in the object. 4654 However, the contents of each field is only significant if the 4655 corresponding flag is set; otherwise, the contents of the field is 4656 regarded as padding, and the MRI refers to all ports (i.e. acts as 4657 a wildcard). If the flag is set and Port=0x0000, the MRI will 4658 apply to a specific port, whose value is not yet known. If 4659 neither of A or B is set, the word is absent. 4661 D flag: The Direction flag has the following meaning: the value 0 4662 means 'in the same direction as the flow' (i.e. downstream), and 4663 the value 1 means 'in the opposite direction to the flow' (i.e. 4664 upstream). 4666 A.3.1.2. Loose-End MRM 4668 In the case of the loose-end MRM, the addressing information takes 4669 the following format. The N-flag N=0 for this MRM. 4671 0 1 2 3 4672 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 4673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4674 |IP-Ver |D| Reserved | 4675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4676 // Source Address // 4677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4678 // Destination Address // 4679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4681 IP-Ver (4 bits): The IP version number, 4 or 6. 4683 Source/Destination address (variable): The source and destination 4684 addresses are always present and of the same type; their length 4685 depends on the value in the IP-Ver field. 4687 D flag: The direction flag. Note that for Q-mode messages, the only 4688 valid value is D=0 (see Section 5.8.2). 4690 A.3.2. Session Identification 4692 Type: Session-Identification 4694 Length: Fixed (4 32-bit words) 4696 0 1 2 3 4697 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 4698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4699 | | 4700 + + 4701 | | 4702 + Session ID + 4703 | | 4704 + + 4705 | | 4706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4708 A.3.3. Network-Layer-Information 4709 Type: Network-Layer-Information 4711 Length: Variable (depends on length of Peer-Identity and IP version) 4713 0 1 2 3 4714 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 4715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4716 | PI-Length | IP-TTL |IP-Ver | Reserved | 4717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4718 | Routing State Validity Time | 4719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4720 // Peer Identity // 4721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4722 // Interface Address // 4723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4725 PI-Length (8 bits): The byte length of the Peer Identity field. 4727 Peer Identity (variable): The Peer Identity field. Note that the 4728 Peer-Identity field itself is padded to a whole number of words. 4730 IP-TTL (8 bits): Initial or reported IP layer TTL. 4732 IP-Ver (4 bits): The IP version for the Interface Address field. 4734 Interface Address (variable): The IP address allocated to the 4735 interface, matching the IP-Ver field. 4737 Routing State Validity Time (32 bits): The time for which the 4738 routing state for this flow can be considered correct without a 4739 refresh. Given in milliseconds. 4741 A.3.4. Stack Proposal 4743 Type: Stack-Proposal 4745 Length: Variable (depends on number of profiles and size of each 4746 profile) 4748 0 1 2 3 4749 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 4750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4751 | Prof-Count | Reserved | 4752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4753 // Profile 1 // 4754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4755 : : 4756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4757 // Profile 2 // 4758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4760 Prof-Count (8 bits): The number of profiles listed. MUST be > 0. 4762 Each profile is itself a sequence of protocol layers, and the profile 4763 is formatted as a list as follows: 4765 o The first byte is a count of the number of layers in the profile. 4767 o This is followed by a sequence of 1-byte MA-Protocol-IDs as 4768 described in Section 5.7. 4770 o The profile is padded to a word boundary with 0, 1, 2 or 3 zero 4771 bytes. 4773 If there are no profiles (i.e. all bytes are null), then an "Object 4774 Value Error" message (Appendix A.4.4.10) with subcode 3 ("Empty 4775 List") MUST be returned and the message dropped. 4777 A.3.5. Stack-Configuration-Data 4779 Type: Stack-Configuration-Data 4781 Length: Variable (depends on number of protocols and size of each 4782 MA-protocol-options field) 4784 0 1 2 3 4785 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 4786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4787 | MPO-Count | Reserved | 4788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4789 | MA-Hold-Time | 4790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4791 // MA-protocol-options 1 // 4792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4793 : : 4794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4795 // MA-protocol-options N // 4796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4798 MPO-Count (8 bits): The number of MA-protocol-options fields present 4799 (these contain their own length information). 4801 MA-Hold-Time (32 bits): The time for which the messaging association 4802 will be held open without traffic or a hello message. Given in 4803 milliseconds. 4805 The MA-protocol-options fields are formatted as follows: 4807 0 1 2 3 4808 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 4809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4810 |MA-Protocol-ID | Profile | Length |D| Reserved | 4811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4812 // Options Data // 4813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4815 MA-Protocol-ID (8 bits): Protocol identifier as described in 4816 Section 5.7. 4818 Profile (8 bits): Tag indicating which profile from the accompanying 4819 Stack-Proposal object this applies to. Profiles are numbered from 4820 1 upwards; the special value 0 indicates 'applies to all 4821 profiles'. 4823 Length (8 bits): The byte length of MA-protocol-options field that 4824 follows. This will be zero-padded up to the next word boundary. 4826 D flag: If set (D=1), this protocol MUST NOT be used for a messaging 4827 association. 4829 Options Data (variable): Any options data for this protocol. Note 4830 that the format of the options data may differ depending on 4831 whether the field is in a Query or Response. 4833 A.3.6. Query Cookie 4835 Type: Query-Cookie 4837 Length: Variable (selected by querying node) 4839 0 1 2 3 4840 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 4841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4842 // Query Cookie // 4843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4845 The contents are implementation defined. See Section 8.5 for further 4846 discussion. 4848 A.3.7. Responder Cookie 4850 Type: Responder-Cookie 4852 Length: Variable (selected by responding node) 4854 0 1 2 3 4855 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 4856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4857 // Responder Cookie // 4858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4860 The contents are implementation defined. See Section 8.5 for further 4861 discussion. 4863 A.3.8. NAT Traversal 4865 Type: NAT-Traversal 4867 Length: Variable (depends on length of contained fields) 4869 This object is used to support the NAT traversal mechanisms described 4870 in Section 7.2. 4872 0 1 2 3 4873 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 4874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4875 | MRI-Length | Type-Count | NAT-Count | Reserved | 4876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4877 // Original Message-Routing-Information // 4878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4879 // List of translated objects // 4880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4881 | Length of opaque information | | 4882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 4883 // Information replaced by NAT #1 | 4884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4885 : : 4886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4887 | Length of opaque information | | 4888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 4889 // Information replaced by NAT #N | 4890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4892 MRI-Length (8 bits): The length of the included MRI payload in 32- 4893 bit words. 4895 Original Message-Routing-Information (variable): The MRI data from 4896 when the message was first sent, not including the object header. 4898 Type-Count (8 bits): The number of objects in the 'List of 4899 translated objects' field. 4901 List of translated objects (variable): This field lists the object 4902 types of the objects that were translated by every NAT through 4903 which the message has passed. It is initialised by the first NAT 4904 on the path; subsequent NATs may delete elements in the list. 4905 Padded with 2 null bytes if necessary. 4907 NAT-Count (8 bits): The number of NATs traversed by the message, and 4908 the number of opaque payloads at the end of the object. The 4909 length fields for each opaque payload are byte counts, not 4910 including the 2 bytes of the length field itself. Note that each 4911 opaque information field is zero-padded to the next 32-bit word 4912 boundary if necessary. 4914 A.3.9. NSLP Data 4916 Type: NSLP-Data 4917 Length: Variable (depends on NSLP) 4919 0 1 2 3 4920 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 4921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4922 // NSLP Data // 4923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4925 A.4. Errors 4927 A.4.1. Error Object 4929 Type: Error 4931 Length: Variable (depends on error) 4933 0 1 2 3 4934 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 4935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4936 | Error Class | Error Code | Error Subcode | 4937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4938 |S|M|C|D|Q| Reserved | MRI Length | Info Count | 4939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4940 | | 4941 + Common Header + 4942 | (of original message) | 4943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4944 : Session Id : 4945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4946 : Message Routing Information : 4947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4948 : Additional Information : 4949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4950 : Debugging Comment : 4951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4953 The flags are: 4954 S - S=1 means the Session ID object is present 4955 M - M=1 means MRI object is present 4956 C - C=1 means a debug Comment is present after header. 4957 D - D=1 means the original message was received in D-mode 4958 Q - Q=1 means the original message was received Q-mode encapsulated 4959 (can't be set if D=0). 4961 A GIST Error object contains an 8 bit error-class (see 4962 Appendix A.4.3), a 16 bit error-code, an 8 bit error-subcode, and as 4963 much information about the message which triggered the error as is 4964 available. This information MUST include the Common header of the 4965 original message and MUST also include the Session Id and MRI objects 4966 if these could be decoded correctly. These objects are included in 4967 their entirety, except for their TLV Headers. The MRI Length field 4968 gives the length of the MRI object in 32-bit words. 4970 The Info Count field contains the number of Additional Information 4971 fields in the object, and the possible formats for these fields are 4972 given in Appendix A.4.2. The precise set of fields to include 4973 depends on the error code/subcode. For every error description in 4974 the error catalogue Appendix A.4.4, the line "Additional Info:" 4975 states what fields MUST be included, and in what order if there can 4976 be more than one; if this line is given as 'None' then additional 4977 information MUST NOT be included. The Debugging Comment is a null- 4978 terminated UTF-8 string, padded if necessary to a whole number of 32- 4979 bit words with more null characters. 4981 A.4.2. Additional Information Fields 4983 The Common Error Header may be followed by some Additional 4984 Information objects. The possible formats of these objects are shown 4985 below. 4987 Message Length Info: 4989 0 1 2 3 4990 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 4991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4992 | Calculated Length | Reserved | 4993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4994 Calculated Length (16 bits): the length of the original message 4995 calculated by adding up all the objects in the message. Measured in 4996 32-bit words. 4998 MTU Info: 5000 0 1 2 3 5001 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 5002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5003 | Link MTU | Reserved | 5004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5005 Link MTU (16 bits): the MTU for a link along which a message could 5006 not be sent. 5008 Object Type Info: 5010 0 1 2 3 5011 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 5012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5013 | Object Type | Reserved | 5014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5015 Object type (16 bits): This provides information about the type 5016 of object which caused the error. 5018 Object Value Info: 5020 0 1 2 3 5021 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 5022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5023 | Rsv | Real Object Length | Offset | 5024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5025 // Object // 5026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5027 This object carries information about a TLV object which was found 5028 to be invalid in the original message. An error message may contain 5029 more than one Object Value Info object. 5031 Real Object Length (12 bits) Since the length in the original TLV 5032 header may be inaccurate, this field provides the actual length 5033 of the object (including the TLV Header) included in the error 5034 message. Measured in 32-bit words. 5036 Offset (16 bits): The byte in the object at which the GIST node 5037 found the error. The first byte in the object has offset=0. 5039 Object (variable): The invalid TLV object (including the TLV 5040 Header). 5042 A.4.3. Error Classes 5044 The first byte of the error object, "Error Class", indicates the 5045 severity level. The currently defined severity levels are: 5047 0 (Informational): response data which should not be thought of as 5048 changing the condition of the protocol state machine. 5050 1 (Success): response data which indicates that the message being 5051 responded to has been processed successfully in some sense. 5053 2 (Protocol-Error): the message has been rejected because of a 5054 protocol error (e.g. an error in message format). 5056 3 (Transient-Failure): the message has been rejected because of a 5057 particular local node status which may be transient (i.e. it may 5058 be worthwhile to retry after some delay). 5060 4 (Permanent-Failure): the message has been rejected because of 5061 local node status which will not change without additional out of 5062 band (e.g. management) operations. 5064 Additional error class values are reserved. 5066 The allocation of error classes to particular errors is not precise; 5067 the above descriptions are deliberately informal. Actual error 5068 processing should take into account the specific error in question; 5069 the error class may be useful supporting information (e.g. in network 5070 debugging). 5072 A.4.4. Error Catalogue 5074 This section lists all the possible GIST errors, including when they 5075 are raised and what additional information fields should be carried 5076 in the error object. 5078 A.4.4.1. Common Header Parse Error 5080 Class: Protocol-Error 5081 Code: 1 5082 Additional Info: For subcode 3 only, Message Length Info carries 5083 the calculated message length. 5085 This message is sent if a GIST node receives a message where the 5086 common header cannot be parsed correctly, or where an error in the 5087 overall message format is detected. Note that in this case the 5088 original MRI and Session ID are not included in the Error Object. 5089 This error code is split into subcodes as follows: 5091 0: Unknown Version: The GIST version is unknown. The (highest) 5092 supported version supported by the node can be inferred from the 5093 Common Header of the Error message itself. 5095 1: Unknown Type: The GIST message type is unknown. 5097 2: Invalid R-flag: The R flag in the header is inconsistent with the 5098 message type. 5100 3: Incorrect Message Length: The overall message length is not 5101 consistent with the set of objects carried. 5103 4: Invalid E-flag: The E flag is set in the header but this is not a 5104 Data message. 5106 A.4.4.2. Hop Limit Exceeded 5108 Class: Permanent-Failure 5109 Code: 2 5110 Additional Info: None 5112 This message is sent if a GIST node receives a message with a GIST 5113 hop count of zero, or a GIST node decrements a packet's GIST hop 5114 count to zero on reception. This message indicates either a routing 5115 loop or too small an initial hop count value. 5117 A.4.4.3. Incorrect Encapsulation 5119 Class: Protocol-Error 5120 Code: 3 5121 Additional Info: None 5123 This message is sent if a GIST node receives a message which uses an 5124 incorrect encapsulation method (e.g. a Query arrives over an MA). 5126 A.4.4.4. Incorrectly Delivered Message 5128 Class: Protocol-Error 5129 Code: 4 5130 Additional Info: None 5132 This message is sent if a GIST node receives a message over an MA 5133 which is not associated with the MRI/NSLPID/SID combination in the 5134 message. 5136 A.4.4.5. No Routing State 5138 Class: Protocol-Error 5139 Code: 5 5140 Additional Info: None 5142 This message is sent if a node receives a message for which routing 5143 state should exist, but has not yet been created and thus there is no 5144 appropriate Querying-SM or Responding-SM. This can occur either on 5145 receiving a Response to an unknown Query, or on receiving a Data 5146 message at a node whose policy requires routing state to exist before 5147 such messages can be accepted. See also Section 6.1 and Section 6.3. 5149 A.4.4.6. Unknown NSLPID 5151 Class: Permanent-Failure 5152 Code: 6 5153 Additional Info: None 5155 This message is sent if a router receives a directly addressed 5156 message for an NSLP which it does not support. 5158 A.4.4.7. Endpoint Found 5160 Class: Informational 5161 Code: 7 5162 Additional Info: None 5164 This message is sent if a GIST node at a flow endpoint receives a 5165 Query message for an NSLP which it does not support. 5167 A.4.4.8. Message Too Large 5169 Class: Permanent-Failure 5170 Code: 8 5171 Additional Info: MTU Info 5173 A router receives a message which it can't forward because it exceeds 5174 the MTU on the next or subsequent hops. 5176 A.4.4.9. Object Type Error 5178 Class: Protocol-Error 5179 Code: 9 5180 Additional Info: Object Type Info 5182 This message is sent if a GIST node receives a message containing a 5183 TLV object with an invalid type. The message includes the object at 5184 fault. This error code is split into subcodes as follows: 5186 0: Duplicate Object: This subcode is used if a GIST node receives a 5187 message containing multiple instances of an object which may only 5188 appear once in a message. In the current specification, this 5189 applies to all objects. 5191 1: Unrecognised Object: This subcode is used if a GIST node receives 5192 a message containing an object which it does not support, and the 5193 extensibility flags AB=00. 5195 2: Missing Object: This subcode is used if a GIST node receives a 5196 message which is missing one or more mandatory objects. This 5197 message is also sent if a Stack-Proposal is sent without a 5198 matching Stack-Configuration-Data object when one was necessary, 5199 or vice versa. 5201 3: Invalid Object Type: This subcode is used if the object type is 5202 known, but it is not valid for this particular GIST message type. 5204 4: Untranslated Object: This subcode is used if the object type is 5205 known and is mandatory to interpret, but it contains addressing 5206 data which has not been translated by an intervening NAT. 5208 5: Invalid Extensibility Flags: This subcode is used if an object is 5209 received with the extensibility flags AB=11. 5211 A.4.4.10. Object Value Error 5213 Class: Protocol-Error 5214 Code: 10 5215 Additional Info: 1 or 2 Object Value Info fields as given below 5217 This message is sent if a router receives a packet containing an 5218 object which cannot be properly parsed. The message contains a 5219 single Object Value Info object, except for subcode 5 as stated 5220 below. This error code is split into subcodes as follows: 5222 0: Incorrect Length: The overall length does not match the object 5223 length calculated from the object contents. 5225 1: Value Not Supported: The value of a field is not supported by the 5226 GIST node. 5228 2: Invalid Flag-Field Combination: An object contains an invalid 5229 combination of flags and/or fields. At the moment this only 5230 relates to the Path-Coupled MRM object, but in future there may be 5231 more. 5233 3: Empty List: At the moment this only relates to Stack-Proposals. 5234 The error message is sent if a stack proposal with a length > 0 (a 5235 length of 0 is handled as "Value Not Supported") contains only 5236 null bytes. 5238 4: Invalid Cookie: The message contains a cookie which could not be 5239 verified by the node. 5241 5: Stack-Proposal - Stack-Configuration-Data Mismatch: This subcode 5242 is used if a GIST node receives a message in which the data in the 5243 Stack-Proposal object is inconsistent with the information in the 5244 Stack Configuration Data object. In this case, both the Stack- 5245 Proposal object and Stack-Configuration-Data object MUST be 5246 included in separate Object Value Info fields in that order. 5248 A.4.4.11. Invalid IP layer TTL 5250 Class: Permanent-Failure 5251 Code: 11 5252 Additional Info: None 5254 This error indicates that a message was received with an IP layer TTL 5255 outside an acceptable range; for example, that an upstream Query was 5256 received with an IP layer TTL of less than 254 (i.e. more than one IP 5257 hop from the sender). The actual IP distance can be derived from the 5258 IP-TTL information in the NLI object carried in the same message. 5260 A.4.4.12. MRI Validation Failure 5262 Class: Permanent-Failure 5263 Code: 12 5264 Additional Info: Object Value Info 5266 This error indicates that a message was received with an MRI that 5267 could not be accepted, e.g. because of too much wildcarding or 5268 failing some validation check (cf. Section 5.8.1.2). The Object 5269 Value Info includes the MRI so the error originator can indicate the 5270 part of the MRI which caused the problem. The error code is divided 5271 into subcodes as follows: 5273 0: MRI Too Wild: The MRI contained too much wildcarding (e.g. too 5274 short a destination address prefix) to be forwarded correctly down 5275 a single path. 5277 1: IP Version Mismatch: The MRI in a path-coupled Query message uses 5278 an IP version which is not implemented on the interface used. 5280 2: Ingress Filter Failure: The MRI in a path-coupled Query message 5281 describes a flow which would not pass ingress filtering on the 5282 interface used. 5284 Appendix B. API between GIST and Signaling Applications 5286 This appendix provides an abstract API between GIST and signaling 5287 applications. It should not constrain implementors, but rather help 5288 clarify the interface between the different layers of the NSIS 5289 protocol suite. In addition, although some of the data types carry 5290 the information from GIST information elements, this does not imply 5291 that the format of that data as sent over the API has to be the same. 5293 Conceptually the API has similarities to the sockets API, 5294 particularly that for unconnected UDP sockets. An extension for an 5295 API like that for UDP connected sockets could be considered. In this 5296 case, for example, the only information needed in a SendMessage 5297 primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle 5298 (which can be null). Other information which was persistent for a 5299 group of messages could be configured once for the socket. Such 5300 extensions may make a concrete implementation more efficient but do 5301 not change the API semantics, and so are not considered further here. 5303 B.1. SendMessage 5305 This primitive is passed from a signaling application to GIST. It is 5306 used whenever the signaling application wants to initiate sending a 5307 message. 5309 SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, 5310 NSLPID, Session-ID, MRI, SII-Handle, 5311 Transfer-Attributes, Timeout, IP-TTL, GIST-Hop-Count ) 5313 The following arguments are mandatory. 5315 NSLP-Data: The NSLP message itself. 5317 NSLP-Data-Size: The length of NSLP-Data. 5319 NSLP-Message-Handle: A handle for this message, that can be used by 5320 GIST as a reference in subsequent MessageStatus notifications 5321 (Appendix B.3). Notifications could be about error conditions or 5322 about the security attributes that will be used for the message. 5323 A NULL handle may be supplied if the NSLP is not interested in 5324 such notifications. 5326 NSLPID: An identifier indicating which NSLP this is. 5328 Session-ID: The NSIS session identifier. Note that it is assumed 5329 that the signaling application provides this to GIST rather than 5330 GIST providing a value itself. 5332 MRI: Message routing information for use by GIST in determining the 5333 correct next GIST hop for this message. The MRI implies the 5334 message routing method to be used and the message direction. 5336 The following arguments are optional: 5338 SII-Handle: A handle, previously supplied by GIST, to a data 5339 structure that should be used to route the message explicitly to a 5340 particular GIST next hop. 5342 Transfer-Attributes: Attributes defining how the message should be 5343 handled (see Section 4.1.2). The following attributes can be 5344 considered: 5346 Reliability: Values 'unreliable' or 'reliable'. 5348 Security: This attribute allows the NSLP to specify what level of 5349 security protection is requested for the message (selected from 5350 'integrity' and 'confidentiality'), and can also be used to 5351 specify what authenticated signaling source and destination 5352 identities should be used to send the message. The 5353 possibilities can be learned by the signaling application from 5354 prior MessageStatus or RecvMessage notifications. If an NSLP- 5355 Message-Handle is provided, GIST will inform the signaling 5356 application of what values it has actually chosen for this 5357 attribute via a MessageStatus callback. This might take place 5358 either synchronously (where GIST is selecting from available 5359 messaging associations), or asynchronously (when a new 5360 messaging association needs to be created). 5362 Local Processing: This attribute contains hints from the 5363 signaling application about what local policy should be applied 5364 to the message; in particular, its transmission priority 5365 relative to other messages, or whether GIST should attempt to 5366 set up or maintain forward routing state. 5368 Timeout: Length of time GIST should attempt to send this message 5369 before indicating an error. 5371 IP-TTL: The value of the IP layer TTL that should be used when 5372 sending this message (may be overridden by GIST for particular 5373 messages). 5375 GIST-Hop-Count: The value for the hop count when sending the 5376 message. 5378 B.2. RecvMessage 5380 This primitive is passed from GIST to a signaling application. It is 5381 used whenever GIST receives a message from the network, including the 5382 case of null messages (zero length NSLP payload), typically initial 5383 Query messages. For Queries, the results of invoking this primitive 5384 are used by GIST to check whether message routing state should be 5385 created (see the discussion of the 'Routing-State-Check' argument 5386 below). 5388 RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLPID, Session-ID, MRI, 5389 Routing-State-Check, SII-Handle, Transfer-Attributes, 5390 IP-TTL, IP-Distance, GIST-Hop-Count, 5391 Inbound-Interface ) 5393 NSLP-Data: The NSLP message itself (may be empty). 5395 NSLP-Data-Size: The length of NSLP-Data (may be zero). 5397 NSLPID: An identifier indicating which NSLP this is message is for. 5399 Session-ID: The NSIS session identifier. 5401 MRI: Message routing information that was used by GIST in forwarding 5402 this message. Implicitly defines the message routing method that 5403 was used and the direction of the message relative to the MRI. 5405 Routing-State-Check: This boolean is True if GIST is checking with 5406 the signaling application to see if routing state should be 5407 created with the peer or the message should be forwarded further 5408 (see Section 4.3.2). If True, the signaling application should 5409 return the following values via the RecvMessage call: 5411 A boolean indicating whether to set up the state. 5413 Optionally, an NSLP-Payload to carry in the generated Response 5414 or forwarded Query respectively. 5416 This mechanism could be extended to enable the signaling 5417 application to indicate to GIST whether state installation should 5418 be immediate or deferred (see Section 5.3.3 and Section 6.3 for 5419 further discussion). 5421 SII-Handle: A handle to a data structure, identifying a peer address 5422 and interface. Can be used to identify route changes and for 5423 explicit routing to a particular GIST next hop. 5425 Transfer-Attributes: The reliability and security attributes that 5426 were associated with the reception of this particular message. As 5427 well as the attributes associated with SendMessage, GIST may 5428 indicate the level of verification of the addresses in the MRI. 5429 Three attributes can be indicated: 5431 * Whether the signaling source address is one of the flow 5432 endpoints (i.e. whether this is the first or last GIST hop); 5434 * Whether the signaling source address has been validated by a 5435 return routability check. 5437 * Whether the message was explicitly routed (and so has not been 5438 validated by GIST as delivered consistently with local routing 5439 state). 5441 IP-TTL: The value of the IP layer TTL this message was received with 5442 (if available). 5444 IP-Distance: The number of IP hops from the peer signaling node 5445 which sent this message along the path, or 0 if this information 5446 is not available. 5448 GIST-Hop-Count: The value of the hop count the message was received 5449 with, after being decremented in the GIST receive-side processing. 5451 Inbound-Interface: Attributes of the interface on which the message 5452 was received, such as whether it lies on the internal or external 5453 side of a NAT. These attributes have only local significance and 5454 are implementation defined. 5456 B.3. MessageStatus 5458 This primitive is passed from GIST to a signaling application. It is 5459 used to notify the signaling application that a message that it 5460 requested to be sent could not be dispatched, or to inform the 5461 signaling application about the transfer attributes that have been 5462 selected for the message (specifically, security attributes). The 5463 signaling application can respond to this message with a return code 5464 to abort the sending of the message if the attributes are not 5465 acceptable. 5467 MessageStatus (NSLP-Message-Handle, Transfer-Attributes, Error-Type) 5468 NSLP-Message-Handle: A handle for the message provided by the 5469 signaling application in SendMessage. 5471 Transfer-Attributes: The reliability and security attributes that 5472 will be used to transmit this particular message. 5474 Error-Type: Indicates the type of error that occurred. For example, 5475 'no next node found'. 5477 B.4. NetworkNotification 5479 This primitive is passed from GIST to a signaling application. It 5480 indicates that a network event of possible interest to the signaling 5481 application occurred. 5483 NetworkNotification ( NSLPID, MRI, Network-Notification-Type ) 5485 NSLPID: An identifier indicating which NSLP this is message is for. 5487 MRI: Provides the message routing information to which the network 5488 notification applies. 5490 Network-Notification-Type: Indicates the type of event that caused 5491 the notification and associated additional data. Two events have 5492 been identified: 5494 Last Node: GIST has detected that this is the last NSLP-aware 5495 node in the path. See Section 4.3.4. 5497 Routing Status Change: GIST has installed new routing state, or 5498 has detected that the routing state may no longer be valid, or 5499 has re-established the routing state. See Section 7.1.3. The 5500 new status is reported; if the status is Good, the SII-Handle 5501 of the peer is also reported, as for RecvMessage. 5503 B.5. SetStateLifetime 5505 This primitive is passed from a signaling application to GIST. It 5506 indicates the duration for which the signaling application would like 5507 GIST to retain its routing state. It can also give a hint that the 5508 signaling application is no longer interested in the state. 5510 SetStateLifetime ( NSLPID, MRI, State-Lifetime ) 5511 NSLPID: Provides the NSLPID to which the routing state lifetime 5512 applies. 5514 MRI: Provides the message routing information to which the routing 5515 state lifetime applies; includes the direction (in the D flag). 5517 State-Lifetime: Indicates the lifetime for which the signaling 5518 application wishes GIST to retain its routing state (may be zero, 5519 indicating that the signaling application has no further interest 5520 in the GIST state). 5522 B.6. InvalidateRoutingState 5524 This primitive is passed from a signaling application to GIST. It 5525 indicates that the signaling application has knowledge that the next 5526 signaling hop known to GIST may no longer be valid, either because of 5527 changes in the network routing or the processing capabilities of 5528 signaling application nodes. See Section 7.1. 5530 InvalidateRoutingState ( NSLPID, MRI, Status, Urgent ) 5532 NSLPID: The NSLP originating the message. May be null (in which 5533 case the invalidation applies to all signaling applications). 5535 MRI: The flow for which routing state should be invalidated; 5536 includes the direction of the change (in the D flag). 5538 Status: The new status that should be assumed for the routing state, 5539 one of Bad or Tentative (see Section 7.1.3). 5541 Urgent: A hint as to whether rediscovery should take place 5542 immediately, or only with the next signaling message. 5544 Appendix C. Example Routing State Table and Handshake Message Sequence 5546 Figure 10 shows a signaling scenario for a single flow being managed 5547 by two signaling applications using the path-coupled message routing 5548 method. The flow sender and receiver and one router support both, 5549 two other routers support one each. The figure also shows the 5550 routing state table at node B. 5552 A B C D E 5553 +------+ +-----+ +-----+ +-----+ +--------+ 5554 | Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow | 5555 |Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver| 5556 | | +-+ +-+ |GIST | |GIST | |GIST | | | 5557 +------+ +-----+ +-----+ +-----+ +--------+ 5558 Flow Direction ------------------------------>> 5560 +------------------------------------+---------+--------+-----------+ 5561 | Message Routing Information | Session | NSLPID | Routing | 5562 | | ID | | State | 5563 +------------------------------------+---------+--------+-----------+ 5564 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | IP-A | 5565 | {IP-A, IP-E, proto/ports}; D=up | | | | 5566 | | | | | 5567 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | (null) | 5568 | {IP-A, IP-E, proto/ports}; D=down | | | | 5569 | | | | | 5570 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | IP-A | 5571 | {IP-A, IP-E, proto/ports}; D=up | | | | 5572 | | | | | 5573 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | Points to | 5574 | {IP-A, IP-E, proto/ports}; D=down | | | B-D MA | 5575 +------------------------------------+---------+--------+-----------+ 5577 Figure 10: A Signaling Scenario 5579 The upstream state is just the same address for each application. 5580 For the downstream direction, NSLP1 only requires D-mode messages and 5581 so no explicit routing state towards C is needed. NSLP2 requires a 5582 messaging association for its messages towards node D, and node C 5583 does not process NSLP2 at all, so the peer state for NSLP2 is a 5584 pointer to a messaging association that runs directly from B to D. 5585 Note that E is not visible in the state table (except implicitly in 5586 the address in the message routing information); routing state is 5587 stored only for adjacent peers. (In addition to the peer 5588 identification, IP hop counts are stored for each peer where the 5589 state itself if not null; this is not shown in the table.) 5591 Figure 11 shows a GIST handshake setting up a messaging association 5592 for B-D signaling, with the exchange of Stack Proposals and MA- 5593 protocol-options in each direction. The Querying node selects TLS/ 5594 TCP as the stack configuration and sets up the messaging association 5595 over which it sends the Confirm. 5597 -------------------------- Query ----------------------------> 5598 IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST) 5599 GIST(Header(Type=Query; NSLPID=NSLP2; R=1; S=0) 5600 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 5601 SessionID(0x1234) 5602 NLI(Peer='string1'; IA=IP#B) 5603 QueryCookie(0x139471239471923526) 5604 StackProposal(#Proposals=3;1=TLS/TCP; 2=TLS/SCTP; 3=TCP) 5605 StackConfigurationData(HoldTime=300; #MPO=2; 5606 TCP(Applicable: all; Data: null) 5607 SCTP(Applicable: all; Data: null))) 5609 <---------------------- Response ---------------------------- 5610 IP(Src=IP#D; Dst=IP#B); UDP(Src=GIST; Dst=6789) 5611 GIST(Header(Type=Response; NSLPID=NSLP2; R=1; S=1) 5612 MRI(MRM=Path-Coupled; Flow=F; Direction=up) 5613 SessionID(0x1234) 5614 NLI(Peer='stringr2', IA=IP#D) 5615 QueryCookie(0x139471239471923526) 5616 ResponderCookie(0xacdefedcdfaeeeded) 5617 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP) 5618 StackConfigurationData(HoldTime=200; #MPO=3; 5619 TCP(Applicable: 3; Data: port=6123) 5620 TCP(Applicable: 1; Data: port=5438) 5621 SCTP(Applicable: all; Data: port=3333))) 5623 -------------------------TCP SYN-----------------------> 5624 <----------------------TCP SYN/ACK---------------------- 5625 -------------------------TCP ACK-----------------------> 5626 TCP connect(IP Src=IP#B; IP Dst=IP#D; Src Port=9166; Dst Port=6123) 5627 <-----------------------TLS INIT-----------------------> 5629 ------------------------ Confirm ----------------------------> 5630 [Sent within messaging association] 5631 GIST(Header(Type=Confirm; NSLPID=NSLP2; R=0; S=1) 5632 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 5633 SessionID(0x1234) 5634 NLI(Peer='string1'; IA=IP#B) 5635 ResponderCookie(0xacdefedcdfaeeeded) 5636 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP) 5637 StackConfigurationData(HoldTime=300)) 5639 Figure 11: GIST Handshake Message Sequence 5641 Appendix D. Change History 5643 D.1. Changes In Version -11 5645 1. Added some text in Section 1 to clarify the scope of GIST 5646 applicability with non-path-coupled message routing methods. 5648 2. Loosened the text about the Query encapsulation to indicate that 5649 a Router Alert Option is needed for all the current message 5650 routing methods but not necessarily for future ones. 5652 3. Clarified the rules for deriving protocol encapsulation 5653 addresses for the Response and other messages in Section 4.4.1 5654 and Section 5.3.1. 5656 4. Updated the ABNF and message descriptions in Section 3.4 to 5657 cover the case of NAT traversal for stateless data messages; 5658 also minor changes in Section 7.2. 5660 5. Re-corrected the timeout processing rules in Section 6.4 (update 5661 in version 10 changed rule 3 but should have changed rule 4). 5662 In addition, the rule 3 processing is made conditional on the 5663 state (i.e. split) since different timers are running in the two 5664 states. 5666 6. Clarified that the E flag can only be set on Data messages, and 5667 added notes to the flag description in Section 7.1.4 and the 5668 format description in Appendix A.1. Also, included a new error 5669 condition to cover incorrect setting in Appendix A.4.4.1. 5671 7. Clarified the text in Section 8.4 to note the issues about 5672 Response size contributing to reflection attacks, and also the 5673 defence against various forms of message spoofing in 5674 Section 8.5. 5676 8. Stated that MA-Protocol-ID value 0 is reserved (not allocated) 5677 in Section 9. 5679 9. Clarified the units (bytes, 32-bit words) for all length fields 5680 in Appendix A. 5682 10. Clarified that the restriction on the D flag value for the 5683 loose-end MRM applies only to Q-mode messages in 5684 Appendix A.3.1.2. 5686 11. Added the Hold Time to the example in Appendix C. 5688 D.2. Changes In Version -10 5690 1. Added further guidance on parameter setting for initial backoff 5691 and rate control for D-mode to Section 5.3.3 [AD review comment 5692 M1]. 5694 2. Rephrased the end of Section 8.6 to highlight the threat left 5695 open when the Querying node does not apply a strong security 5696 policy to offered Stack-Proposal [AD review comment M2]. 5698 3. Clarified in Section 7.2 that although NAT behaviour is only 5699 informatively described in this specification, it is being 5700 defined in a separate document [AD review M3]. 5702 4. Strengthened and clarified the reference to the extensibility 5703 document for technical guidance on codepoint allocation, and 5704 made the reference normative. Added rationale for the 5705 'Reserved' blocks in the various registries, and added further 5706 notes on what information must be provided to support an 5707 allocation request [AD review comment M4]. 5709 5. Fixed an identifier collision in the ABNF for the GIST messages 5710 in Section 5.2.2 (Common-Header in the message header and 5711 common-header as a payload in error messages) and re-verified 5712 the ABNF [AD review comment L1]. 5714 6. Clarified the text in Section 3.3 about the impact on NATs of 5715 defining a new MRM, referring to the specification split 5716 described in Section 7.2.2. Also added a flag to the MRM format 5717 (Appendix A.3.1) to denote MRIs which do not contain network or 5718 transport addresses, and made more specific the error message to 5719 be returned if a NAT does not understand an MRM in Section 7.2.1 5720 [AD review comment L2]. 5722 7. Added discussion in Section 4.1.2 on delivery failure detected 5723 for reliable messaging in general, and for the case of Forwards- 5724 TCP in particular in Section 5.7.2. Also noted that this needs 5725 to be considered for future MA-Protocol-IDs used for reliable 5726 messaging (Section 9) [AD review comment L3]. 5728 8. Added clarifying text to Section 5.1 on what it means to invert 5729 the direction of an MRI [AD review comment L5]. 5731 9. Enhanced the format descriptions in Appendix A to include 5732 descriptions of all message and object fields and also field 5733 lengths [AD review comment L6]. 5735 10. Added more explanation in Section 5.2.2 of how a message 5736 direction is defined, in particular in the context of TTL 5737 measurement [AD review comment L7]. 5739 11. Added a new explanation of why a well-known port is needed for 5740 the query encapsulation in Section 5.3.2 [AD review comment L8]. 5742 12. Added a note that DCCP does not provide reliability in 5743 Section 5.4.1 [AD review comment L9]. 5745 13. Clarified the rules on how long to retain stack configuration 5746 data in Section 5.7.1 and included a default timer value [AD 5747 review comment L10]. 5749 14. Modified the text about stack-proposal verification as part of 5750 downgrade protection in Section 5.7.1, to clarify that the MUST 5751 applies directly to the object verification itself; also noted 5752 the action to be taken in case of a failed verification [AD 5753 review comment L11]. 5755 15. Added further information on the addressing used in opening a 5756 forwards-TCP connection in Section 5.7.2 [AD review comment 5757 L12]. 5759 16. Modified the text in Section 5.8.1.2 to say that using the 5760 signaling source address is a consequence of setting DF itself 5761 rather than why DF was set in the first place; also weakened the 5762 instruction from MUST to SHOULD [AD review comment L14]. 5764 17. Added further clarification of why routing state installed by a 5765 downstream Query should supersede that from an upstream Query in 5766 Section 5.8.1.3 [AD review comment L15]. 5768 18. Corrected a timer in the Messaging Association state machine 5769 (Section 6.4) from NoHello to SendHello. Also, added default 5770 values for MA-Hold-Time and route change probe frequency, and 5771 explanatory text for each, to Section 4.4.3 [AD review comment 5772 L16]. 5774 19. Re-arranged the text in Section 7.2 to highlight the rules about 5775 precisely which messages are and are not translated in a GIST- 5776 specific way by NATs [AD review comment L19]. 5778 20. Explicitly noted that 'r' bits are also reserved in Appendix A.2 5779 [AD review comment L20]. 5781 21. Added an error condition for processing messages which have the 5782 extensibility flags AB set to 11 in Appendix A.2.1 [AD review 5783 comment L21]. 5785 22. Fixed the table of MRM identifiers in Section 9 so the field 5786 name matches that in Appendix A.3.1 [AD review comment L22]. 5788 23. Clarified why only D=0 is valid for the loose-end MRM in 5789 Appendix A.3.1.2 [AD review comment L23]. 5791 24. Clarified the rules about processing the NAT traversal object in 5792 Appendix A.3.8 to cover the case where there are several NATs 5793 along the path with different capabilities [AD review comment 5794 L24]. 5796 25. Strengthened the text in Appendix A.4.1 to be clearer about what 5797 additional information fields must be included in error messages 5798 [AD review comment L25]. 5800 26. Tidied up the use of acronyms throughout the document, including 5801 adding some to the terminology list in Section 2 [AD review 5802 comment N1]. 5804 27. Added references to RFC4086 and updated 2119 language for 5805 cryptographic randomness of SIDs and cookies in Section 3.5 and 5806 Section 8.5 respectively [AD review comment N2]. 5808 28. Modified the transition labelling in Figure 7 to make it clearer 5809 that in the Established-Established transition, the 5810 [!confirmRequired] qualification applies only to the rx_Query 5811 case [AD review comment N4]. 5813 29. Added a reference for OSPF in Section 7.1.2 [AD review comment 5814 N5]. 5816 30. Changed NAT terminology from public/private to external/internal 5817 to match BEHAVE usage in Section 7.2 and Section 7.4 [AD review 5818 comment N6]. 5820 31. Updated a number of i-d references to published RFCs or working 5821 group documents [AD review comment N7 partial]. 5823 32. Fixed rfc2119 capitalisation of MUST not in Appendix A.3.5 [AD 5824 review comment N8]. 5826 33. Fixed an error subcode name from 'Invalid Object' to 'Invalid 5827 Object Type' in Appendix A.4.4.9 [AD review comment N9]. 5829 34. Added the NTO to the GIST message ABNF in Section 5.1 and 5830 updated the forward reference to the NAT traversal section 5832 [tracker issue 104]. 5834 35. Removed a spurious rule about creating listening MAs in 5835 Section 6.3 and strengthened the rules about needing to have 5836 these available but with an open policy on when to create and 5837 destroy them in Section 5.7.1 [tracker issue 105]. 5839 36. Added text that limits the applicability of the private/ 5840 experimental space to closed network environments [tracker issue 5841 106]. 5843 37. Added text in Section 7.1.4 encouraging GIST to use a single SII 5844 across multiple sessions if possible to allow signaling 5845 application aggregation [tracker issue 107]. 5847 38. Specified that this document would define GIST version 1 in 5848 Section 5.2.1 [tracker issue 108]. 5850 39. Added the ability for RecvMessage to pass up interface 5851 attributes in Appendix B.2 [tracker issue 110]. 5853 40. Added additional text on rules for selecting stack proposals and 5854 MA re-use in Section 5.7.1 to ensure that re-used associations 5855 have properties that the Querying node actually needs [tracker 5856 issue 111]. 5858 41. Added a brief introduction to the GIST message types in a new 5859 Section 3.4. 5861 In addition, the following AD review comments did not lead to text 5862 changes. See the mailing list discussion at 5863 http://www1.ietf.org/mail-archive/web/nsis/current/msg06307.html. 5865 L4: Direct use of PMTUD by GIST. 5867 L13: Use of TLS 1.0 rather than 1.1. 5869 L17: Guidance on NSLP behaviour during rerouting, 5871 L18: Behaviour of GIST-unaware NATs. 5873 N3: Node state machine logic. 5875 D.3. Changes In Version -09 5877 1. Added a new Section 3.6 clarifying the relationship between 5878 signaling applications and NSLPIDs; modified terminology in the 5879 remainder of the document likewise. 5881 2. Added a new Section 8.6 explaining the rationale behind the 5882 downgrade attack prevention mechanism. 5884 3. Re-wrote parts of Section 4.3.2, Section 6.1 and Appendix B.2 to 5885 clarify the way that GIST is assumed to interact with signaling 5886 applications to exercise policy control over whether or not two 5887 nodes become signaling peers during a GIST handshake. 5889 4. Generalised an error message Appendix A.4.4.12 to cover 5890 additional MRI validation checks in Section 4.3.4 and 5891 Section 5.8.1.2. 5893 5. Allowed an optional Stack-Configuration-Data object in Confirm 5894 messages to allow messaging association lifetime to be 5895 negotiated even in the case of late state installation at the 5896 Responding node (see Section 4.4.1 and Section 4.4.3). 5898 6. Removed the option in Section 4.4.2 of allowing a node to treat 5899 messaging associations with the same authenticated end points as 5900 equivalent. 5902 7. Include additional guidance in Section 4.4.3 to prevent routing 5903 state being erroneously refreshed in the case of rerouting 5904 events; also included general guidance notes on timer setting. 5906 8. Clarified that the Stack-Proposal lists protocols in top-to- 5907 bottom order (see Section 5.7.1). 5909 9. Enhanced the definition of TLS usage in Section 5.7.3 with 5910 details on ciphersuite requirements and authentication methods. 5912 10. Tidied up terminology and discussion of how protocol options 5913 data is carried in the SCD; renamed higher-layer-addressing to 5914 MA-protocol-options. 5916 D.4. Changes In Version -08 5918 1. Changed the protocol name from GIMPS to GIST (everywhere). 5920 2. Inserted RFC2119 language (MUST etc.) in the appropriate places. 5922 3. Added references to the actions to be taken in various error 5923 conditions, including the error messages to be send 5924 (throughout). 5926 4. Added legacy NAT traversal to the list of excluded functions in 5927 Section 1.1. 5929 5. Included some text at the end of Section 3.3 analysing the case 5930 of a GIST node which does not support a particular MRM. 5932 6. Added a flag to mark when messages have been explicitly routed, 5933 so they can bypass validation against current routing state (see 5934 Section 4.3.1, TBD). 5936 7. Re-wrote the discussion in Section 4.3.4 to cover all cases of 5937 nodes not hosting an NSLP (including end systems), in particular 5938 the validations that can be performed at intermediate GIST nodes 5939 (this replaces the old section 7.2). 5941 8. Clarified the rules about R and S flag setting in the common 5942 header and D flag in the MRI (Section 5). 5944 9. Included discussion of how a node with a choice of interfaces or 5945 IP versions should select one to use in the NLI (Section 5.2.2). 5947 10. Modified the description of messaging association protocol 5948 selections (Section 5.7 and elsewhere) to clarify that this is 5949 essentially capability discovery rather than an open ended 5950 protocol negotiation. 5952 11. Modified the description of how higher layer addressing 5953 information is carried (Section 5.7.1 and Appendix A.3.5) to 5954 allow the data to be tagged against a specific profile if 5955 necessary, or omitted if the protocol does not need it. 5957 12. Added a higher layer protocol definition for TLS in 5958 Section 5.7.3. 5960 13. Simplified and restructured the state machine presentation in 5961 Section 6, in particular using a single list for the events and 5962 eliminating the transition tables. Also modified the operation 5963 of the Responder machine to handle retransmitted Query messages 5964 correctly. 5966 14. Re-wrote the route change handling text in Section 7.1 to 5967 clarify the relative responsibilities of GIST and NSLPs and 5968 their interaction through the API. Notifications are now 5969 assumed to be a signaling application responsibility, and GIST 5970 behaviour is defined in terms of handling changes in a 3-state 5971 model of the correctness of the routing state for each 5972 direction. 5974 15. Updated the NAT traversal description in Section 7.2, including 5975 normative text about how GIST nodes should handle messages 5976 containing NAT-Traversal objects. 5978 16. Likewise, clarified that the responsibility for session/flow 5979 binding in the case of tunnelling is handled by NSLPs 5980 (Section 7.3). 5982 17. Formalised the IANA considerations (Section 9). 5984 18. Extended the routing state example (Appendix C) to include a 5985 message sequence for association setup. 5987 19. Re-arranged the sequence of sections, including placing this 5988 change history at the end. 5990 D.5. Changes In Version -07 5992 1. The open issues section has finally been removed in favour of the 5993 authoritative list of open issues in an online issue tracker at h 5994 ttp://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index. 5996 2. Clarified terminology on peering and adjacencies that there may 5997 be NSIS nodes between GIMPS peers that do some message 5998 processing, but that are not explicitly visible in the peer state 5999 tables. 6001 3. Added a description of the loose-end MRM (Section 5.8.2 and 6002 Appendix A.3.1.2). 6004 4. Added a description of an upstream Query encapsulation for the 6005 path-coupled MRM, Section 5.8.1.3, including rationale for and 6006 restrictions on its use. 6008 5. The formal description of the protocol in Section 6 has been 6009 significantly updated and extended in terms of detail. 6011 6. Modified the description of the interaction between NSLPs and 6012 GIMPS for handling inbound messages for which no routing state 6013 exists, to allow the NSLP to indicate whether state setup should 6014 proceed and to provide NSLP payloads for the Response or 6015 forwarded message (Section 3.7, Section 4.3.2 and Appendix B). 6017 7. Included new text, Section 5.6, on the processing and 6018 encapsulation of error messages. Also added formats and an error 6019 message catalogue in Appendix A.4, including a modified format 6020 for the overall GIMPS-Error message and the GIMPS-Error-Data 6021 object. 6023 8. Removed the old section 5.3.3 on NSLPID/RAO setting on the 6024 assumption that this will be covered in the extensibility 6025 document. 6027 9. Included a number of other minor corrections and clarifications. 6029 D.6. Changes In Version -06 6031 Version -06 does not introduce any major structural changes to the 6032 protocol definition, although it does clarify a number of details and 6033 resolve some outstanding open issues. The primary changes are as 6034 follows: 6036 1. Added a new high level Section 3.3 which gathers together the 6037 various aspects of the message routing method concept. 6039 2. Added a new high level Section 3.5 which explains the concept 6040 and significance of the session identifier. Also clarified that 6041 the routing state always depends on the session identifier. 6043 3. Added notes about the level of address validation performed by 6044 GIMPS in Section 4.1.2 and extensions to the API in Appendix B. 6046 4. Split the old Node-Addressing object into a Network-Layer- 6047 Information object and Stack-Configuration-Data object. The 6048 former refers to basic information about a node, and the latter 6049 carries information about messaging association configuration. 6050 Redefined the content of the various handshake messages 6051 accordingly in Section 4.4.1 and Section 5.1. 6053 5. Re-wrote Section 4.4.3 to clarify the rules on refresh and purge 6054 of routing state and messaging associations. Also, moved the 6055 routing state lifetime into the Network-Layer-Information object 6056 and added a messaging association lifetime to the Stack- 6057 Configuration-Data object (Section 5.2). 6059 6. Added specific message types for errors and MA-Refresh in 6060 Section 5.1. The error object is now GIMPS-specific 6061 (Appendix A.4.1). 6063 7. Moved the Flow-Identifier information about the message routing 6064 method from the general description of the object to the path- 6065 coupled MRM section (Section 5.8.1.1), and made a number of 6066 clarifications to the bit format (Appendix A.3.1.1). 6068 8. Removed text about assumptions on the version numbering of 6069 NSLPs, and restricted the scope of the description of TLV object 6070 formats and extensibility flags to GIMPS rather than the whole 6071 of NSIS (Appendix A). 6073 9. Added a new Section 5.5 explaining the possible relationships 6074 between message types and encapsulation formats. 6076 10. Added a new Section 6 in outline form, to capture the formal 6077 specification of the protocol operation. 6079 11. Added new security sections on cookie requirements (Section 8.5) 6080 and residual threats (Section 8.7). 6082 D.7. Changes In Version -05 6084 Version -05 reformulates the specification, to describe routing state 6085 maintenance in terms of exchanging explicitly identified Query/ 6086 Response/Confirm messages, leaving the upstream/downstream 6087 distinction as a specific detail of how Query messages are 6088 encapsulated. This necessitated widespread changes in the 6089 specification text, especially Section 4.2.1, Section 4.4, 6090 Section 5.1 and Section 5.3 (although the actual message sequences 6091 are unchanged). A number of other issues, especially in the area of 6092 message encapsulation, have also been closed. The main changes are 6093 the following: 6095 1. Added a reference to an individual draft on the Loose End MRM as 6096 a concrete example of an alternative message routing method. 6098 2. Added further text (particularly in Section 2) on what GIMPS 6099 means by the concept of 'session'. 6101 3. Firmed up the selection of UDP as the encapsulation choice for 6102 D-mode, removing the open issue on this topic. 6104 4. Defined the interaction between GIMPS and signaling applications 6105 for communicating about the cryptographic security properties of 6106 how a message will be sent or has been received (see 6107 Section 4.1.2 and Appendix B). 6109 5. Closed the issue on whether Query messages should use the 6110 signaling or flow source address in the IP header; both options 6111 are allowed by local policy and a flag in the common header 6112 indicates which was used. (See Section 5.8.1.2.) 6114 6. Added the necessary information elements to allow the IP hop 6115 count between adjacent GIMPS peers to be measures and reported. 6116 (See Section 5.2.2 and Appendix A.3.3.) 6118 7. The old open-issue text on selection of IP router alert option 6119 values has been moved into the main specification to capture the 6120 technical considerations that should be used in assigning such 6121 values (in old section 5.3.3). 6123 8. Resolved the open issue on lost Confirm messages by allowing a 6124 choice of timer-based retransmission of the Response, or an 6125 error message from the responding node which causes the 6126 retransmission of the Confirm (see Section 5.3.3). 6128 9. Closed the open issue on support for message scoping (this is 6129 now assumed to be a NSLP function). 6131 10. Moved the authoritative text for most of the remaining open 6132 issues to an online issue tracker. 6134 D.8. Changes In Version -04 6136 Version -04 includes mainly clarifications of detail and extensions 6137 in particular technical areas, in part to support ongoing 6138 implementation work. The main details are as follows: 6140 1. Substantially updated Section 4, in particular clarifying the 6141 rules on what messages are sent when and with what payloads 6142 during routing and messaging association setup, and also adding 6143 some further text on message transfer attributes. 6145 2. The description of messaging association protocol setup 6146 including the related object formats has been centralised in a 6147 new Section 5.7, removing the old Section 6.6 and also closing 6148 old open issues 8.5 and 8.6. 6150 3. Made a number of detailed changes in the message format 6151 definitions (Appendix A), as well as incorporating initial rules 6152 for encoding message extensibility information. Also included 6153 explicit formats for a general purpose Error object, and the 6154 objects used to discover supported messaging association 6155 protocols. Updated the corresponding open issues section (old 6156 section 9.3) with a new item on NSLP versioning. 6158 4. Updated the GIMPS API (Appendix B), including more precision on 6159 message transfer attributes, making the NSLP hint about storing 6160 reverse path state a return value rather than a separate 6161 primitive, and adding a new primitive to allow signaling 6162 applications to invalidate GIMPS routing state. Also, added a 6163 new parameter to SendMessage to allow signaling applications to 6164 'bypass' a message statelessly, preserving the source of an 6165 input message. 6167 5. Added an outline for the future content of an IANA 6168 considerations section (Section 9). Currently, this is 6169 restricted to identifying the registries and allocations 6170 required, without defining the allocation policies and other 6171 considerations involved. 6173 6. Shortened the background design discussion in Section 3. 6175 7. Made some clarifications in the terminology section relating to 6176 how the use of C-mode does and does not mandate the use of 6177 transport or security protection. 6179 8. The ABNF for message formats in Section 5.1 has been re-written 6180 with a grammar structured around message purpose rather than 6181 message direction, and additional explanation added to the 6182 information element descriptions in Section 5.2. 6184 9. The description of the D-mode transport in Section 5.3 has been 6185 updated. The encapsulation rules (covering IP addressing and 6186 UDP port allocation) have been corrected, and a new subsection 6187 on message retransmission and rate limiting has been added, 6188 superseding the old open issue on the same subject (section 6189 8.10). 6191 10. A new open issue on IP TTL measurement to detect non-GIMPS 6192 capable hops has been added (old section 9.5). 6194 D.9. Changes In Version -03 6196 Version -03 includes a number of minor clarifications and extensions 6197 compared to version -02, including more details of the GIMPS API and 6198 messaging association setup and the node addressing object. The full 6199 list of changes is as follows: 6201 1. Added a new section pinning down more formally the interaction 6202 between GIMPS and signaling applications (Section 4.1), in 6203 particular the message transfer attributes that signaling 6204 applications can use to control GIMPS (Section 4.1.2). 6206 2. Added a new open issue identifying where the interaction between 6207 the security properties of GIMPS and the security requirements of 6208 signaling applications should be identified (old section 9.10). 6210 3. Added some more text in Section 4.2.1 to clarify that GIMPS has 6211 the (sole) responsibility for generating the messages that 6212 refresh message routing state. 6214 4. Added more clarifying text and table to GHC and IP TTL handling 6215 discussion of Section 4.3.4. 6217 5. Split Section 4.4 into subsections for different scenarios, and 6218 added more detail on Node-Addressing object content and use to 6219 handle the case where association re-use is possible in 6220 Section 4.4.2. 6222 6. Added strawman object formats for Node-Addressing and Stack- 6223 Proposal objects in Section 5.1 and Appendix A. 6225 7. Added more detail on the bundling possibilities and appropriate 6226 configurations for various transport protocols in Section 5.4.1. 6228 8. Included some more details on NAT traversal in Section 7.2, 6229 including a new object to carry the untranslated address-bearing 6230 payloads, the NAT-Traversal object. 6232 9. Expanded the open issue discussion in old section 9.3 to include 6233 an outline set of extensibility flags. 6235 D.10. Changes In Version -02 6237 Version -02 does not represent any radical change in design or 6238 structure from version -01; the emphasis has been on adding details 6239 in some specific areas and incorporation of comments, including early 6240 review comments. The full list of changes is as follows: 6242 1. Added a new Section 1.1 which summarises restrictions on scope 6243 and applicability; some corresponding changes in terminology in 6244 Section 2. 6246 2. Closed the open issue on including explicit GIMPS state teardown 6247 functionality. On balance, it seems that the difficulty of 6248 specifying this correctly (especially taking account of the 6249 security issues in all scenarios) is not matched by the saving 6250 of state enabled. 6252 3. Removed the option of a special class of message transfer for 6253 reliable delivery of a single message. This can be implemented 6254 (inefficiently) as a degenerate case of C-mode if required. 6256 4. Extended Appendix A with a general discussion of rules for 6257 message and object formats across GIMPS and other NSLPs. Some 6258 remaining open issues are noted in old section 9.3 (since 6259 removed). 6261 5. Updated the discussion of RAO/NSLPID relationships to take into 6262 account the proposed message formats and rules for allocation of 6263 NSLP id, and propose considerations for allocation of RAO 6264 values. 6266 6. Modified the description of the information used to route 6267 messages (first given in Section 4.2.1 but also throughout the 6268 document). Previously this was related directly to the flow 6269 identification and described as the Flow-Routing-Information. 6270 Now, this has been renamed Message-Routing-Information, and 6271 identifies a message routing method and any associated 6272 addressing. 6274 7. Modified the text in Section 4.3 and elsewhere to impose sanity 6275 checks on the Message-Routing-Information carried in C-mode 6276 messages, including the case where these messages are part of a 6277 GIMPS-Query/Response exchange. 6279 8. Added rules for message forwarding to prevent message looping in 6280 a new Section 4.3.4, including rules on IP TTL and GIMPS hop 6281 count processing. These take into account the new RAO 6282 considerations described above. 6284 9. Added an outline mechanism for messaging association protocol 6285 stack setup, with the details in a new Section 6.6 and other 6286 changes in Section 4.4 and the various sections on message 6287 formats. 6289 10. Removed the open issue on whether storing reverse routing state 6290 is mandatory or optional. This is now explicit in the API 6291 (under the control of the local NSLP). 6293 11. Added an informative annex describing an abstract API between 6294 GIMPS and NSLPs in Appendix B. 6296 D.11. Changes In Version -01 6298 The major change in version -01 is the elimination of 6299 'intermediaries', i.e. imposing the constraint that signaling 6300 application peers are also GIMPS peers. This has the consequence 6301 that if a signaling application wishes to use two classes of 6302 signaling transport for a given flow, maybe reaching different 6303 subsets of nodes, it must do so by running different signaling 6304 sessions; and it also means that signaling adaptations for passing 6305 through NATs which are not signaling application aware must be 6306 carried out in D-mode. On the other hand, it allows the elimination 6307 of significant complexity in the C-mode handling and also various 6308 other protocol features (such as general route recording). 6310 The full set of changes is as follows: 6312 1. Added a worked example in Section 3.7. 6314 2. Stated that nodes which do not implement the signaling 6315 application should bypass the message (Section 4.3). 6317 3. Decoupled the state handling logic for routing state and 6318 messaging association state in Section 4.4. Also, allow 6319 messaging associations to be used immediately in both directions 6320 once they are opened. 6322 4. Added simple ABNF for the various GIMPS message types in a new 6323 Section 5.1, and more details of the common header and each 6324 object in Section 5.2, including bit formats in Appendix A. The 6325 common header format means that the encapsulation is now the 6326 same for all transport types (Section 5.4.1). 6328 5. Added some further details on D-mode encapsulation in 6329 Section 5.3, including more explanation of why a well known port 6330 is needed. 6332 6. Removed the possibility for fragmentation over DCCP 6333 (Section 5.4.1), mainly in the interests of simplicity and loss 6334 amplification. 6336 7. Removed all the tunnel mode encapsulations (old sections 5.3.3 6337 and 5.3.4). 6339 8. Fully re-wrote the route change handling description 6340 (Section 7.1), including some additional detection mechanisms 6341 and more clearly distinguishing between upstream and downstream 6342 route changes. Included further details on GIMPS/NSLP 6343 interactions, including where notifications are delivered and 6344 how local repair storms could be avoided. Removed old 6345 discussion of propagating notifications through signaling 6346 application unaware nodes (since these are now bypassed 6347 automatically). Added discussion on how to route messages for 6348 local state removal on the old path. 6350 9. Revised discussion of policy-based forwarding (old Section 7.2) 6351 to account for actual Flow-Routing-Information definition, and 6352 also how wildcarding should be allowed and handled. 6354 10. Removed old route recording section (old Section 6.3). 6356 11. Extended the discussion of NAT handling (Section 7.2) with an 6357 extended outline on processing rules at a GIMPS-aware NAT and a 6358 pointer to implications for C-mode processing and state 6359 management. 6361 12. Clarified the definition of 'correct routing' of signaling 6362 messages in Section 8 and GIMPS role in enforcing this. Also, 6363 opened the possibility that peer node authentication could be 6364 signaling application dependent. 6366 13. Removed old open issues on C-mode Encapsulation (section 8.7); 6367 added new open issues on Message Routing (old Section 9.3 of 6368 version -05, later moved to Section 3.3) and D-mode congestion 6369 control. 6371 14. Added this change history. 6373 Authors' Addresses 6375 Henning Schulzrinne 6376 Columbia University 6377 Department of Computer Science 6378 450 Computer Science Building 6379 New York, NY 10027 6380 US 6382 Phone: +1 212 939 7042 6383 Email: hgs+nsis@cs.columbia.edu 6384 URI: http://www.cs.columbia.edu 6386 Robert Hancock 6387 Siemens/Roke Manor Research 6388 Old Salisbury Lane 6389 Romsey, Hampshire SO51 0ZN 6390 UK 6392 Email: robert.hancock@roke.co.uk 6393 URI: http://www.roke.co.uk 6395 Full Copyright Statement 6397 Copyright (C) The Internet Society (2006). 6399 This document is subject to the rights, licenses and restrictions 6400 contained in BCP 78, and except as set forth therein, the authors 6401 retain all their rights. 6403 This document and the information contained herein are provided on an 6404 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 6405 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 6406 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 6407 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 6408 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 6409 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6411 Intellectual Property 6413 The IETF takes no position regarding the validity or scope of any 6414 Intellectual Property Rights or other rights that might be claimed to 6415 pertain to the implementation or use of the technology described in 6416 this document or the extent to which any license under such rights 6417 might or might not be available; nor does it represent that it has 6418 made any independent effort to identify any such rights. Information 6419 on the procedures with respect to rights in RFC documents can be 6420 found in BCP 78 and BCP 79. 6422 Copies of IPR disclosures made to the IETF Secretariat and any 6423 assurances of licenses to be made available, or the result of an 6424 attempt made to obtain a general license or permission for the use of 6425 such proprietary rights by implementers or users of this 6426 specification can be obtained from the IETF on-line IPR repository at 6427 http://www.ietf.org/ipr. 6429 The IETF invites any interested party to bring to its attention any 6430 copyrights, patents or patent applications, or other proprietary 6431 rights that may cover technology that may be required to implement 6432 this standard. Please address the information to the IETF at 6433 ietf-ipr@ietf.org. 6435 Acknowledgment 6437 Funding for the RFC Editor function is provided by the IETF 6438 Administrative Support Activity (IASA).