idnits 2.17.1 draft-ietf-nsis-ntlp-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 15 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (June 3, 2009) is 5433 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'Data' on line 251 -- Looks like a reference, but probably isn't: 'Flow' on line 266 -- Looks like a reference, but probably isn't: 'Adjacent' on line 276 -- Looks like a reference, but probably isn't: 'Message' on line 307 -- Looks like a reference, but probably isn't: 'Initialisation' on line 3761 == Unused Reference: '44' is defined on line 5448, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4307 (ref. '4') (Obsoleted by RFC 8247) ** Obsolete normative reference: RFC 5226 (ref. '5') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 2460 (ref. '6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2765 (ref. '8') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 5246 (ref. '11') (Obsoleted by RFC 8446) == Outdated reference: A later version (-07) exists of draft-ietf-nsis-ext-02 -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '16') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. '21') (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 5389 (ref. '27') (Obsoleted by RFC 8489) == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-14 -- Obsolete informational reference (is this intentional?): RFC 3852 (ref. '29') (Obsoleted by RFC 5652) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-20 -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '40') (Obsoleted by RFC 9260) == Outdated reference: A later version (-10) exists of draft-ietf-nsis-ntlp-statemachine-06 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-11 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 12 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: Experimental R. Hancock 5 Expires: December 5, 2009 RMR 6 June 3, 2009 8 GIST: General Internet Signalling Transport 9 draft-ietf-nsis-ntlp-20 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 5, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document specifies protocol stacks for the routing and transport 48 of per-flow signalling messages along the path taken by that flow 49 through the network. The design uses existing transport and security 50 protocols under a common messaging layer, the General Internet 51 Signalling Transport (GIST), which provides a common service for 52 diverse signalling applications. GIST does not handle signalling 53 application state itself, but manages its own internal state and the 54 configuration of the underlying transport and security protocols to 55 enable the transfer of messages in both directions along the flow 56 path. The combination of GIST and the lower layer transport and 57 security protocols provides a solution for the base protocol 58 component of the "Next Steps in Signalling" framework. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Requirements Notation and Terminology . . . . . . . . . . . . 6 64 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 9 66 3.2. Modes and Messaging Associations . . . . . . . . . . . . 10 67 3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 12 68 3.4. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 14 69 3.5. GIST Peering Relationships . . . . . . . . . . . . . . . 15 70 3.6. Effect on Internet Transparency . . . . . . . . . . . . . 15 71 3.7. Signalling Sessions . . . . . . . . . . . . . . . . . . . 16 72 3.8. Signalling Applications and NSLPIDs . . . . . . . . . . . 17 73 3.9. GIST Security Services . . . . . . . . . . . . . . . . . 17 74 3.10. Example of Operation . . . . . . . . . . . . . . . . . . 18 75 4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 22 76 4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 22 77 4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 24 78 4.3. Basic GIST Message Processing . . . . . . . . . . . . . . 26 79 4.4. Routing State and Messaging Association Maintenance . . . 34 80 5. Message Formats and Transport . . . . . . . . . . . . . . . . 46 81 5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 46 82 5.2. Information Elements . . . . . . . . . . . . . . . . . . 48 83 5.3. D-mode Transport . . . . . . . . . . . . . . . . . . . . 53 84 5.4. C-mode Transport . . . . . . . . . . . . . . . . . . . . 59 85 5.5. Message Type/Encapsulation Relationships . . . . . . . . 60 86 5.6. Error Message Processing . . . . . . . . . . . . . . . . 61 87 5.7. Messaging Association Setup . . . . . . . . . . . . . . . 61 88 5.8. Specific Message Routing Methods . . . . . . . . . . . . 66 89 6. Formal Protocol Specification . . . . . . . . . . . . . . . . 72 90 6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 74 91 6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 75 92 6.3. Responder Node Processing . . . . . . . . . . . . . . . . 78 93 6.4. Messaging Association Processing . . . . . . . . . . . . 81 94 7. Additional Protocol Features . . . . . . . . . . . . . . . . 85 95 7.1. Route Changes and Local Repair . . . . . . . . . . . . . 85 96 7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 92 97 7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 98 98 7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 99 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 101 100 8.1. Message Confidentiality and Integrity . . . . . . . . . . 101 101 8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 102 102 8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 102 103 8.4. Denial of Service Prevention and Overload Protection . . 104 104 8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 106 105 8.6. Security Protocol Selection Policy . . . . . . . . . . . 108 106 8.7. Residual Threats . . . . . . . . . . . . . . . . . . . . 109 107 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111 108 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 116 109 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 110 11.1. Normative References . . . . . . . . . . . . . . . . . . 117 111 11.2. Informative References . . . . . . . . . . . . . . . . . 118 112 Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 121 113 A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 121 114 A.2. General Object Format . . . . . . . . . . . . . . . . . . 122 115 A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 124 116 A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 133 117 Appendix B. API between GIST and Signalling Applications . . . . 143 118 B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 143 119 B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 145 120 B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 146 121 B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 147 122 B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 148 123 B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 148 124 Appendix C. Deployment Issues with Router Alert Options . . . . 150 125 Appendix D. Example Routing State Table and Handshake . . . . . 153 126 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 155 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 156 129 1. Introduction 131 Signalling involves the manipulation of state held in network 132 elements. 'Manipulation' could mean setting up, modifying and 133 tearing down state; or it could simply mean the monitoring of state 134 which is managed by other mechanisms. This specification 135 concentrates mainly on path-coupled signalling, controlling resources 136 on network elements which are located on the path taken by a 137 particular data flow, possibly including but not limited to the flow 138 endpoints. Examples of state management include network resource 139 reservation, firewall configuration, and state used in active 140 networking; examples of state monitoring are the discovery of 141 instantaneous path properties, such as available bandwidth or 142 cumulative queuing delay. Each of these different uses of signalling 143 is referred to as a signalling application. 145 GIST assumes other mechanisms are responsible for controlling routing 146 within the network, and GIST is not designed to set up or modify 147 paths itself; therefore it is complementary to protocols like RSVP-TE 148 [23] or LDP [24] rather than an alternative. There are almost always 149 more than two participants in a path-coupled signalling session, 150 although there is no need for every node on the path to participate; 151 indeed, support for GIST and any signalling applications imposes a 152 performance cost, and deployment for flow-level signalling is much 153 more likely on edge devices than core routers. GIST path-coupled 154 signalling does not directly support multicast flows, but the current 155 GIST design could be extended to do so, especially in environments 156 where the multicast replication points can be made GIST-capable. 157 GIST can also be extended to cover other types of signalling pattern, 158 not related to any end-to-end flow in the network, in which case the 159 distinction between GIST and end-to-end higher-layer signalling will 160 be drawn differently or not at all. 162 Every signalling application requires a set of state management 163 rules, as well as protocol support to exchange messages along the 164 data path. Several aspects of this protocol support are common to 165 all or a large number of signalling applications, and hence can be 166 developed as a common protocol. The NSIS framework given in [30] 167 provides a rationale for a function split between the common and 168 application specific protocols, and gives outline requirements for 169 the former, the 'NSIS Transport Layer Protocol' (NTLP). Several 170 concepts in the framework are derived from RSVP [15], as are several 171 aspects of the GIST protocol design. The application specific 172 protocols are referred to as 'NSIS Signalling Layer Protocols' 173 (NSLPs), and are defined in separate documents. The NSIS framework 174 [30], and the accompanying threats document [31], provide important 175 background information to this specification, including information 176 on how GIST is expected to be used in various network types and what 177 role it is expected to perform. 179 This specification provides a concrete solution for the NTLP. It is 180 based on the use of existing transport and security protocols under a 181 common messaging layer, the General Internet Signalling Transport 182 (GIST). GIST does not handle signalling application state itself; in 183 that crucial respect, it differs from higher layer signalling 184 protocols such as SIP, RTSP, and the control component of FTP. 185 Instead, GIST manages its own internal state and the configuration of 186 the underlying transport and security protocols to ensure the 187 transfer of signalling messages on behalf of signalling applications 188 in both directions along the flow path. The purpose of GIST is thus 189 to provide the common functionality of node discovery, message 190 routing and message transport in a way which is simple for multiple 191 signalling applications to re-use. 193 The structure of this specification is as follows. Section 2 defines 194 terminology, and Section 3 gives an informal overview of the protocol 195 design principles and operation. The normative specification is 196 contained mainly in Section 4 to Section 8. Section 4 describes the 197 message sequences and Section 5 their format and contents. Note that 198 the detailed bit formats are given in Appendix A. The protocol 199 operation is captured in the form of state machines in Section 6. 200 Section 7 describes some more advanced protocol features and security 201 considerations are contained in Section 8. In addition, Appendix B 202 describes an abstract API for the service which GIST provides to 203 signalling applications, and Appendix D provides an example message 204 flow. Parts of the GIST design use packets with IP options to probe 205 the network, which leads to some migration issues in the case of 206 IPv4, and these are discussed in Appendix C. 208 Because of the layered structure of the NSIS protocol suite, protocol 209 extensions to cover a new signalling requirement could be carried out 210 either within GIST, or within the signalling application layer, or 211 both. General guidelines on how to extend different layers of the 212 protocol suite, and in particular when and how it is appropriate to 213 extend GIST, are contained in a separate document [13]. In this 214 document, Section 9 gives the formal IANA considerations for the 215 registries defined by the GIST specification. 217 2. Requirements Notation and Terminology 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in RFC 2119 [3]. In 222 addition, the security specifications in Section 5.7.3 use the 223 terminology MUST- and SHOULD+ from [4]. 225 The terminology used in this specification is defined in this 226 section. The basic entities relevant at the GIST level are shown in 227 Figure 1. In particular, this diagram distinguishes the different 228 address types as being associated with a flow (end-to-end addresses) 229 or signalling (addresses of adjacent signalling peers). 231 Source GIST (adjacent) peer nodes Destination 233 IP address IP addresses = Signalling IP address 234 = Flow Source/Destination Addresses = Flow 235 Source (depending on signalling direction) Destination 236 Address | | Address 237 V V 238 +--------+ +------+ Data Flow +------+ +--------+ 239 | Flow |-----------|------|-------------|------|-------->| Flow | 240 | Sender | | | | | |Receiver| 241 +--------+ | GIST |============>| GIST | +--------+ 242 | Node |<============| Node | 243 +------+ Signalling +------+ 244 GN1 Flow GN2 246 >>>>>>>>>>>>>>>>> = Downstream direction 247 <<<<<<<<<<<<<<<<< = Upstream direction 249 Figure 1: Basic Terminology 251 [Data] Flow: A set of packets identified by some fixed combination 252 of header fields. Flows are unidirectional; a bidirectional 253 communication is considered a pair of unidirectional flows. 255 Session: A single application layer exchange of information for 256 which some state information is to be manipulated or monitored. 257 See Section 3.7 for further detailed discussion. 259 Session Identifier (SID): An identifier for a session; the syntax is 260 a 128 bit value which is opaque to GIST. 262 [Flow] Sender: The node in the network which is the source of the 263 packets in a flow. A sender could be a host, or a router if for 264 example the flow is actually an aggregate. 266 [Flow] Receiver: The node in the network which is the sink for the 267 packets in a flow. 269 Downstream: In the same direction as the data flow. 271 Upstream: In the opposite direction to the data flow. 273 GIST Node: Any node supporting the GIST protocol, regardless of what 274 signalling applications it supports. 276 [Adjacent] Peer: The next node along the signalling path, in the 277 upstream or downstream direction, with which a GIST node 278 explicitly interacts. 280 Querying Node: The GIST node that initiates the handshake process to 281 discover the adjacent peer. 283 Responding Node: The GIST node that responds to the handshake, 284 becoming the adjacent peer to the Querying node. 286 Datagram Mode (D-mode): A mode of sending GIST messages between 287 nodes without using any transport layer state or security 288 protection. Datagram mode uses UDP encapsulation, with source and 289 destination IP addresses derived either from the flow definition 290 or previously discovered adjacency information. 292 Connection Mode (C-mode): A mode of sending GIST messages directly 293 between nodes using point-to-point messaging associations (see 294 below). Connection mode allows the re-use of existing transport 295 and security protocols where such functionality is required. 297 Messaging Association (MA): A single connection between two 298 explicitly identified GIST adjacent peers, i.e. between a given 299 signalling source and destination address. A messaging 300 association may use a transport protocol; if security protection 301 is required, it may use a network layer security association, or 302 use a transport layer security association internally. A 303 messaging association is bidirectional: signalling messages can be 304 sent over it in either direction, referring to flows of either 305 direction. 307 [Message] Routing: Message routing describes the process of 308 determining which is the next GIST peer along the signalling path. 309 For signalling along a flow path, the message routing carried out 310 by GIST is built on top of normal IP routing, that is, forwarding 311 packets within the network layer based on their destination IP 312 address. In this document, the term 'routing' generally refers to 313 GIST message routing unless particularly specified. 315 Message Routing Method (MRM): There can be different algorithms for 316 discovering the route that signalling messages should take. These 317 are referred to as message routing methods, and GIST supports 318 alternatives within a common protocol framework. See Section 3.3. 320 Message Routing Information (MRI): The set of data item values which 321 is used to route a signalling message according to a particular 322 MRM; for example, for routing along a flow path, the MRI includes 323 flow source and destination addresses, protocol and port numbers. 324 See Section 3.3. 326 Router Alert Option (RAO): An option that can be included in IPv4 327 and v6 headers to assist in the packet interception process; see 328 [14] and [18]. 330 Transfer Attributes: A description of the requirements which a 331 signalling application has for the delivery of a particular 332 message; for example, whether the message should be delivered 333 reliably. See Section 4.1.2. 335 3. Design Overview 337 3.1. Overall Design Approach 339 The generic requirements identified in the NSIS framework [30] for 340 transport of signalling messages are essentially two-fold: 342 Routing: Determine how to reach the adjacent signalling node along 343 each direction of the data path (the GIST peer), and if necessary 344 explicitly establish addressing and identity information about 345 that peer; 347 Transport: Deliver the signalling information to that peer. 349 To meet the routing requirement, one possibility is for the node to 350 use local routing state information to determine the identity of the 351 GIST peer explicitly. GIST defines a three-way handshake which 352 probes the network to set up the necessary routing state between 353 adjacent peers, during which signalling applications can also 354 exchange data. Once the routing decision has been made, the node has 355 to select a mechanism for transport of the message to the peer. GIST 356 divides the transport functionality into two parts, a minimal 357 capability provided by GIST itself, with the use of well-understood 358 transport protocols for the harder cases. Here, with details 359 discussed later, the minimal capability is restricted to messages 360 that are sized well below the lowest maximum transmission unit (MTU) 361 along a path, are infrequent enough not to cause concerns about 362 congestion and flow control, and do not need security protection or 363 guaranteed delivery. 365 In [30] all of these routing and transport requirements are assigned 366 to a single notional protocol, the NSIS Transport Layer Protocol 367 (NTLP). The strategy of splitting the transport problem leads to a 368 layered structure for the NTLP, with a specialised GIST messaging 369 layer running over standard transport and security protocols. The 370 basic concept is shown in Figure 2. Note that not every combination 371 of transport and security protocols implied by the figure is actually 372 possible for use in GIST; the actual combinations allowed by this 373 specification are defined in Section 5.7. The figure also shows GIST 374 offering its services to upper layers at an abstract interface, the 375 GIST API, further discussed in Section 4.1. 377 ^^ +-------------+ 378 || | Signalling | 379 NSIS +------------|Application 2| 380 Signalling | Signalling +-------------+ 381 Application |Application 1| | 382 Level +-------------+ | 383 || | | 384 VV | | 385 ========|===================|===== <-- GIST API 386 | | 387 ^^ +------------------------------------------------+ 388 || |+-----------------------+ +--------------+ | 389 || || GIST | | GIST State | | 390 || || Encapsulation |<<<>>>| Maintenance | | 391 || |+-----------------------+ +--------------+ | 392 || | GIST: Messaging Layer | 393 || +------------------------------------------------+ 394 NSIS | | | | 395 Transport .......................................... 396 Level . Transport Layer Security (TLS or DTLS) . 397 (NTLP) .......................................... 398 || | | | | 399 || +----+ +----+ +----+ +----+ 400 || |UDP | |TCP | |SCTP| |DCCP| ... other 401 || +----+ +----+ +----+ +----+ protocols 402 || | | | | 403 || ............................. 404 || . IP Layer Security . 405 || ............................. 406 VV | | | | 407 ===========================|=======|=======|=======|============ 408 | | | | 409 +----------------------------------------------+ 410 | IP | 411 +----------------------------------------------+ 413 Figure 2: Protocol Stack Architecture for Signalling Transport 415 3.2. Modes and Messaging Associations 417 Internally, GIST has two modes of operation: 419 Datagram mode (D-mode): used for small, infrequent messages with 420 modest delay constraints and no security requirements. A special 421 case of D-mode called Query-mode (Q-mode) is used when no routing 422 state exists. 424 Connection mode (C-mode): is used for all other signalling traffic. 425 In particular, it can support large messages and channel security, 426 and provides congestion control for signalling traffic. 428 C-mode can in principle use any stream or message-oriented transport 429 protocol; this specification defines TCP as the initial choice. It 430 can in principle employ specific network layer security associations, 431 or an internal transport layer security association; this 432 specification defines TLS as the initial choice. When GIST messages 433 are carried in C-mode, they are treated just like any other traffic 434 by intermediate routers between the GIST peers. Indeed, it would be 435 impossible for intermediate routers to carry out any processing on 436 the messages without terminating the transport and security protocols 437 used. 439 D-mode uses UDP, as a suitable NAT-friendly encapsulation which does 440 not require per-message shared state to be maintained between the 441 peers. Long-term evolution of GIST is assumed to preserve the 442 simplicity of the current D-mode design. Any extension to the 443 security or transport capabilities of D-mode can be viewed as the 444 selection of a different protocol stack under the GIST messaging 445 layer; this is then equivalent to defining another option within the 446 overall C-mode framework. This includes both the case of using 447 existing protocols, and specific development of a message exchange 448 and payload encapsulation to support GIST requirements. 449 Alternatively, if any necessary parameters (e.g. a shared secret for 450 use in integrity or confidentiality protection) can be negotiated 451 out-of-band, then the additional functions can be added directly to 452 D-mode by adding an optional object to the message (see 453 Appendix A.2.1). Note that in such an approach, downgrade attacks as 454 discussed in Section 8.6 would need to be prevented by policy at the 455 destination node. 457 It is possible to mix these two modes along a path. This allows, for 458 example, the use of D-mode at the edges of the network and C-mode 459 towards the core. Such combinations may make operation more 460 efficient for mobile endpoints, while allowing shared security 461 associations and transport connections to be used for messages for 462 multiple flows and signalling applications. The setup for these 463 protocols imposes an initialisation cost for the use of C-mode, but 464 in the long term this cost can be shared over all signalling sessions 465 between peers; once the transport layer state exists, retransmission 466 algorithms can operate much more aggressively than would be possible 467 in a pure D-mode design. 469 It must be understood that the routing and transport functions within 470 by GIST are not independent. If the message transfer has 471 requirements that require C-mode, for example if the message is so 472 large that fragmentation is required, this can only be used between 473 explicitly identified nodes. In such cases, GIST carries out the 474 three-way handshake initially in D-mode to identify the peer and then 475 sets up the necessary connections if they do not already exist. It 476 must also be understood that the signalling application does not make 477 the D-mode/C-mode selection directly; rather, this decision is made 478 by GIST on the basis of the message characteristics and the transfer 479 attributes stated by the application. The distinction is not visible 480 at the GIST service interface. 482 In general, the state associated with C-mode messaging to a 483 particular peer (signalling destination address, protocol and port 484 numbers, internal protocol configuration and state information) is 485 referred to as a messaging association (MA). MAs are totally 486 internal to GIST (they are not visible to signalling applications). 487 Although GIST may be using an MA to deliver messages about a 488 particular flow, there is no direct correspondence between them: the 489 GIST message routing algorithms consider each message in turn and 490 select an appropriate MA to transport it. There may be any number of 491 MAs between two GIST peers although the usual case is zero or one, 492 and they are set up and torn down by management actions within GIST 493 itself. 495 3.3. Message Routing Methods 497 The baseline message routing functionality in GIST is that signalling 498 messages follow a route defined by an existing flow in the network, 499 visiting a subset of the nodes through which it passes. This is the 500 appropriate behaviour for application scenarios where the purpose of 501 the signalling is to manipulate resources for that flow. However, 502 there are scenarios for which other behaviours are applicable. Two 503 examples are: 505 Predictive Routing: Here, the intent is to signal along a path that 506 the data flow may follow in the future. Possible cases are pre- 507 installation of state on the backup path that would be used in the 508 event of a link failure, and predictive installation of state on 509 the path that will be used after a mobile node handover. 511 NAT Address Reservations: This applies to the case where a node 512 behind a NAT wishes to reserve an address at which it can be 513 reached by a sender on the other side. This requires a message to 514 be sent outbound from what will be the flow receiver although no 515 reverse routing state for the flow yet exists. 517 Most of the details of GIST operation are independent of the routing 518 behaviour being used. Therefore, the GIST design encapsulates the 519 routing-dependent details as a message routing method (MRM), and 520 allows multiple MRMs to be defined. This specification defines the 521 path-coupled MRM, corresponding to the baseline functionality 522 described above, and a second ("Loose End") MRM for the NAT Address 523 Reservation case. The detailed specifications are given in 524 Section 5.8. 526 The content of an MRM definition is as follows, using the path- 527 coupled MRM as an example: 529 o The format of the information that describes the path that the 530 signalling should take, the Message Routing Information (MRI). 531 For the path-coupled MRM, this is just the Flow Identifier (see 532 Section 5.8.1.1) and some additional control information. 533 Specifically, the MRI always includes a flag to distinguish 534 between the two directions that signalling messages can take, 535 denoted 'upstream' and 'downstream'. 537 o A specification of the IP-level encapsulation of the messages 538 which probe the network to discover the adjacent peers. A 539 downstream encapsulation must be defined; an upstream 540 encapsulation is optional. For the path-coupled MRM, this 541 information is given in Section 5.8.1.2 and Section 5.8.1.3. 542 Current MRMs rely on the interception of probe messages in the 543 data plane, but other mechanisms are also possible within the 544 overall GIST design and would be appropriate for other types of 545 signalling pattern. 547 o A specification of what validation checks GIST should apply to the 548 probe messages, for example to protect against IP address spoofing 549 attacks. The checks may be dependent on the direction (upstream 550 or downstream) of the message. For the path-coupled MRM, the 551 downstream validity check is basically a form of ingress 552 filtering, also discussed in Section 5.8.1.2. 554 o The mechanism(s) available for route change detection, i.e. any 555 change in the neighbour relationships that the MRM discovers. The 556 default case for any MRM is soft-state refresh, but additional 557 supporting techniques may be possible; see Section 7.1.2. 559 In addition, it should be noted that NAT traversal may require 560 translation of fields in the MRI object carried in GIST messages (see 561 Section 7.2.2). The generic MRI format includes a flag that must be 562 given as part of the MRM definition, to indicate if some kind of 563 translation is necessary. Development of a new MRM therefore 564 includes updates to the GIST specification, and may include updates 565 to specifications of NAT behaviour. These updates may be done in 566 separate documents as is the case for NAT traversal for the MRMs of 567 the base GIST specification, as described in Section 7.2.3 and [46]. 569 The MRI is passed explicitly between signalling applications and 570 GIST; therefore, signalling application specifications must define 571 which MRMs they require. Signalling applications may use fields in 572 the MRI in their packet classifiers; if they use additional 573 information for packet classification, this would be carried at the 574 NSLP level and so would be invisible to GIST. Any node hosting a 575 particular signalling application needs to use a GIST implementation 576 that supports the corresponding MRMs. The GIST processing rules 577 allow nodes not hosting the signalling application to ignore messages 578 for it at the GIST level, so it does not matter if these nodes 579 support the MRM or not. 581 3.4. GIST Messages 583 GIST has six message types: Query, Response, Confirm, Data, Error, 584 and MA-Hello. Apart from the invocation of the messaging association 585 protocols used by C-mode, all GIST communication consists of these 586 messages. In addition, all signalling application data is carried as 587 additional payloads in these messages, alongside the GIST 588 information. 590 The Query, Response and Confirm messages implement the handshake that 591 GIST uses to set up routing state and messaging associations. The 592 handshake is initiated from the Querying node towards the Responding 593 node. The first message is the Query, which is encapsulated in a 594 specific way depending on the message routing method, in order to 595 probe the network infrastructure so that the correct peer will 596 intercept it and become the Responding node. A Query always triggers 597 a Response in the reverse direction as the second message of the 598 handshake. The content of the Response controls whether a Confirm 599 message is sent: as part of the defence against denial of service 600 attacks, the Responding node can delay state installation until a 601 return routability check has been performed, and require the Querying 602 node to complete the handshake with the Confirm message. In 603 addition, if the handshake is being used to set up a new MA, the 604 Response is required to request a Confirm. All of these three 605 messages can optionally carry signalling application data. The 606 handshake is fully described in Section 4.4.1. 608 The Data message is used purely to encapsulate and deliver signalling 609 application data. Usually it is sent using pre-established routing 610 state. However, if there are no security or transport requirements 611 and no need for persistent reverse routing state, it can also be sent 612 in the same way as the Query. Finally, Error messages are used to 613 indicate error conditions at the GIST level, and the MA-Hello message 614 can be used as a diagnostic and keepalive for the messaging 615 association protocols. 617 3.5. GIST Peering Relationships 619 Peering is the process whereby two GIST nodes create message routing 620 states which point to each other. 622 A peering relationship can only be created by a GIST handshake. 623 Nodes become peers when one issues a Query and gets a Response from 624 another. Issuing the initial Query is a result of an NSLP request on 625 that node, and the Query itself is formatted according to the rules 626 of the message routing method. For current MRMs, the identity of the 627 Responding node is not known explicitly at the time the Query is 628 sent; instead, the message is examined by nodes along the path until 629 one decides to send a Response, thereby becoming the peer. If the 630 node hosts the NSLP, local GIST and signalling application policy 631 determine whether to peer; the details are given in Section 4.3.2. 632 Nodes not hosting the NSLP forward the Query transparently 633 (Section 4.3.4). Note that the design of the Query message (see 634 Section 5.3.2) is such that nodes have to opt-in specifically to 635 carry out the message interception - GIST-unaware nodes see the Query 636 as a normal data packet and so forward it transparently. 638 An existing peering relationship can only be changed by a new GIST 639 handshake; in other words, it can only change when routing state is 640 refreshed. On a refresh, if any of the factors in the original 641 peering process have changed, the peering relationship can also 642 change. As well as network level rerouting, changes could include 643 modifications to NSIS signalling functions deployed at a node, or 644 alterations to signalling application policy. A change could cause 645 an existing node to drop out of the signalling path, or a new node to 646 become part of it. All these possibilities are handled as rerouting 647 events by GIST; further details of the process are described in 648 Section 7.1. 650 3.6. Effect on Internet Transparency 652 GIST relies on routers inside the network to intercept and process 653 packets which would normally be transmitted end-to-end. This 654 processing may be non-transparent: messages may be forwarded with 655 modifications, or not forwarded at all. This interception applies 656 only to the encapsulation used for the Query messages which probe the 657 network, for example along a flow path; all other GIST messages are 658 handled only by the nodes to which they are directly addressed, i.e. 659 as normal Internet traffic. 661 Because this interception potentially breaks Internet transparency 662 for packets which have nothing to do with GIST, the encapsulation 663 used by GIST in this case (called Query-mode or Q-mode) has several 664 features to avoid accidental collisions with other traffic: 666 o Q-mode messages are always sent as UDP traffic, and to a specific 667 well-known port allocated by IANA. 669 o All GIST messages sent as UDP have a magic number as the first 32- 670 bit word of the datagram payload. 672 Even if a node intercepts a packet as potentially a GIST message, 673 unless it passes both these checks it will be ignored at the GIST 674 level and forwarded transparently. Further discussion of the 675 reception process is in Section 4.3.1 and the encapsulation in 676 Section 5.3. 678 3.7. Signalling Sessions 680 GIST requires signalling applications to associate each of their 681 messages with a signalling session. Informally, given an application 682 layer exchange of information for which some network control state 683 information is to be manipulated or monitored, the corresponding 684 signalling messages should be associated with the same session. 685 Signalling applications provide the session identifier (SID) whenever 686 they wish to send a message, and GIST reports the SID when a message 687 is received; on messages forwarded at the GIST level, the SID is 688 preserved unchanged. Usually, NSLPs will preserve the SID value 689 along the entire signalling path, but this is not enforced by or even 690 visible to GIST, which only sees the scope of the SID as the single 691 hop between adjacent NSLP peers. 693 Most GIST processing and state information is related to the flow 694 (defined by the MRI, see above) and signalling application (given by 695 the NSLP identifier, see below). There are several possible 696 relationships between flows and sessions, for example: 698 o The simplest case is that all signalling messages for the same 699 flow have the same SID. 701 o Messages for more than one flow may use the same SID, for example 702 because one flow is replacing another in a mobility or multihoming 703 scenario. 705 o A single flow may have messages for different SIDs, for example 706 from independently operating signalling applications. 708 Because of this range of options, GIST does not perform any 709 validation on how signalling applications map between flows and 710 sessions, nor does it perform any direct validation on the properties 711 of the SID itself, such as any enforcement of uniqueness. GIST only 712 defines the syntax of the SID as an opaque 128-bit identifier. 714 The SID assignment has the following impact on GIST processing: 716 o Messages with the same SID that are to be delivered reliably 717 between the same GIST peers are delivered in order. 719 o All other messages are handled independently. 721 o GIST identifies routing state (upstream and downstream peer) by 722 the triplet (MRI, NSLP, SID). 724 Strictly speaking, the routing state should not depend on the SID. 725 However, if the routing state is keyed only by (MRI, NSLP), there is 726 a trivial denial of service attack (see Section 8.3) where a 727 malicious off-path node asserts that it is the peer for a particular 728 flow. Such an attack would not redirect the traffic but would 729 reroute the signalling. Instead, the routing state is also 730 segregated between different SIDs, which means that the attacking 731 node can only disrupt a signalling session if it can guess the 732 corresponding SID. Normative rules on the selection of SIDs are 733 given in Section 4.1.3. 735 3.8. Signalling Applications and NSLPIDs 737 The functionality for signalling applications is supported by NSIS 738 signalling layer protocols (NSLPs). Each NSLP is identified by a 16 739 bit NSLP identifier (NSLPID), assigned by IANA (Section 9). A single 740 signalling application, such as resource reservation, may define a 741 family of NSLPs to implement its functionality, for example to carry 742 out signalling operations at different levels in a hierarchy (cf. 743 [22]). However, the interactions between the different NSLPs (for 744 example, to relate aggregation levels or aggregation region 745 boundaries in the resource management case) are handled at the 746 signalling application level; the NSLPID is the only information 747 visible to GIST about the signalling application being used. 749 3.9. GIST Security Services 751 GIST has two distinct security goals: 753 o to protect GIST state from corruption, and to protect the nodes on 754 which it runs from resource exhaustion attacks; and 756 o to provide secure transport for NSLP messages to the signalling 757 applications. 759 The protocol mechanisms to achieve the first goal are mainly internal 760 to GIST. They include a cookie exchange and return routability check 761 to protect the handshake which sets up routing state, and a random 762 SID is also used to prevent off-path session hijacking by SID 763 guessing. Further details are given in Section 4.1.3 and 764 Section 4.4.1, and the overall security aspects are discussed in 765 Section 8. 767 A second level of protection is provided by the use of a channel 768 security protocol in messaging associations (i.e. within C-mode). 769 This mechanism serves two purposes: to protect against on-path 770 attacks on GIST, and to provide a secure channel for NSLP messages. 771 For the mechanism to be effective, it must be able to provide the 772 following functions: 774 o mutual authentication of the GIST peer nodes; 776 o ability to verify the authenticated identity against a database of 777 nodes authorised to take part in GIST signalling; 779 o confidentiality and integrity protection for NSLP data, and 780 provision of the authenticated identities used to the signalling 781 application. 783 The authorised peer database is described in more detail in 784 Section 4.4.2, including the types of entries that it can contain and 785 the authorisation checking algorithm that is used. The only channel 786 security protocol defined by this specification is a basic use of 787 TLS, and Section 5.7.3 defines the TLS-specific aspects of how these 788 functions (for example, authentication and identity comparison) are 789 integrated with the rest of GIST operation. At a high level, there 790 are several alternative protocols with similar functionality, and the 791 handshake (Section 4.4.1) provides a mechanism within GIST to select 792 between them. However, they differ in their identity schemes and 793 authentication methods and dependencies on infrastructure support for 794 the authentication process, and any GIST extension to incorporate 795 them would need to define the details of the corresponding 796 interactions with GIST operation. 798 3.10. Example of Operation 800 This section presents an example of GIST usage in a relatively simple 801 (in particular, NAT-free) signalling scenario, to illustrate its main 802 features. 804 GN1 GN2 805 +------------+ +------------+ 806 NSLP | | | | 807 Level | >>>>>>>>>1 | | 5>>>>>>>>5 | 808 | ^ V | Intermediate | ^ V | 809 |-^--------2-| Routers |-^--------V-| 810 | ^ V | | ^ V | 811 | ^ V | +-----+ +-----+ | ^ V | 812 >>>>>>>>>>^ >3>>>>>>>>4>>>>>>>>>>>4>>>>>>>>>5 5>>>>>>>>> 813 | | | | | | | | 814 GIST | 6<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<6 | 815 Level +------------+ +-----+ +-----+ +------------+ 817 >>>>>, <<<<< = Signalling messages 818 1 - 6 = Stages in the example 819 (stages 7 and 8 are not shown) 821 Figure 3: Example of Operation 823 Consider the case of an RSVP-like signalling application which makes 824 receiver-based resource reservations for a single unicast flow. In 825 general, signalling can take place along the entire end-to-end path 826 (between flow source and destination), but the role of GIST is only 827 to transfer signalling messages over a single segment of the path, 828 between neighbouring resource-capable nodes. Basic GIST operation is 829 the same, whether it involves the endpoints or only interior nodes: 830 in either case, GIST is triggered by a request from a local 831 signalling application. The example here describes how GIST 832 transfers messages between two adjacent peers some distance along the 833 path, GN1 and GN2 (see Figure 3). We take up the story at the point 834 where a message is being processed above the GIST layer by the 835 signalling application in GN1. 837 1. The signalling application in GN1 determines that this message is 838 a simple description of resources that would be appropriate for 839 the flow. It determines that it has no special security or 840 transport requirements for the message, but simply that it should 841 be transferred to the next downstream signalling application peer 842 on the path that the flow will take. 844 2. The message payload is passed to the GIST layer in GN1, along 845 with a definition of the flow and description of the message 846 transfer attributes (in this case, requesting no reliable 847 transmission or channel security protection). GIST determines 848 that this particular message does not require fragmentation and 849 that it has no knowledge of the next peer for this flow and 850 signalling application; however, it also determines that this 851 application is likely to require secured upstream and downstream 852 transport of large messages in the future. This determination is 853 a function of node-internal policy interactions between GIST and 854 the signalling application. 856 3. GN1 therefore constructs a GIST Query carrying the NSLP payload, 857 and additional payloads at the GIST level which will be used to 858 initiate a messaging association. The Query is encapsulated in a 859 UDP datagram and injected into the network. At the IP level, the 860 destination address is the flow receiver, and an IP Router Alert 861 Option (RAO) is also included.. 863 4. The Query passes through the network towards the flow receiver, 864 and is seen by each router in turn. GIST-unaware routers will 865 not recognise the RAO value and will forward the message 866 unchanged; GIST-aware routers which do not support the NSLP in 867 question will also forward the message basically unchanged, 868 although they may need to process more of the message to decide 869 this after initial interception. 871 5. The message is intercepted at GN2. The GIST layer identifies the 872 message as relevant to a local signalling application, and passes 873 the NSLP payload and flow description upwards to it. This 874 signalling application in GN2 indicates to GIST that it will peer 875 with GN1 and so GIST should proceed to set up any routing state. 876 In addition, the signalling application continues to process the 877 message as in GN1 (compare step 1), passing the message back down 878 to GIST so that it is sent further downstream, and this will 879 eventually result in the message reaching the flow receiver. 880 GIST itself operates hop-by-hop, and the signalling application 881 joins these hops together to manage the end-to-end signalling 882 operations. 884 6. In parallel, the GIST instance in GN2 now knows that it should 885 maintain routing state and a messaging association for future 886 signalling with GN1. This is recognised because the message is a 887 Query, and because the local signalling application has indicated 888 that it will peer with GN1. There are two possible cases for 889 sending back the necessary GIST Response: 891 6.A - Association Exists: GN1 and GN2 already have an 892 appropriate MA. GN2 simply records the identity of GN1 as its 893 upstream peer for that flow and NSLP, and sends a Response 894 back to GN1 over the MA identifying itself as the peer for 895 this flow. 897 6.B - No Association: GN2 sends the Response in D-mode directly 898 to GN1, identifying itself and agreeing to the messaging 899 association setup. The protocol exchanges needed to complete 900 this will proceed in parallel with the following stages. 902 In each case, the result is that GN1 and GN2 are now in a peering 903 relationship for the flow. 905 7. Eventually, another NSLP message works its way upstream from the 906 receiver to GN2. This message contains a description of the 907 actual resources requested, along with authorisation and other 908 security information. The signalling application in GN2 passes 909 this payload to the GIST level, along with the flow definition 910 and transfer attributes; in this case, it could request reliable 911 transmission and use of a secure channel for integrity 912 protection. (Other combinations of attributes are possible). 914 8. The GIST layer in GN2 identifies the upstream peer for this flow 915 and NSLP as GN1, and determines that it has an MA with the 916 appropriate properties. The message is queued on the MA for 917 transmission; this may incur some delay if the procedures begun 918 in step 6.B have not yet completed. 920 Further messages can be passed in each direction in the same way. 921 The GIST layer in each node can in parallel carry out maintenance 922 operations such as route change detection (see Section 7.1). 924 It should be understood that several of these details of GIST 925 operations can be varied, either by local policy or according to 926 signalling application requirements. The authoritative details are 927 contained in the remainder of this document. 929 4. GIST Processing Overview 931 This section defines the basic structure and operation of GIST. 932 Section 4.1 describes the way in which GIST interacts with local 933 signalling applications in the form of an abstract service interface. 934 Section 4.2 describes the per-flow and per-peer state that GIST 935 maintains for the purpose of transferring messages. Section 4.3 936 describes how messages are processed in the case where any necessary 937 messaging associations and routing state already exist; this includes 938 the simple scenario of pure D-mode operation, where no messaging 939 associations are necessary. Finally, Section 4.4 describes how 940 routing state and messaging associations are created and managed. 942 4.1. GIST Service Interface 944 This section describes the interaction between GIST and signalling 945 applications in terms of an abstract service interface, including a 946 definition of the attributes of the message transfer that GIST can 947 offer. The service interface presented here is non-normative and 948 does not constrain actual implementations of any interface between 949 GIST and signalling applications; the interface is provided to aid 950 understanding of how GIST can be used. However, requirements on SID 951 selection and internal GIST behaviour to support message transfer 952 semantics (such as in-order delivery) are stated normatively here. 954 The same service interface is presented at every GIST node; however, 955 applications may invoke it differently at different nodes, depending 956 for example on local policy. In addition, the service interface is 957 defined independently of any specific transport protocol, or even the 958 distinction between D-mode and C-mode. The initial version of this 959 specification defines how to support the service interface using a 960 C-mode based on TCP; if additional protocol support is added, this 961 will support the same interface and so the change will be invisible 962 to applications, except as a possible performance improvement. A 963 more detailed description of this service interface is given in 964 Appendix B. 966 4.1.1. Message Handling 968 Fundamentally, GIST provides a simple message-by-message transfer 969 service for use by signalling applications: individual messages are 970 sent, and individual messages are received. At the service 971 interface, the NSLP payload, which is opaque to GIST, is accompanied 972 by control information expressing the application's requirements 973 about how the message should be routed (the MRI), and the application 974 also provides the session identifier (SID), see Section 4.1.3. 975 Additional message transfer attributes control the specific transport 976 and security properties that the signalling application desires. 978 The distinction between GIST D- and C-mode is not visible at the 979 service interface. In addition, the functionality to handle 980 fragmentation and reassembly, bundling together of small messages for 981 efficiency, and congestion control are not visible at the service 982 interface; GIST will take whatever action is necessary based on the 983 properties of the messages and local node state. 985 A signalling application is free to choose the rate at which it 986 processes inbound messages; an implementation MAY allow the 987 application to block accepting messages from GIST. In these 988 circumstances, GIST MAY discard unreliably delivered messages, but 989 for reliable messages MUST propagate flow-control condition back to 990 the sender. Therefore, applications must be aware that they may in 991 turn be blocked from sending outbound messages themselves. 993 4.1.2. Message Transfer Attributes 995 Message transfer attributes are used by NSLPs to define minimum 996 required levels of message processing. The attributes available are 997 as follows: 999 Reliability: This attribute may be 'true' or 'false'. When 'true', 1000 the following rules apply: 1002 * messages MUST be delivered to the signalling application in the 1003 peer exactly once or not at all; 1005 * for messages with the same SID, the delivery MUST be in order; 1007 * if there is a chance that the message was not delivered (e.g. 1008 in the case of a transport layer error), an error MUST be 1009 indicated to the local signalling application identifying the 1010 routing information for the message in question. 1012 GIST implements reliability by using an appropriate transport 1013 protocol within a messaging association, so mechanisms for the 1014 detection of message loss depend on the protocol in question; for 1015 the current specification, the case of TCP is considered in 1016 Section 5.7.2. When 'false', a message may be delivered, once, 1017 several times or not at all, with no error indications in any 1018 case. 1020 Security: This attribute defines the set of security properties that 1021 the signalling application requires for the message, including the 1022 type of protection required, and what authenticated identities 1023 should be used for the signalling source and destination. This 1024 information maps onto the corresponding properties of the security 1025 associations established between the peers in C-mode. Keying 1026 material for the security associations is established by the 1027 authentication mechanisms within the messaging association 1028 protocols themselves; see Section 8.2. The attribute can be 1029 specified explicitly by the signalling application, or reported by 1030 GIST to the signalling application. The latter can take place 1031 either on receiving a message, or just before sending a message 1032 but after configuring or selecting the messaging association to be 1033 used for it. 1035 This attribute can also be used to convey information about any 1036 address validation carried out by GIST, such as whether a return 1037 routability check has been carried out. Further details are 1038 discussed in Appendix B. 1040 Local Processing: An NSLP may provide hints to GIST to enable more 1041 efficient or appropriate processing. For example, the NSLP may 1042 select a priority from a range of locally defined values to 1043 influence the sequence in which messages leave a node. Any 1044 priority mechanism MUST respect the ordering requirements for 1045 reliable messages within a session, and priority values are not 1046 carried in the protocol or available at the signalling peer or 1047 intermediate nodes. An NSLP may also indicate that upstream path 1048 routing state will not be needed for this flow, to inhibit the 1049 node requesting its downstream peer to create it; conversely, even 1050 if routing state exists, the NSLP may request that it is not used, 1051 which will lead to GIST Data messages being sent Q-mode 1052 encapsulated instead. 1054 A GIST implementation MAY deliver messages with stronger attribute 1055 values than those explicitly requested by the application. 1057 4.1.3. SID Selection 1059 The fact that SIDs index routing state (see Section 4.2.1 below) 1060 means that there are requirements for how they are selected. 1061 Specifically, signalling applications MUST choose SIDs so that they 1062 are cryptographically random, and SHOULD NOT use several SIDs for the 1063 same flow, to avoid additional load from routing state maintenance. 1064 Guidance on secure randomness generation can be found in [32]. 1066 4.2. GIST State 1068 4.2.1. Message Routing State 1070 For each flow, the GIST layer can maintain message routing state to 1071 manage the processing of outgoing messages. This state is 1072 conceptually organised into a table with the following structure. 1073 Each row in the table corresponds to a unique combination of the 1074 following three items: 1076 Message Routing Information (MRI): This defines the method to be 1077 used to route the message, the direction in which to send the 1078 message, and any associated addressing information; see 1079 Section 3.3. 1081 Session Identification (SID): The signalling session with which this 1082 message should be associated; see Section 3.7. 1084 NSLP Identification (NSLPID): This is an IANA-assigned identifier 1085 associated with the NSLP which is generating messages for this 1086 flow; see Section 3.8. The inclusion of this identifier allows 1087 the routing state to be different for different NSLPs. 1089 The information associated with a given {MRI,SID,NSLPID} triplet 1090 consists of the routing state to reach the peer in the direction 1091 given by the MRI. For any flow there will usually be two entries in 1092 the table, one each for the upstream and downstream MRI. The routing 1093 state includes information about the peer identity (see 1094 Section 4.4.3), and a UDP port number for D-mode, or a reference to 1095 one or more MAs for C-mode. Entries in the routing state table are 1096 created by the GIST handshake, which is described in more detail in 1097 Section 4.4. 1099 It is also possible for the state information for either direction to 1100 be empty. There are several possible cases: 1102 o The signalling application has indicated that no messages will 1103 actually be sent in that direction. 1105 o The node is the endpoint of the signalling path, for example 1106 because it is acting as a proxy, or because it has determined that 1107 there are no further signalling nodes in that direction. 1109 o The node is using other techniques to route the message. For 1110 example, it can send it in Q-mode and rely on the peer to 1111 intercept it. 1113 In particular, if the node is a flow endpoint, GIST will refuse to 1114 create routing state for the direction beyond the end of the flow 1115 (see Section 4.3.3). Each entry in the routing state table has an 1116 associated validity timer indicating for how long it can be 1117 considered accurate. When this timer expires, the entry MUST be 1118 purged if it has not been refreshed. Installation and maintenance of 1119 routing state is described in more detail in Section 4.4. 1121 4.2.2. Peer-Peer Messaging Association State 1123 The per-flow message routing state is not the only state stored by 1124 GIST. There is also the state required to manage the MAs. Since 1125 these are not per-flow, they are stored separately from the routing 1126 state, including the following per-MA information: 1128 o a queue of any messages that require the use of an MA, pending 1129 transmission while the MA is being established; 1131 o the time since the peer re-stated its desire to keep the MA open 1132 (see Section 4.4.5). 1134 In addition, per-MA state, such as TCP port numbers or timer 1135 information, is held in the messaging association protocols 1136 themselves. However, the details of this state are not directly 1137 visible to GIST, and they do not affect the rest of the protocol 1138 description. 1140 4.3. Basic GIST Message Processing 1142 This section describes how signalling application messages are 1143 processed in the case where any necessary messaging associations and 1144 routing state are already in place. The description is divided into 1145 several parts. Firstly, message reception, local processing and 1146 message transmission are described for the case where the node hosts 1147 the NSLPID identified in the message. Secondly, in Section 4.3.4, 1148 the case where the message is handled directly in the IP or GIST 1149 layer (because there is no matching signalling application on the 1150 node) is given. An overview is given in Figure 4. This section 1151 concentrates on the GIST level processing, with full details of IP 1152 and transport layer encapsulation in Section 5.3 and Section 5.4. 1154 +---------------------------------------------------------+ 1155 | >> Signalling Application Processing >> | 1156 | | 1157 +--------^---------------------------------------V--------+ 1158 ^ NSLP NSLP V 1159 ^ Payloads Payloads V 1160 +--------^---------------------------------------V--------+ 1161 | >> GIST >> | 1162 | ^ ^ ^ Processing V V V | 1163 +--x-----------N--Q---------------------Q--N-----------x--+ 1164 x N Q Q N x 1165 x N Q>>>>>>>>>>>>>>>>>>>>>Q N x 1166 x N Q Bypass at Q N x 1167 +--x-----+ +--N--Q--+ GIST level +--Q--N--+ +-----x--+ 1168 | C-mode | | D-mode | | D-mode | | C-mode | 1169 |Handling| |Handling| |Handling| |Handling| 1170 +--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+ 1171 x N Q Q N x 1172 x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x 1173 x N Q Bypass at Q N x 1174 +--x--N--+ +-----Q--+ IP (router +--Q-----+ +--N--x--+ 1175 |IP Host | | Q-mode | alert) level | Q-mode | |IP Host | 1176 |Handling| |Handling| |Handling| |Handling| 1177 +--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+ 1178 x N Q Q N x 1179 +--x--N-----------Q--+ +--Q-----------N--x--+ 1180 | IP Layer | | IP Layer | 1181 | (Receive Side) | | (Transmit Side) | 1182 +--x--N-----------Q--+ +--Q-----------N--x--+ 1183 x N Q Q N x 1184 x N Q Q N x 1186 NNNNNNNNNNNNNN = Normal D-mode messages 1187 QQQQQQQQQQQQQQ = D-mode messages which are Q-mode encapsulated 1188 xxxxxxxxxxxxxx = C-mode messages 1189 RAO = Router Alert Option 1191 Figure 4: Message Paths through a GIST Node 1193 4.3.1. Message Reception 1195 Messages can be received in C-mode or D-mode. 1197 Reception in C-mode is simple: incoming packets undergo the security 1198 and transport treatment associated with the MA, and the MA provides 1199 complete messages to the GIST layer for further processing. 1201 Reception in D-mode depends on the message type. 1203 Normal encapsulation: Normal messages arrive UDP-encapsulated and 1204 addressed directly to the receiving signalling node, at an address 1205 and port learned previously. Each datagram contains a single 1206 message which is passed to the GIST layer for further processing, 1207 just as in the C-mode case. 1209 Q-mode encapsulation: Where GIST is sending messages to be 1210 intercepted by the appropriate peer rather than directly addressed 1211 to it (in particular, Query messages), these are UDP encapsulated, 1212 and MAY include an IP router alert option (RAO) if required by the 1213 MRM. Each GIST node can therefore see every such message, but 1214 unless the message exactly matches the Q-mode encapsulation rules 1215 (Section 5.3.2) it MUST be forwarded transparently at the IP 1216 level. If it does match, GIST MUST check the NSLPID in the common 1217 header. The case where the NSLPID does not match a local 1218 signalling application at all is considered below in 1219 Section 4.3.4; otherwise, the message MUST be passed up to the 1220 GIST layer for further processing. 1222 Several different RAO values may be used by the NSIS protocol suite. 1223 GIST itself does not allocate any RAO values (for either IPv4 or 1224 IPv6); an assignment is made for each NSLP using MRMs that use the 1225 RAO in the Q-mode encapsulation. The assignment rationale is 1226 discussed in a separate document [13]. The RAO value assigned for an 1227 NSLPID may be different for IPv4 and IPv6. Note the different 1228 significance between the RAO and the NSLPID values: the meaning of a 1229 message (which signalling application it refers to, whether it should 1230 be processed at a node) is determined only from the NSLPID; the role 1231 of the RAO value is simply to allow nodes to pre-filter which IP 1232 datagrams are analysed to see if they might be Q-mode GIST messages. 1234 For all assignments associated with NSIS, the RAO specific processing 1235 is the same and is as defined by this specification, here and in 1236 Section 4.3.4 and Section 5.3.2. 1238 Immediately after reception, the GIST hop count is checked. Any 1239 message with a GIST hop count of zero MUST be rejected with a "Hop 1240 Limit Exceeded" error message (Appendix A.4.4.2); note that a correct 1241 GIST implementation will never send a message with a GIST hop count 1242 of zero. Otherwise, the GIST hop count MUST be decremented by one 1243 before the next stage. 1245 4.3.2. Local Processing and Validation 1247 Once a message has been received, it is processed locally within the 1248 GIST layer. Further processing depends on the message type and 1249 payloads carried; most of the GIST payloads are associated with 1250 internal state maintenance, and details are covered in Section 4.4. 1252 This section concentrates on the interaction with the signalling 1253 application, in particular the decision to peer and how data is 1254 delivered to the NSLP. 1256 In the case of a Query, there is an interaction with the signalling 1257 application to determine which of two courses to follow. The first 1258 option (peering) MUST be chosen if the node is the final destination 1259 of the Query message. 1261 1. The receiving signalling application wishes to become a 1262 signalling peer with the Querying node. GIST MUST continue with 1263 the handshake process to set up message routing state, as 1264 described in Section 4.4.1. The application MAY provide an NSLP 1265 payload for the same NSLPID, which GIST will transfer in the 1266 Response. 1268 2. The signalling application does not wish to set up state with the 1269 Querying node and become its peer. This includes the case where 1270 a node wishes to avoid taking part in the signalling for overload 1271 protection reasons. GIST MUST propagate the Query, similar to 1272 the case described in Section 4.3.4. No message is sent back to 1273 the Querying node. The application MAY provide an updated NSLP 1274 payload for the same NSLPID, which will be used in the Query 1275 forwarded by GIST. Note that if the node which finally processes 1276 the Query returns an Error message, this will be sent directly 1277 back to the originating node, bypassing any forwarders. For 1278 these diagnostics to be meaningful, any GIST node forwarding a 1279 Query, or relaying it with modified NSLP payload, MUST NOT modify 1280 it except in the GIST hop count; in particular, it MUST NOT 1281 modify any other GIST payloads or their order. An implementation 1282 MAY choose to achieve this by retaining the original message, 1283 rather than reconstructing it from some parsed internal 1284 representation. 1286 This interaction with the signalling application, including the 1287 generation or update of an NSLP payload, SHOULD take place 1288 synchronously as part of the Query processing. In terms of the GIST 1289 service interface, this can be implemented by providing appropriate 1290 return values for the primitive that is triggered when such a message 1291 is received; see Appendix B.2 for further discussion. 1293 For all GIST message types other than Queries, if the message 1294 includes an NSLP payload, this MUST be delivered locally to the 1295 signalling application identified by the NSLPID. The format of the 1296 payload is not constrained by GIST, and the content is not 1297 interpreted. Delivery is subject to the following validation checks 1298 which MUST be applied in the sequence given: 1300 1. if the message was explicitly routed (see Section 7.1.5) or is a 1301 Data message delivered without routing state (see Section 5.3.2), 1302 the payload is delivered but flagged to the receiving NSLP to 1303 indicate that routing state was not validated; 1305 2. else, if the message arrived on an association which is not 1306 associated with the MRI/NSLPID/SID combination given in the 1307 message, the message MUST be rejected with an "Incorrectly 1308 Delivered Message" error message (Appendix A.4.4.4); 1310 3. else, if there is no routing state for this MRI/SID/NSLPID the 1311 message MUST either be dropped or be rejected with a error 1312 message (see Section 4.4.6 for further details); 1314 4. else, the payload is delivered as normal. 1316 4.3.3. Message Transmission 1318 Signalling applications can generate their messages for transmission, 1319 either asynchronously, or in reply to an input message delivered by 1320 GIST, and GIST can also generate messages autonomously. GIST MUST 1321 verify that it is not the direct destination of an outgoing message, 1322 and MUST reject such messages with an error indication to the 1323 signalling application. When the message is generated by a 1324 signalling application, it may be carried in a Query if local policy 1325 and the message transfer attributes allow it; otherwise this may 1326 trigger setup of an MA over which the NSLP payload is sent in a Data 1327 message. 1329 Signalling applications may specify a value to be used for the GIST 1330 hop count; otherwise, GIST selects a value itself. GIST MUST reject 1331 messages for which the signalling application has specified a value 1332 of zero. Although the GIST hop count is only intended to control 1333 message looping at the GIST level, the GIST API (Appendix B) provides 1334 the incoming hop count to the NSLPs, which can preserve it on 1335 outgoing messages as they are forwarded further along the path. This 1336 provides a lightweight loop-control mechanism for NSLPs which do not 1337 define anything more sophisticated. Note that the count will be 1338 decremented on forwarding through every GIST-aware node. Initial 1339 values for the GIST hop count are an implementation matter; one 1340 suitable approach is to use the same algorithm as for IP TTL setting 1341 [1]. 1343 When a message is available for transmission, GIST uses internal 1344 policy and the stored routing state to determine how to handle it. 1345 The following processing applies equally to locally generated 1346 messages and messages forwarded from within the GIST or signalling 1347 application levels. However, see Section 5.6 for special rules 1348 applying to the transmission of error messages by GIST. 1350 The main decision is whether the message must be sent in C-mode or 1351 D-mode. Reasons for using C-mode are: 1353 o message transfer attributes: for example, the signalling 1354 application has specified security attributes that require 1355 channel-secured delivery, or reliable delivery. 1357 o message size: a message whose size (including the GIST header, 1358 GIST objects and any NSLP payload, and an allowance for the IP and 1359 transport layer encapsulation required by D-mode) exceeds a 1360 fragmentation-related threshold MUST be sent over C-mode, using a 1361 messaging association that supports fragmentation and reassembly 1362 internally. The allowance for IP and transport layer 1363 encapsulation is 64 bytes. The message size MUST NOT exceed the 1364 Path MTU to the next peer, if this is known. If this is not 1365 known, the message size MUST NOT exceed the least of the first-hop 1366 MTU, and 576 bytes. The same limit applies to IPv4 and IPv6. 1368 o congestion control: D-mode SHOULD NOT be used for signalling where 1369 it is possible to set up routing state and use C-mode, unless the 1370 network can be engineered to guarantee capacity for D-mode traffic 1371 within the rate control limits imposed by GIST (see 1372 Section 5.3.3). 1374 In principle, as well as determining that some messaging association 1375 must be used, GIST MAY select between a set of alternatives, e.g. for 1376 load sharing or because different messaging associations provide 1377 different transport or security attributes. For the case of reliable 1378 delivery, GIST MUST NOT distribute messages for the same session over 1379 multiple messaging associations in parallel, but MUST use a single 1380 association at any given time. The case of moving over to a new 1381 association is covered in Section 4.4.5. 1383 If the use of a messaging association (i.e. C-mode) is selected, the 1384 message is queued on the association found from the routing state 1385 table, and further output processing is carried out according to the 1386 details of the protocol stacks used. If no appropriate association 1387 exists, the message is queued while one is created (see 1388 Section 4.4.1), which will trigger the exchange of additional GIST 1389 messages. If no association can be created, this is an error 1390 condition, and should be indicated back to the local signalling 1391 application. 1393 If a messaging association is not appropriate, the message is sent in 1394 D-mode. The processing in this case depends on the message type, 1395 local policy, and whether routing state exists or not. 1397 o If the message is not a Query, and local policy does not request 1398 the use of Q-mode for this message, and routing state exists, it 1399 is sent with the normal D-mode encapsulation directly to the 1400 address from the routing state table. 1402 o If the message is a Query, or the message is Data and local policy 1403 as given by the message transfer attributes request the use of 1404 Q-mode, then it is sent in Q-mode as defined in Section 5.3.2; the 1405 details depend on the message routing method. 1407 o If no routing state exists, GIST can attempt to use Q-mode as in 1408 the Query case: either sending a Data message with the Q-mode 1409 encapsulation, or using the event as a trigger for routing state 1410 setup (see Section 4.4). If this is not possible, e.g. because 1411 the encapsulation for the MRM is only defined for one message 1412 direction, then this is an error condition which is reported back 1413 to the local signalling application. 1415 4.3.4. Nodes not Hosting the NSLP 1417 A node may receive messages where it has no signalling application 1418 corresponding to the message NSLPID. There are several possible 1419 cases depending mainly on the encapsulation: 1421 1. A message contains an RAO value which is relevant to NSIS, but it 1422 does not exactly match the Q-mode encapsulation rules of 1423 Section 5.3.2. The message MUST be transparently forwarded at 1424 the IP layer. See Section 3.6. 1426 2. A Q-mode encapsulated message contains an RAO value which has 1427 been assigned to some NSIS signalling application but which is 1428 not used on this specific node, but the IP layer is unable to 1429 distinguish whether it needs to be passed to GIST for further 1430 processing or whether the packet should be forwarded just like a 1431 normal IP datagram. 1433 3. A Q-mode encapsulated message contains an RAO value which has 1434 been assigned to an NSIS signalling application which is used on 1435 this node, but the signalling application does not process the 1436 NSLPID in the message. (This covers the case where a signalling 1437 application uses a set of NSLPIDs.) 1439 4. A directly addressed message (in D-mode or C-mode) is delivered 1440 to a node for which there is no corresponding signalling 1441 application. With the current specification, this should not 1442 happen in normal operation. While future versions might find a 1443 use for such a feature, currently this MUST cause an "Unknown 1444 NSLPID" error message, Appendix A.4.4.6. 1446 5. A Q-mode encapsulated message arrives at the end-system which 1447 does not handle the signalling application. This is possible in 1448 normal operation, and MUST be indicated to the sender with an 1449 "Endpoint Found" informational message (Appendix A.4.4.7). The 1450 end-system includes the MRI and SID from the original message in 1451 the error message without interpreting them. 1453 6. The node is GIST-aware NAT. See Section 7.2. 1455 In case (2) and (3), the role of GIST is to forward the message 1456 essentially as though it were a normal IP datagram, and it will not 1457 become a peer to the node sending the message. Forwarding with 1458 modified NSLP payloads is covered above in Section 4.3.2. However, a 1459 GIST implementation MUST ensure that the IP-layer TTL field and GIST 1460 hop count are managed correctly to prevent message looping, and this 1461 should be done consistently independently of where in the packet 1462 processing path the decision is mode. The rules are that in case 1463 (2), the IP-layer TTL MUST be decremented just as if the message was 1464 a normal IP forwarded packet. In cases (2), (3) and (4), the GIST 1465 hop count MUST be decremented as in the case of normal input 1466 processing. 1468 A GIST node processing Q-mode encapsulated messages in this way 1469 SHOULD make the routing decision based on the full contents of the 1470 MRI and not only the IP destination address. It MAY also apply a 1471 restricted set of sanity checks and under certain conditions return 1472 an error message rather than forward the message. These conditions 1473 are: 1475 1. The message is so large that it would be fragmented on downstream 1476 links, for example because the downstream MTU is abnormally small 1477 (less than 576 bytes). The error "Message Too Large" 1478 (Appendix A.4.4.8) SHOULD be returned to the sender, which SHOULD 1479 begin messaging association setup. 1481 2. The GIST hop count has reached zero. The error "Hop Limit 1482 Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender, 1483 which MAY retry with a larger initial hop count. 1485 3. The MRI represents a flow definition which is too general to be 1486 forwarded along a unique path (e.g. the destination address 1487 prefix is too short). The error "MRI Validation Failure" 1488 (Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be 1489 returned to the sender, which MAY retry with restricted MRIs, 1490 possibly starting additional signalling sessions to do so. If 1491 the GIST node does not understand the MRM in question it MUST NOT 1492 apply this check, instead forwarding the message transparently. 1494 In the first two cases, only the common header of the GIST message is 1495 examined; in the third case, the MRI is also examined. The rest of 1496 the message MUST NOT be inspected in any case. Similar to the case 1497 of Section 4.3.2, the GIST payloads MUST NOT be modified or re- 1498 ordered; an implementation MAY choose to achieve this by retaining 1499 the original message, rather than reconstructing it from some parsed 1500 internal representation. 1502 4.4. Routing State and Messaging Association Maintenance 1504 The main responsibility of GIST is to manage the routing state and 1505 messaging associations which are used in the message processing 1506 described above. Routing state is installed and refreshed by GIST 1507 handshake messages. Messaging associations are set up by the normal 1508 procedures of the transport and security protocols that comprise 1509 them, using peer IP addresses from the routing state. Once a 1510 messaging association has been created, its refresh and expiration 1511 can be managed independently from the routing state. 1513 There are two different cases for state installation and refresh: 1515 1. Where routing state is being discovered or a new association is 1516 to be established; and 1518 2. Where a suitable association already exists, including the case 1519 where routing state for the flow is being refreshed. 1521 These cases are now considered in turn, followed by the case of 1522 background general management procedures. 1524 4.4.1. Routing State and Messaging Association Creation 1526 The message sequence for GIST state setup between peers is shown in 1527 Figure 5 and described in detail below. The figure informally 1528 summarises the contents of each message, including optional elements 1529 in square brackets. An example is given in Appendix D. 1531 The first message in any routing state maintenance operation is a 1532 Query, sent from the querying node and intercepted at the responding 1533 node. This message has addressing and other identifiers appropriate 1534 for the flow and signalling application that state maintenance is 1535 being done for, addressing information about the node that generated 1536 the Query itself, and MAY contain an NSLP payload. It also includes 1537 a Query Cookie, and optionally capability information about messaging 1538 association protocol stacks. The role of the cookies in this and 1539 later messages is to protect against certain denial of service 1540 attacks and to correlate the events in the message sequence (see 1541 Section 8.5 for further details). 1543 +----------+ +----------+ 1544 | Querying | |Responding| 1545 | Node(Q-N)| | Node(R-N)| 1546 +----------+ +----------+ 1547 Query ............. 1548 ----------------------> . . 1549 Router Alert Option . Routing . 1550 MRI/SID/NSLPID . state . 1551 Q-N Network Layer Info . installed . 1552 Query Cookie . at . 1553 [Q-N Stack-Proposal . Responding. 1554 Q-N Stack-Config-Data] . node . 1555 [NSLP Payload] . (case 1) . 1556 ............. 1557 ...................................... 1558 . The responder can use an existing . 1559 . messaging association if available . 1560 . from here onwards to short-circuit . 1561 . messaging association setup . 1562 ...................................... 1564 Response 1565 ............. <---------------------- 1566 . Routing . MRI/SID/NSLPID 1567 . state . R-N Network Layer Info 1568 . installed . Query cookie 1569 . at . [Responder Cookie 1570 . Querying . [R-N Stack-Proposal 1571 . node . R-N Stack-Config-Data]] 1572 ............. [NSLP Payload] 1574 .................................... 1575 . If a messaging association needs . 1576 . to be created, it is set up here . 1577 . and the Confirm uses it . 1578 .................................... 1580 Confirm ............. 1581 ----------------------> . Routing . 1582 MRI/SID/NSLPID . state . 1583 Q-N Network Layer Info . installed . 1584 [Responder Cookie . at . 1585 [R-N Stack-Proposal . Responding. 1586 [Q-N Stack-Config-Data]]] . node . 1587 [NSLP Payload] . (case 2) . 1588 ............. 1590 Figure 5: Message Sequence at State Setup 1592 Provided that the signalling application has indicated that message 1593 routing state should be set up (see Section 4.3.2), reception of a 1594 Query MUST elicit a Response. This is a normally encapsulated D-mode 1595 message with additional GIST payloads. It contains network layer 1596 information about the responding node, echoes the Query Cookie, and 1597 MAY contain an NSLP payload, possibly a reply to the NSLP payload in 1598 the initial message. In case a messaging association was requested, 1599 it MUST also contain a Responder Cookie and its own capability 1600 information about messaging association protocol stacks. Even if a 1601 messaging association is not requested, the Response MAY still 1602 include a Responder Cookie if the node's routing state setup policy 1603 requires it (see below). 1605 Setup of a new messaging association begins when peer addressing 1606 information is available and a new messaging association is actually 1607 needed. Any setup MUST take place immediately after the specific 1608 Query/Response exchange, because the addressing information used may 1609 have a limited lifetime, either because it depends on limited 1610 lifetime NAT bindings or because it refers to agile destination ports 1611 for the transport protocols. The Stack-Proposal and Stack- 1612 Configuration-Data objects carried in the exchange carry capability 1613 information about what messaging association protocols can be used, 1614 and the processing of these objects is described in more detail in 1615 Section 5.7. With the protocol options currently defined, setup of 1616 the messaging association always starts from the Querying node, 1617 although more flexible configurations are possible within the overall 1618 GIST design. If the messaging association includes a channel 1619 security protocol, each GIST node MUST verify the authenticated 1620 identity of the peer against its authorised peer database, and if 1621 there is no match the messaging association MUST be torn down. The 1622 database and authorisation check are described in more detail in 1623 Section 4.4.2 below. Note that the verification can depend on what 1624 the MA is to be used for (e.g. for which MRI or session), so this 1625 step may not be possible immediately after authentication has 1626 completed but some time later. 1628 Finally, after any necessary messaging association setup has 1629 completed, a Confirm MUST be sent if the Response requested it. Once 1630 the Confirm has been sent, the Querying node assumes that routing 1631 state has been installed at the responder, and can send normal Data 1632 messages for the flow in question; recovery from a lost Confirm is 1633 discussed in Section 5.3.3. If a messaging association is being 1634 used, the Confirm MUST be sent over it before any other messages for 1635 the same flow, and it echoes the Responder Cookie and Stack-Proposal 1636 from the Response. The former is used to allow the receiver to 1637 validate the contents of the message (see Section 8.5), and the 1638 latter is to prevent certain bidding-down attacks on messaging 1639 association security (see Section 8.6). This first Confirm on a new 1640 association MUST also contain a Stack-Configuration-Data object 1641 carrying an MA-Hold-Time value, which supersedes the value given in 1642 the original Query. The association can be used in the upstream 1643 direction for the MRI and NSLPID carried in the Confirm, after the 1644 Confirm has been received. 1646 The querying node MUST install the responder address, derived from 1647 the R-Node Network Layer info, as routing state information after 1648 verifying the Query Cookie in the Response. The responding node MAY 1649 install the querying address as peer state information at two points 1650 in time: 1652 Case 1: after the receipt of the initial Query, or 1654 Case 2: after a Confirm containing the Responder Cookie. 1656 The responding node SHOULD derive the peer address from the Q-Node 1657 Network Layer Info if this was decoded successfully. Otherwise, it 1658 MAY be derived from the IP source address of the message if the 1659 common header flags this as being the signalling source address. The 1660 precise constraints on when state information is installed are a 1661 matter of security policy considerations on prevention of denial-of- 1662 service attacks and state poisoning attacks, which are discussed 1663 further in Section 8. Because the responding node MAY choose to 1664 delay state installation as in case (2), the Confirm must contain 1665 sufficient information to allow it to be processed in the same way as 1666 the original Query. This places some special requirements on NAT 1667 traversal and cookie functionality, which are discussed in 1668 Section 7.2 and Section 8 respectively. 1670 4.4.2. GIST Peer Authorisation 1672 When two GIST nodes authenticate using a messaging association, both 1673 ends have to decide whether to accept the creation of the MA and 1674 whether to trust the information sent over it. This can be seen as 1675 an authorisation decision: 1677 o Authorised peers are trusted to install correct routing state 1678 about themselves and not, for example, to claim that they are on- 1679 path for a flow when they are not. 1681 o Authorised peers are trusted to obey transport and application 1682 level flow control rules, and not to attempt to create overload 1683 situations. 1685 o Authorised peers are trusted not to send erroneous or malicious 1686 error messages, for example asserting that routing state has been 1687 lost when it has not. 1689 This specification models the decision as verification by the 1690 authorising node of the peer's identity against a local list of 1691 peers, the authorised peer database (APD). The APD is an abstract 1692 construct, similar to the security policy database of IPsec [37]. 1693 Implementations MAY provide the associated functionality in any way 1694 they choose. This section defines only the requirements for APD 1695 administration and the consequences of successfully validating a 1696 peer's identity against it. 1698 The APD consists of a list of entries. Each entry includes an 1699 identity, the namespace from which the identity comes (e.g. DNS 1700 domains), the scope within which the entry is applicable, and whether 1701 authorisation is allowed or denied. The following are example 1702 scopes: 1704 Peer Address Ownership: The scope is the IP address at which the 1705 peer for this MRI should be; the APD entry denotes the identity as 1706 the owner of address. If the authorising node can determine this 1707 address from local information (such as its own routing tables), 1708 matching this entry shows that the peer is the correct on-path 1709 node and so should be authorised. The determination is simple if 1710 the peer is one IP hop downstream, since the IP address can be 1711 derived from the router's forwarding tables. If the peer is more 1712 than one hop away or is upstream, the determination is harder but 1713 may still be possible in some circumstances. The authorising node 1714 may be able to determine a (small) set of possible peer addresses, 1715 and accept that any of these could be the correct peer. 1717 End-System Subnet: The scope is an address range within which the 1718 MRI source or destination lie; the APD entry denotes the identity 1719 as potentially being on-path between the authorising node and that 1720 address range. There may be different source and destination 1721 scopes, to account for asymmetric routing. 1723 The same identity may appear in multiple entries, and the order of 1724 entries in the APD is significant. When a messaging association is 1725 authenticated and associated with an MRI, the authorising node scans 1726 the APD to find the first entry where the identity matches that 1727 presented by the peer, and where the scope information matches the 1728 circumstances for which the MA is being set up. The identity 1729 matching process itself depends on the messaging association protocol 1730 that carries out the authentication, and details for TLS are given in 1731 Section 5.7.3. Whenever the full set of possible peers for a 1732 specific scope is known, deny entries SHOULD be added for the 1733 wildcard identity to reject signalling associations from unknown 1734 nodes. The ability of the authorising node to reject inappropriate 1735 MAs depends directly on the granularity of the APD and the precision 1736 of the scope matching process. 1738 If authorisation is allowed, the MA can be used as normal; otherwise 1739 it MUST be torn down without further GIST exchanges, and any routing 1740 state associated with the MA MUST also be deleted. An error 1741 condition MAY be logged locally. When an APD entry is modified or 1742 deleted, the node MUST re-validate existing MAs and the routing state 1743 table against the revised contents of the APD. This may result in 1744 MAs being torn down or routing state entries being deleted. These 1745 changes SHOULD be indicated to local signalling applications via the 1746 NetworkNotification API call (Appendix B.4). 1748 This specification does not define how the APD is populated. As a 1749 minimum, an implementation MUST provide an administrative interface 1750 through which entries can be added, modified, or deleted. More 1751 sophisticated mechanisms are possible in some scenarios. For 1752 example, the fact that a node is legitimately associated with a 1753 specific IP address could be established by direct embedding of the 1754 IP address as a particular identity type in a certificate, or by a 1755 mapping that address to another identifier type via an additional 1756 database lookup (such as relating IP addresses in in-addr.arpa to 1757 domain names). An enterprise network operator could generate a list 1758 of all the identities of its border nodes as authorised to be on the 1759 signalling path to external destinations, and this could be 1760 distributed to all hosts inside the network. Regardless of the 1761 technique, it MUST be ensured that the source data justify the 1762 authorisation decisions listed at the start of this section, and that 1763 the security of the chain of operations on which the APD entry 1764 depends cannot be compromised. 1766 4.4.3. Messaging Association Multiplexing 1768 It is a design goal of GIST that, as far as possible, a single 1769 messaging association should be used for multiple flows and sessions 1770 between two peers, rather than setting up a new MA for each. This 1771 re-use of existing MAs is referred to as messaging association 1772 multiplexing. Multiplexing ensures that the MA cost scales only with 1773 the number of peers, and avoids the latency of new MA setup where 1774 possible. 1776 However, multiplexing requires the identification of an existing MA 1777 which matches the same routing state and desired properties that 1778 would be the result of a normal handshake in D-mode, and this 1779 identification must be done as reliably and securely as continuing 1780 with this procedure. Note that this requirement is complicated by 1781 the fact that NATs may remap the node addresses in D-mode messages, 1782 and also interacts with the fact that some nodes may peer over 1783 multiple interfaces (and thus with different addresses). 1785 MA multiplexing is controlled by the Network-Layer-Information (NLI) 1786 object, which is carried in Query, Response and Confirm messages. 1787 The NLI object includes (among other elements): 1789 Peer-Identity: For a given node, this is an interface independent 1790 value with opaque syntax. It MUST be chosen so as to have a high 1791 probability of uniqueness across the set of all potential peers, 1792 and SHOULD be stable at least until the next node restart. Note 1793 that there is no cryptographic protection of this identity; 1794 attempting to provide this would essentially duplicate the 1795 functionality in the messaging association security protocols. 1796 For routers, the Router-ID [2], which is one of the router's IP 1797 addresses, MAY be used as one possible value for the Peer- 1798 Identity. In scenarios with nested NATs, the Router-ID alone may 1799 not satisfy the uniqueness requirements, in which case it MAY be 1800 extended with additional tokens, either chosen randomly or 1801 administratively coordinated. 1803 Interface-Address: This is an IP address through which the 1804 signalling node can be reached. There may be several choices 1805 available for the Interface-Address, and further discussion of 1806 this is contained in Section 5.2.2. 1808 A messaging association is associated with the NLI object that was 1809 provided by the peer in the Query/Response/Confirm at the time the 1810 association was first set up. There may be more than one MA for a 1811 given NLI object, for example with different security or transport 1812 properties. 1814 MA multiplexing is achieved by matching these two elements from the 1815 NLI provided in a new GIST message with one associated with an 1816 existing MA. The message can be either a Query or Response, although 1817 the former is more likely: 1819 o If there is a perfect match to an existing association, that 1820 association SHOULD be re-used, provided it meets the criteria on 1821 security and transport properties given at the end of 1822 Section 5.7.1. This is indicated by sending the remaining 1823 messages in the handshake over that association. This will lead 1824 to multiplexing on an association to the wrong node if signalling 1825 nodes have colliding Peer-Identities and one is reachable at the 1826 same Interface-Address as another. This could be caused by an on- 1827 path attacker; on-path attacks are discussed further in 1828 Section 8.7. When multiplexing is done, and the original MA 1829 authorisation was MRI-dependent, the verification steps of 1830 Section 4.4.2 MUST be repeated for the new flow. 1832 o In all other cases, the handshake MUST be executed in D-mode as 1833 usual. There are in fact four possibilities: 1835 1. Nothing matches: this is clearly a new peer. 1837 2. Only the Peer-Identity matches: this may be either a new 1838 interface on an existing peer, or a changed address mapping 1839 behind a NAT. These should be rare events, so the expense of 1840 a new association setup is acceptable. Another possibility is 1841 one node using another node's Peer-Identity, for example as 1842 some kind of attack. Because the Peer-Identity is used only 1843 for this multiplexing process, the only consequence this has 1844 is to require a new association setup, and this is considered 1845 in Section 8.4. 1847 3. Only the Interface-Address matches: this is probably a new 1848 peer behind the same NAT as an existing one. A new 1849 association setup is required. 1851 4. Both elements of the NLI object match: this is a degenerate 1852 case, where one node recognises an existing peer, but wishes 1853 to allow the option to set up a new association in any case, 1854 for example to create an association with different 1855 properties. 1857 4.4.4. Routing State Maintenance 1859 Each item of routing state expires after a lifetime which is 1860 negotiated during the Query/Response/Confirm handshake. The Network 1861 Layer Info (NLI) object in the Query contains a proposal for the 1862 lifetime value, and the NLI in the Response contains the value the 1863 Responding node requires. A default timer value of 30 seconds is 1864 RECOMMENDED. Nodes which can exploit alternative, more powerful, 1865 route change detection methods such as those described in 1866 Section 7.1.2 MAY choose to use much longer times. Nodes MAY use 1867 shorter times to provide more rapid change detection. If the number 1868 of active routing state items corresponds to a rate of Queries that 1869 will stress the rate limits applied to D-mode traffic 1870 (Section 5.3.3), nodes MUST increase the timer for new items and on 1871 the refresh of existing ones. A suitable value is 1872 2 * (number of routing states) / (rate limit in pkts/second) 1874 which leaves a factor of two headroom for new routing state creation 1875 and Query retransmissions. 1877 The Querying node MUST ensure that a Query is received before this 1878 timer expires, if it believes that the signalling session is still 1879 active; otherwise, the Responding node MAY delete the state. Receipt 1880 of the message at the Responding node will refresh peer addressing 1881 state for one direction, and receipt of a Response at the querying 1882 node will refresh it for the other. There is no mechanism at the 1883 GIST level for explicit teardown of routing state. However, GIST 1884 MUST NOT refresh routing state if a signalling session is known to be 1885 inactive, either because upstream state has expired, or because the 1886 signalling application has indicated via the GIST API (Appendix B.5) 1887 that the state is no longer required, because this would prevent 1888 correct state repair in the case of network rerouting at the IP 1889 layer. 1891 This specification defines precisely only the time at which routing 1892 state expires; it does not define when refresh handshakes should be 1893 initiated. Implementations MUST select timer settings which take at 1894 least the following into account: 1896 o The transmission latency between source and destination; 1898 o The need for retransmissions of Query messages; 1900 o The need to avoid network synchronisation of control traffic (cf. 1901 [43]). 1903 In most cases, a reasonable policy is to initiate the routing state 1904 refresh when between 1/2 and 3/4 of the validity time has elapsed 1905 since the last successful refresh. The actual moment MUST be chosen 1906 randomly within this interval to avoid synchronisation effects. 1908 4.4.5. Messaging Association Maintenance 1910 Unneeded MAs are torn down by GIST, using the teardown mechanisms of 1911 the underlying transport or security protocols if available, for 1912 example by simply closing a TCP connection. The teardown can be 1913 initiated by either end. Whether an MA is needed is a combination of 1914 two factors: 1916 o local policy, which could take into account the cost of keeping 1917 the messaging association open, the level of past activity on the 1918 association, and the likelihood of future activity, e.g. if there 1919 is routing state still in place which might generate messages to 1920 use it. 1922 o whether the peer still wants the MA to remain in place. During MA 1923 setup, as part of the Stack-Configuration-Data, each node 1924 advertises its own MA-Hold-Time, which is the time for which it 1925 will retain an MA which is not carrying signalling traffic. A 1926 node MUST NOT tear down an MA if it has received traffic from its 1927 peer over that period. A peer which has generated no traffic but 1928 still wants the MA retained can use a special null message (MA- 1929 Hello) to indicate the fact. A default value for MA-Hold-Time of 1930 30 seconds is RECOMMENDED. Nodes MAY use shorter times to achieve 1931 more rapid peer failure detection, but need to take into account 1932 the load on the network created by the MA-Hello messages. Nodes 1933 MAY use longer times, but need to take into account the cost of 1934 retaining idle MAs for extended periods. Nodes MAY take 1935 signalling application behaviour (e.g. NSLP refresh times) into 1936 account in choosing an appropriate value. 1938 Because the Responding node can choose not to create state until a 1939 Confirm, an abbreviated Stack-Configuration-Data object containing 1940 just this information from the initial Query MUST be repeated by 1941 the Querying node in the first Confirm sent on a new MA. If the 1942 object is missing in the Confirm, an "Object Type Error" message 1943 (Appendix A.4.4.9) with subcode 2 ("Missing Object") MUST be 1944 returned. 1946 Messaging associations can always be set up on demand, and messaging 1947 association status is not made directly visible outside the GIST 1948 layer. Therefore, even if GIST tears down and later re-establishes a 1949 messaging association, signalling applications cannot distinguish 1950 this from the case where the MA is kept permanently open. To 1951 maintain the transport semantics described in Section 4.1, GIST MUST 1952 close transport connections carrying reliable messages gracefully or 1953 report an error condition, and MUST NOT open a new association to be 1954 used for given session and peer while messages on a previous 1955 association could still be outstanding. GIST MAY use an MA-Hello 1956 request/reply exchange on an existing association to verify that 1957 messages sent on it have reached the peer. GIST MAY use the same 1958 technique to test the liveness of the underlying MA protocols 1959 themselves at arbitrary times. 1961 This specification defines precisely only the time at which messaging 1962 associations expires; it does not define when keepalives should be 1963 initiated. Implementations MUST select timer settings which take at 1964 least the following into account: 1966 o The transmission latency between source and destination; 1968 o The need for retransmissions within the messaging association 1969 protocols; 1971 o The need to avoid network synchronisation of control traffic (cf. 1972 [43]). 1974 In most cases, a reasonable policy is to initiate the MA refresh when 1975 between 1/2 and 3/4 of the validity time has elapsed since the last 1976 successful refresh. The actual moment MUST be chosen randomly within 1977 this interval to avoid synchronisation effects. 1979 4.4.6. Routing State Failures 1981 A GIST node can receive a message from a GIST peer, which can only be 1982 correctly processed in the context of some routing state, but where 1983 no corresponding routing state exists. Cases where this can arise 1984 include: 1986 o Where the message is random traffic from an attacker, or 1987 backscatter (replies to such traffic). 1989 o Where routing state has been correctly installed but the peer has 1990 since lost it, for example because of aggressive timeout settings 1991 at the peer, or because the node has crashed and restarted. 1993 o Where the routing state has never been correctly installed in the 1994 first place, but the sending node does not know this. This can 1995 happen if the Confirm message of the handshake is lost. 1997 It is important for GIST to recover from such situations promptly 1998 where they represent genuine errors (node restarts, or lost messages 1999 which would not otherwise be retransmitted). Note that only 2000 Response, Confirm, Error and Data messages ever require routing state 2001 to exist, and these are considered in turn: 2003 Response: A Response can be received at a node which never sent (or 2004 has forgotten) the corresponding Query. If the node wants routing 2005 state to exist, it will initiate it itself; a diagnostic error 2006 would not allow the sender of the Response to take any corrective 2007 action, and the diagnostic could itself be a form of backscatter. 2008 Therefore, an error message MUST NOT be generated, but the 2009 condition MAY be logged locally. 2011 Confirm: For a Responding node which implements delayed state 2012 installation, this is normal behaviour, and routing state will be 2013 created provided the Confirm is validated. Otherwise, this is a 2014 case of a non-existent or forgotten Response, and the node may not 2015 have sufficient information in the Confirm to create the correct 2016 state. The requirement is to notify the Querying node so that it 2017 can recover the routing state. 2019 Data: This arises when a node receives Data where routing state is 2020 required, but either it does not exist at all, or it has not been 2021 finalised (no Confirm message). To avoid Data being black-holed, 2022 a notification must be sent to the peer. 2024 Error: Some error messages can only be interpreted in the context of 2025 routing state. However, the only error messages which require a 2026 reply within the protocol are routing state error messages 2027 themselves. Therefore, this case should be treated the same as a 2028 Response: an error message MUST NOT be generated, but the 2029 condition MAY be logged locally. 2031 For the case of Confirm or Data messages, if the state is required 2032 but does not exist, the node MUST reject the incoming message with a 2033 "No Routing State" error message (Appendix A.4.4.5). There are then 2034 three cases at the receiver of the error message: 2036 No routing state: The condition MAY be logged but a reply MUST NOT 2037 be sent (see above). 2039 Querying node: The node MUST restart the GIST handshake from the 2040 beginning, with a new Query. 2042 Responding node: The node MUST delete its own routing state and 2043 SHOULD report an error condition to the local signalling 2044 application. 2046 The rules at the Querying or Responding node make GIST open to 2047 disruption by randomly injected error messages, similar to blind 2048 reset attacks on TCP (cf. [48]), although because routing state 2049 matching includes the SID this is mainly limited to on-path 2050 attackers. If a GIST node detects a significant rate of such 2051 attacks, it MAY adopt a policy of using secured messaging 2052 associations to communicate for the affected MRIs, and only accepting 2053 "No Routing State" error messages over such associations. 2055 5. Message Formats and Transport 2057 5.1. GIST Messages 2059 All GIST messages begin with a common header, followed by a sequence 2060 of type-length-value (TLV) objects. This subsection describes the 2061 various GIST messages and their contents at a high level in ABNF 2062 [12]; a more detailed description of the header and each object is 2063 given in Section 5.2 and bit formats in Appendix A. Note that the 2064 NAT traversal mechanism for GIST involves the insertion of an 2065 additional NAT-Traversal-Object in Query, Response, and some Data and 2066 Error messages; the rules for this are given in Section 7.2. 2068 GIST-Message: The primary messages are either part of the three-way 2069 handshake, or a simple message carrying NSLP data. Additional types 2070 are defined for errors and keeping messaging associations alive. 2071 GIST-Message = Query / Response / Confirm / 2072 Data / Error / MA-Hello 2074 The common header includes a version number, message type and size, 2075 and NSLPID. It also carries a hop count to prevent infinite message 2076 looping and various control flags, including one (the R flag) to 2077 indicate if a reply of some sort is requested. The objects following 2078 the common header MUST be carried in a fixed order, depending on 2079 message type. Messages with missing, duplicate or invalid objects 2080 for the message type MUST be rejected with an "Object Type Error" 2081 message with the appropriate subcode (Appendix A.4.4.9). 2083 Query: A Query MUST be sent in D-mode using the special Q-mode 2084 encapsulation. In addition to the common header, it contains certain 2085 mandatory control objects, and MAY contain a signalling application 2086 payload. A stack proposal and configuration data MUST be included if 2087 the message exchange relates to setup of a messaging association, and 2088 this is the case even if the Query is intended only for refresh 2089 (since a routing change might have taken place in the meantime). The 2090 R flag MUST always be set (R=1) in a Query, since this message always 2091 elicits a Response. 2092 Query = Common-Header 2093 [ NAT-Traversal-Object ] 2094 Message-Routing-Information 2095 Session-Identification 2096 Network-Layer-Information 2097 Query-Cookie 2098 [ Stack-Proposal Stack-Configuration-Data ] 2099 [ NSLP-Data ] 2101 Response: A Response MUST be sent in D-mode if no existing messaging 2102 association can be re-used. If one is being re-used, the Response 2103 MUST be sent in C-mode. It MUST echo the MRI, SID and Query-Cookie 2104 of the Query, and carries its own Network-Layer-Information. If the 2105 message exchange relates to setup of a new messaging association, 2106 which MUST involve a D-mode Response, a Responder cookie MUST be 2107 included, as well as the Responder's own stack proposal and 2108 configuration data. The R flag MUST be set (R=1) if a Responder 2109 cookie is present but otherwise is optional; if the R flag is set, a 2110 Confirm MUST be sent as a reply. Therefore, in particular, a Confirm 2111 will always be required if a new MA is being set up. Note that the 2112 direction of this MRI will be inverted compared to that in the Query, 2113 that is, an upstream MRI becomes downstream and vice versa (see 2114 Section 3.3). 2115 Response = Common-Header 2116 [ NAT-Traversal-Object ] 2117 Message-Routing-Information 2118 Session-Identification 2119 Network-Layer-Information 2120 Query-Cookie 2121 [ Responder-Cookie 2122 [ Stack-Proposal Stack-Configuration-Data ] ] 2123 [ NSLP-Data ] 2125 Confirm: A Confirm MUST be sent in C-mode if a messaging association 2126 is being used for this routing state, and MUST be sent before other 2127 messages for this routing state if an association is being set up. 2128 If no messaging association is being used, the Confirm MUST be sent 2129 in D-mode. The Confirm MUST include the MRI (with inverted 2130 direction) and SID, and echo the Responder-Cookie if the Response 2131 carried one. In C-mode, the Confirm MUST also echo the Stack- 2132 Proposal from the Response (if present) so it can be verified that 2133 this has not been tampered with. The first Confirm on a new 2134 association MUST also repeat the Stack-Configuration-Data from the 2135 original Query in an abbreviated form, just containing the MA-Hold- 2136 Time. 2137 Confirm = Common-Header 2138 Message-Routing-Information 2139 Session-Identification 2140 Network-Layer-Information 2141 [ Responder-Cookie 2142 [ Stack-Proposal 2143 [ Stack-Configuration-Data ] ] ] 2144 [ NSLP-Data ] 2146 Data: The Data message is used to transport NSLP data without 2147 modifying GIST state. It contains no control objects, but only the 2148 MRI and SID associated with the NSLP data being transferred. 2149 Network-Layer-Information (NLI) MUST be carried in the D-mode case, 2150 but MUST NOT be included otherwise. 2152 Data = Common-Header 2153 [ NAT-Traversal-Object ] 2154 Message-Routing-Information 2155 Session-Identification 2156 [ Network-Layer-Information ] 2157 NSLP-Data 2159 Error: An Error message reports a problem determined at the GIST 2160 level. (Errors generated by signalling applications are reported in 2161 NSLP-Data payloads and are not treated specially by GIST.) If the 2162 message is being sent in D-mode, the originator of the error message 2163 MUST include its own Network-Layer-Information object. All other 2164 information related to the error is carried in a GIST-Error-Data 2165 object. 2166 Error = Common-Header 2167 [ NAT-Traversal-Object ] 2168 [ Network-Layer-Information ] 2169 GIST-Error-Data 2171 MA-Hello: This message MUST be sent only in C-mode. It contains the 2172 common header, with a NSLPID of zero, and a message identifier, the 2173 Hello-ID. It always indicates that a node wishes to keep a messaging 2174 association open, and if sent with R=0 and zero Hello-ID this is its 2175 only function. A node MAY also invoke a diagnostic request/reply 2176 exchange by setting R=1 and providing a non-zero Hello-ID; if this 2177 case, the peer MUST send another MA-Hello back along the messaging 2178 association echoing the same Hello-ID and with R=0. Use of this 2179 diagnostic is entirely at the discretion of the initiating node. 2180 MA-Hello = Common-Header 2181 Hello-ID 2183 5.2. Information Elements 2185 This section describes the content of the various objects that can be 2186 present in each GIST message, both the common header, and the 2187 individual TLVs. The bit formats are provided in Appendix A. 2189 5.2.1. The Common Header 2191 Each message begins with a fixed format common header, which contains 2192 the following information: 2194 Version: The version number of the GIST protocol. This 2195 specification defines GIST version 1. 2197 GIST hop count: A hop count to prevent a message from looping 2198 indefinitely. 2200 Length: The number of 32 bit words in the message following the 2201 common header. 2203 Upper layer identifier (NSLPID): This gives the specific NSLP that 2204 this message is used for. 2206 Context-free flag: This flag is set (C=1) if the receiver has to be 2207 able to process the message without supporting routing state. The 2208 C-flag MUST be set for Query messages, and also for Data messages 2209 sent in Q-mode. The C-flag is important for NAT traversal 2210 processing. 2212 Message type: The message type (Query, Response, etc.) 2214 Source addressing mode: If set (S=1), this indicates that the IP 2215 source address of the message is the same as the IP address of the 2216 signalling peer, so replies to this message can be sent safely to 2217 this address. S is always set in C-mode. It is cleared (S=0) if 2218 the IP source address was derived from the message routing 2219 information in the payload and this is different from the 2220 signalling source address. 2222 Response requested: A flag which if set (R=1) indicates that a GIST 2223 message should be sent in reply to this message. The appropriate 2224 message type for the reply depends on the type of the initial 2225 message. 2227 Explicit routing: A flag which if set (E=1) indicates that the 2228 message was explicitly routed (see Section 7.1.5). 2230 Note that in D-mode, Section 5.3, there is a 32-bit magic number 2231 before the header. However, this is regarded as part of the 2232 encapsulation rather than part of the message itself. 2234 5.2.2. TLV Objects 2236 All data following the common header is encoded as a sequence of 2237 type-length-value objects. Currently, each object can occur at most 2238 once; the set of required and permitted objects is determined by the 2239 message type and encapsulation (D-mode or C-mode). 2241 Message-Routing-Information (MRI): Information sufficient to define 2242 how the signalling message should be routed through the network. 2244 Message-Routing-Information = message-routing-method 2245 method-specific-information 2247 The format of the method-specific-information depends on the 2248 message-routing-method requested by the signalling application. 2249 Note that it always includes a flag defining the direction as 2250 either 'upstream' or 'downstream' (see Section 3.3). It is 2251 provided by the NSLP in the message sender and used by GIST to 2252 select the message routing. 2254 Session-Identification (SID): The GIST session identifier is a 128 2255 bit, cryptographically random identifier chosen by the node which 2256 originates the signalling exchange. See Section 3.7. 2258 Network-Layer-Information (NLI): This object carries information 2259 about the network layer attributes of the node sending the 2260 message, including data related to the management of routing 2261 state. This includes a peer identity and IP address for the 2262 sending node. It also includes IP-TTL information to allow the IP 2263 hop count between GIST peers to be measured and reported, and a 2264 validity time (RS-validity-time) for the routing state. 2266 Network-Layer-Information = peer-identity 2267 interface-address 2268 RS-validity-time 2269 IP-TTL 2271 The use of the RS-validity-time field is described in 2272 Section 4.4.4. The peer-identity and interface-address are used 2273 for matching existing associations, as discussed in Section 4.4.3. 2275 The interface-address must be routable, i.e. it MUST be usable as 2276 a destination IP address for packets to be sent back to the node 2277 generating the signalling message, whether in D-mode or C-mode. 2278 If this object is carried in a message with the source addressing 2279 mode flag S=1, the interface-address MUST match the source address 2280 used in the IP encapsulation, to assist in legacy NAT detection 2281 (Section 7.2.1). If this object is carried in a Query or Confirm, 2282 the interface-address MUST specifically be set to an address bound 2283 to an interface associated with the MRI, to allow its use in route 2284 change handling as discussed in Section 7.1. A suitable choice is 2285 the interface that is carrying the outbound flow. A node may have 2286 several choices for which of its addresses to use as the 2287 interface-address. For example, there may be a choice of IP 2288 versions, or addresses of limited scope (e.g. link-local), or 2289 addresses bound to different interfaces in the case of a router or 2290 multi-homed host. However, some of these interface addresses may 2291 not be usable by the peer. A node MUST follow a policy of using a 2292 global address of the same IP version as in the MRI, unless it can 2293 establish that an alternative address would also be usable. 2295 The setting and interpretation of the IP-TTL field depends on the 2296 message direction (upstream/downstream as determined from the MRI 2297 as described above) and encapsulation. 2299 * If the message is sent downstream, if the TTL that will be set 2300 in the IP header for the message can be determined, the IP-TTL 2301 value MUST be set to this value, or else set to 0. 2303 * On receiving a downstream message in D-mode, a non-zero IP-TTL 2304 is compared to the TTL in the IP header, and the difference is 2305 stored as the IP-hop-count-to-peer for the upstream peer in the 2306 routing state table for that flow. Otherwise, the field is 2307 ignored. 2309 * If the message is sent upstream, the IP-TTL MUST be set to the 2310 value of the IP-hop-count-to-peer stored in the routing state 2311 table, or 0 if there is no value yet stored. 2313 * On receiving an upstream message, the IP-TTL is stored as the 2314 IP-hop-count-to-peer for the downstream peer. 2316 In all cases, the IP-TTL value reported to signalling applications 2317 is the one stored with the routing state for that flow, after it 2318 has been updated if necessary from processing the message in 2319 question. 2321 Stack-Proposal: This field contains information about which 2322 combinations of transport and security protocols are available for 2323 use in messaging associations, and is also discussed further in 2324 Section 5.7. 2326 Stack-Proposal = 1*stack-profile 2328 stack-profile = protocol-count 1*protocol-layer 2329 ;; padded on the right with 0 to 32 bit boundary 2330 protocol-count = %x01-FF 2331 ;; number of the following , 2332 ;; represented as one byte. This doesn't include 2333 ;; padding. 2335 Each protocol-layer field identifies a protocol with a unique tag; 2336 any additional data, such as higher-layer addressing or other 2337 options data associated with the protocol, will be carried in a 2338 MA-protocol-options field in the Stack-Configuration-Data TLV (see 2339 below). 2341 Stack-Configuration-Data (SCD): This object carries information 2342 about the overall configuration of a messaging association. 2344 Stack-Configuration-Data = MA-Hold-Time 2345 0*MA-protocol-options 2347 The MA-Hold-Time field indicates how long a node will hold open an 2348 inactive association; see Section 4.4.5 for more discussion. The 2349 MA-protocol-options fields give the configuration of the protocols 2350 (e.g. TCP, TLS) to be used for new messaging associations, and 2351 they are described in more detail in Section 5.7. 2353 Query-Cookie/Responder-Cookie: A Query-Cookie is contained in a 2354 Query and MUST be echoed in a Response; a Responder-Cookie MAY be 2355 sent in a Response, and if present MUST be echoed in the following 2356 Confirm. Cookies are variable length bit strings, chosen by the 2357 cookie generator. See Section 8.5 for further details on 2358 requirements and mechanisms for cookie generation. 2360 Hello-ID: The Hello-ID is a 32-bit quantity that is used to 2361 correlate messages in an MA-Hello request/reply exchange. A non- 2362 zero value MUST be used in a request (messages sent with R=1) and 2363 the same value must be returned in the reply (which has R=0). The 2364 value zero MUST be used for all other messages; if a message is 2365 received with R=1 and Hello-ID=0, an "Object Value Error" message 2366 (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") MUST be 2367 returned and the message dropped. Nodes MAY use any algorithm to 2368 generate the Hello-ID; a suitable approach is a local sequence 2369 number with a random starting point. 2371 NSLP-Data: The NSLP payload to be delivered to the signalling 2372 application. GIST does not interpret the payload content. 2374 GIST-Error-Data: This contains the information to report the cause 2375 and context of an error. 2377 GIST-Error-Data = error-class error-code error-subcode 2378 common-error-header 2379 [ Message-Routing-Information-content ] 2380 [ Session-Identification-content ] 2381 0*additional-information 2382 [ comment ] 2384 The error-class indicates the severity level, and the error-code 2385 and error-subcode identify the specific error itself. A full list 2386 of GIST errors and their severity levels is given in Appendix A.4. 2388 The common-error-header carries the Common-Header from the 2389 original message, and contents of the Message-Routing-Information 2390 (MRI) and Session-Identification (SID) objects are also included 2391 if they were successfully decoded. For some errors, additional 2392 information fields can be included, and these fields themselves 2393 have a simple TLV format. Finally, an optional free-text comment 2394 may be added. 2396 5.3. D-mode Transport 2398 This section describes the various encapsulation options for D-mode 2399 messages. Although there are several possibilities, depending on 2400 message type, MRM, and local policy, the general design principle is 2401 that the sole purpose of the encapsulation is to ensure that the 2402 message is delivered to or intercepted at the correct peer. Beyond 2403 that, minimal significance is attached to the type of encapsulation 2404 or the values of addresses or ports used for it. This allows new 2405 options to be developed in the future to handle particular deployment 2406 requirements without modifying the overall protocol specification. 2408 5.3.1. Normal Encapsulation 2410 Normal encapsulation MUST be used for all D-mode messages where the 2411 signalling peer is already known from previous signalling. This 2412 includes Response and Confirm messages, and Data messages except if 2413 these are being sent without using local routing state. Normal 2414 encapsulation is simple: the message is carried in a single UDP 2415 datagram. UDP checksums MUST be enabled. The UDP payload MUST 2416 always begin with a 32 bit magic number with value 0x4e04 bda5 in 2417 network byte order; this is followed by the GIST common header and 2418 the complete set of payloads. If the magic number is not present, 2419 the message MUST be silently dropped. The normal encapsulation is 2420 shown in outline in Figure 6. 2422 0 1 2 3 2423 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 2424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2425 // IP Header // 2426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2427 // UDP Header // 2428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2429 | GIST Magic Number (0x4e04bda5) | 2430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 // GIST Common Header // 2432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2433 // GIST Payloads // 2434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 Figure 6: Normal Encapsulation Packet Format 2438 The message is IP addressed directly to the adjacent peer as given by 2439 the routing state table. Where the message is a direct reply to a 2440 Query and no routing state exists, the destination address is derived 2441 from the input message using the same rules as in Section 4.4.1. The 2442 UDP port numbering MUST be compatible with that used on Query 2443 messages (see below), that is, the same for messages in the same 2444 direction and with source and destination port numbers swapped for 2445 messages in the opposite direction. Normally encapsulated messages 2446 MUST be sent with source addressing mode flag S=1 unless the message 2447 is a reply to a message which is known to have passed through a NAT, 2448 and the receiver MUST check the IP source address with the interface- 2449 address given in the NLI as part of legacy NAT detection. Both these 2450 aspects of message processing are discussed further in Section 7.2.1. 2452 5.3.2. Q-mode Encapsulation 2454 Q-mode encapsulation MUST be used for messages where no routing state 2455 is available or where the routing state is being refreshed, in 2456 particular for Query messages. Q-mode can also be used when 2457 requested by local policy. Q-mode encapsulation is similar to normal 2458 encapsulation, with changes in IP address selection, rules about IP 2459 options, and a defined method for selecting UDP ports. 2461 It is an essential property of the Q-mode encapsulation that it is 2462 possible for a GIST node to intercept these messages efficiently even 2463 when they are not directly addressed to it; and conversely that it is 2464 possible for a non-GIST node to ignore these messages without 2465 overloading the slow path packet processing. This document specifies 2466 that interception is done on the basis RAOs. 2468 5.3.2.1. Encapsulation and Interception in IPv4 2470 In general, the IP addresses are derived from information in the MRI; 2471 the exact rules depend on the MRM. For the case of messages with 2472 source addressing mode flag S=1, the receiver MUST check the IP 2473 source address with the interface-address given in the NLI as part of 2474 legacy NAT detection, see Section 7.2.1. 2476 Current MRMs define the use of a Router Alert Option [14] to assist 2477 the peer in intercepting the message depending on the NSLPID. If the 2478 MRM defines the use of RAO, the sender MUST include it unless it has 2479 been specifically configured not to (see below). A node MAY make the 2480 initial interception decision based purely on IP-Protocol number 2481 transport header analysis. Implementations MAY provide an option to 2482 disable the setting of RAO on Q-mode packets on a per-destination 2483 prefix basis; however, the option MUST be disabled by default and 2484 MUST only be enabled when it has been separately verified that the 2485 the next GIST node along the path to the destination is capable of 2486 intercepting packets without RAO. The purpose of this option is to 2487 allow operation across networks which do not properly support RAO; 2488 further details are discussed in Appendix C. 2490 It is likely that fragmented datagrams will not be correctly 2491 intercepted in the network, since the checks that a datagram is a 2492 Q-mode packet depend on data beyond the IP header. Therefore the 2493 sender MUST set the Don't Fragment (DF) bit in the IPv4 header. Note 2494 that ICMP "packet too large" messages will be sent to the source 2495 address of the original IP datagram, and since all MRM definitions 2496 recommend S=1 for at least some retransmissions, ICMP errors related 2497 to fragmentation will be seen at the Querying node. 2499 The upper layer protocol, identified by the IP-Protocol field in the 2500 IP header, MUST be UDP. 2502 5.3.2.2. Encapsulation and Interception in IPv6 2504 As for IPv4, the IP addresses are derived from information in the 2505 MRI; the exact rules depend on the MRM. For the case of messages 2506 with source addressing mode flag S=1, the receiver MUST check the IP 2507 source address with the interface-address given in the NLI as part of 2508 legacy NAT detection, see Section 7.2.1. 2510 For all current MRMs, the IP header is given a Router Alert Option 2511 [8] to assist the peer in intercepting the message depending on the 2512 NSLPID. If the MRM defines the use of RAO, the sender MUST include 2513 it without exception. It is RECOMMENDED that a node bases its 2514 initial interception decision purely on the presence of a hop-by-hop 2515 option header containing the RAO, which will be at the start of the 2516 header chain. 2518 The upper layer protocol MUST be UDP without intervening 2519 encapsulation layers. Following any hop-by-hop option header, the IP 2520 header MUST NOT include any extension headers other than routing or 2521 destination options [6], and for the last extension header MUST have 2522 a next-header field of UDP. 2524 5.3.2.3. Upper Layer Encapsulation and Overall Interception 2525 Requirements 2527 For both IP versions, the above rules require that the upper layer 2528 protocol identified by the IP header MUST be UDP. Other packets MUST 2529 NOT be identified as GIST Q-mode packets; this includes IP-in-IP 2530 tunnelled packets, other tunnelled packets (tunnel mode AH/ESP), or 2531 packets which have undergone some additional transport layer 2532 processing (transport mode AH/ESP). If IP output processing at the 2533 originating node or an intermediate router causes such additional 2534 encapsulations to be added to a GIST Q-mode packet, this packet will 2535 not be identified as GIST until the encapsulation is terminated. If 2536 the node wishes to signal for data over the network region where the 2537 encapsulation applies, it MUST generate additional signalling with an 2538 MRI matching the encapsulated traffic, and the outbound GIST Q-mode 2539 messages for it MUST bypass the encapsulation processing. 2541 Therefore, the final stage of the interception process and the final 2542 part of encapsulation is at the UDP level. The source UDP port is 2543 selected by the message sender as the port at which it is prepared to 2544 receive UDP messages in reply, and the sender MUST use the 2545 destination UDP port allocated for GIST by IANA (see Section 9). 2546 Note that for some MRMs, GIST nodes anywhere along the path can 2547 generate GIST packets with source addresses that spoof the source 2548 address of the data flow. Therefore, destinations cannot distinguish 2549 these packets from genuine end-to-end data purely on address 2550 analysis. Instead, it must be possible to distinguish such GIST 2551 packets by port analysis; furthermore, the mechanism to do so must 2552 remain valid even if the destination is GIST-unaware. GIST solves 2553 this problem by using a fixed destination UDP port from the "well 2554 known" space for the Q-mode encapsulation. This port should never be 2555 allocated on a GIST-unaware host, and therefore Q-mode encapsulated 2556 messages should always be rejected with an ICMP error. The usage of 2557 this destination port by other applications will result in reduced 2558 performance due to increased delay and packet drop rates due to their 2559 interception by GIST nodes. 2561 A GIST node will need to be capable to filter out all IP/UDP packets 2562 that has an UDP destination port number equal to the one registered 2563 for GIST Q-mode encapsulation on the IP-level it operates. These 2564 packets should then be further verified to be GIST packets by 2565 checking the magic number (see Section 5.3.1). The packets that 2566 meets both port and magic number requirement are further processed as 2567 GIST Q-mode packets. Any filtered packets that fails this GIST magic 2568 word check SHOULD be forwarded towards the IP packets destination 2569 with best possible effort. A GIST node is RECOMMENDED as protection 2570 against denial of service attacks to have a rate limiter preventing 2571 more packets (filtered as potential Q-mode packets) then the system 2572 can handle safely to be processed. Any excessive packets SHOULD be 2573 discarded. 2575 5.3.2.4. IP Option Processing 2577 For both IPv4 and IPv6, for Q-mode packets with IP options allowed by 2578 the above requirements, IP options processing is intended to be 2579 carried out independently of GIST processing. Note that for the 2580 options allowed by the above rules, the option semantics are 2581 independent of the payload: UDP payload modifications are not 2582 prevented by the options and do not affect the option content, and 2583 conversely the presence of the options does not affect the UDP 2584 payload. 2586 On packets originated by GIST, IP options MAY be added according to 2587 node-local policies on outgoing IP data. On packets forwarded by 2588 GIST without NSLP processing, IP options MUST be processed as for a 2589 normally forwarded IP packet. On packets locally delivered to the 2590 NSLP, the IP options MAY be passed to the NSLP and equivalent options 2591 used on subsequently generated outgoing Q-mode packets. In this 2592 case, routing related options SHOULD be processed identically as they 2593 would be for a normally forwarded IP packet. 2595 5.3.3. Retransmission and Rate Control 2597 D-mode uses UDP, and hence has no automatic reliability or congestion 2598 control capabilities. Signalling applications requiring reliability 2599 should be serviced using C-mode, which should also carry the bulk of 2600 signalling traffic. However, some form of messaging reliability is 2601 required for the GIST control messages themselves, as is rate control 2602 to handle retransmissions and also bursts of unreliable signalling or 2603 state setup requests from the signalling applications. 2605 Query messages which do not receive Responses MAY be retransmitted; 2606 retransmissions MUST use a binary exponential backoff. The initial 2607 timer value is T1, which the backoff process can increase up to a 2608 maximum value of T2 seconds. The default value for T1 is 500 ms. T1 2609 is an estimate of the round-trip time between the querying and 2610 responding nodes. Nodes MAY use smaller values of T1 if it is known 2611 that the Query should be answered within the local network. T1 MAY 2612 be chosen larger, and this is RECOMMENDED if it is known in advance 2613 (such as on high latency access links) that the round-trip time is 2614 larger. The default value of T2 is 64*T1. Note that Queries may go 2615 unanswered either because of message loss (in either direction), or 2616 because there is no reachable GIST peer. Therefore, implementations 2617 MAY trade off reliability (large T2) against promptness of error 2618 feedback to applications (small T2). If the NSLP has indicated a 2619 timeout on the validity of this payload (see Appendix B.1), T2 MUST 2620 be chosen so that the process terminates within this timeout. 2621 Retransmitted Queries MUST use different Query-Cookie values. If the 2622 Query carries NSLP data, it may be delivered multiple times to the 2623 signalling application. These rules apply equally to the message 2624 that first creates routing state, and those that refresh it. In all 2625 cases, Responses MUST be sent promptly to avoid spurious 2626 retransmissions. Nodes generating any type of retransmission MUST be 2627 prepared to receive and match a reply to any of them, not just the 2628 one most recently sent. Although a node SHOULD terminate its 2629 retransmission process when any reply is received, it MUST continue 2630 to process further replies as normal. 2632 This algorithm is sufficient to handle lost Queries and Responses. 2633 The case of a lost Confirm is more subtle. The Responding node MAY 2634 run a retransmission timer to resend the Response until a Confirm is 2635 received; the timer MUST use the same backoff mechanism and 2636 parameters as for Responses. The problem of an amplification attack 2637 stimulated by a malicious Query is handled by requiring the cookie 2638 mechanism to enable the node receiving the Response to discard it 2639 efficiently if it does not match a previously sent Query. This 2640 approach is only appropriate if the Responding node is prepared to 2641 store per-flow state after receiving a single (Query) message, which 2642 includes the case where the node has queued NSLP data. If the 2643 Responding node has delayed state installation, the error condition 2644 will only be detected when a Data message arrives. This is handled 2645 as a routing state error (see Section 4.4.6) which causes the 2646 Querying node to restart the handshake. 2648 The basic rate-control requirements for D-mode traffic are 2649 deliberately minimal. A single rate limiter applies to all traffic, 2650 for all interfaces and message types. It applies to retransmissions 2651 as well as new messages, although an implementation MAY choose to 2652 prioritise one over the other. Rate-control applies only to locally 2653 generated D-mode messages, not to messages which are being forwarded. 2654 When the rate limiter is in effect, D-mode messages MUST be queued 2655 until transmission is re-enabled, or they MAY be dropped with an 2656 error condition indicated back to local signalling applications. In 2657 either case, the effect of this will be to reduce the rate at which 2658 new transactions can be initiated by signalling applications, thereby 2659 reducing the load on the network. 2661 The rate limiting mechanism is implementation-defined, but it is 2662 RECOMMENDED that a token bucket limiter as described in [34] be used. 2663 The token bucket MUST be sized to ensure that a node cannot saturate 2664 the network with D-mode traffic, for example when re-probing the 2665 network for multiple flows after a route change. A suitable approach 2666 is to restrict the token bucket parameters so that the mean output 2667 rate is a small fraction of the node's lowest-speed interface. It is 2668 RECOMMENDED that this fraction is no more than 5%. Note that, 2669 according to the rules of Section 4.3.3, in general D-mode SHOULD 2670 only be used for Queries and Responses rather than normal signalling 2671 traffic unless capacity for normal signalling traffic can be 2672 engineered. 2674 5.4. C-mode Transport 2676 It is a requirement of the NTLP defined in [30] that it should be 2677 able to support bundling of small messages, fragmentation of large 2678 messages, and message boundary delineation. TCP provides both 2679 bundling and fragmentation, but not message boundaries. However, the 2680 length information in the GIST common header allows the message 2681 boundary to be discovered during parsing. The bundling together of 2682 small messages can either be done within the transport protocol or 2683 can be carried out by GIST during message construction. Either way, 2684 two approaches can be distinguished: 2686 1. As messages arrive for transmission they are gathered into a 2687 bundle until a size limit is reached or a timeout expires (cf. 2688 the Nagle algorithm of TCP). This provides maximal efficiency at 2689 the cost of some latency. 2691 2. Messages awaiting transmission are gathered together while the 2692 node is not allowed to send them, for example because it is 2693 congestion controlled. 2695 The second type of bundling is always appropriate. For GIST, the 2696 first type MUST NOT be used for trigger messages (i.e. messages that 2697 update GIST or signalling application state), but may be appropriate 2698 for refresh messages (i.e. messages that just extend timers). These 2699 distinctions are known only to the signalling applications, but MAY 2700 be indicated (as an implementation issue) by setting the priority 2701 transfer attribute (Section 4.1.2). 2703 It can be seen that all of these transport protocol options can be 2704 supported by the basic GIST message format already presented. The 2705 GIST message, consisting of common header and TLVs, is carried 2706 directly in the transport protocol, possibly incorporating transport 2707 layer security protection. Further messages can be carried in a 2708 continuous stream. This specification defines only the use of TCP, 2709 but other possibilities could be included without additional work on 2710 message formatting. 2712 5.5. Message Type/Encapsulation Relationships 2714 GIST has four primary message types (Query, Response, Confirm, and 2715 Data) and three possible encapsulation methods (normal D-mode, 2716 Q-mode, and C-mode). The combinations of message type and 2717 encapsulation which are allowed for message transmission are given in 2718 the table below. In some cases there are several possible choices, 2719 depending on the existence of routing state or messaging 2720 associations. The rules governing GIST policy, including whether or 2721 not to create such state to handle a message, are described 2722 normatively in the other sections of this specification. If a 2723 message which can only be sent in Q/D-mode arrives in C-mode or vice 2724 versa, this MUST be rejected with an "Incorrect Encapsulation" error 2725 message (Appendix A.4.4.3). However, it should be noted that the 2726 processing of the message at the receiver is not otherwise affected 2727 by the encapsulation method used, except that the decapsulation 2728 process may provide additional information, such as translated 2729 addresses or IP hop count to be used in the subsequent message 2730 processing. 2732 +----------+--------------+---------------------------+-------------+ 2733 | Message | Normal | Query D-mode (Q-mode) | C-mode | 2734 | | D-mode | | | 2735 +----------+--------------+---------------------------+-------------+ 2736 | Query | Never | Always, with C-flag=1 | Never | 2737 | | | | | 2738 | Response | Unless a | Never | If a | 2739 | | messaging | | messaging | 2740 | | association | | association | 2741 | | is being | | is being | 2742 | | re-used | | re-used | 2743 | | | | | 2744 | Confirm | Only if no | Never | If a | 2745 | | messaging | | messaging | 2746 | | association | | association | 2747 | | has been set | | has been | 2748 | | up or is | | set up or | 2749 | | being | | is being | 2750 | | re-used | | re-used | 2751 | | | | | 2752 | Data | If routing | If the MRI can be used to | If a | 2753 | | state exists | derive the Q-mode | messaging | 2754 | | for the flow | encapsulation, and either | association | 2755 | | but no | no routing state exists | exists | 2756 | | messaging | or local policy requires | | 2757 | | association | Q-mode; MUST have | | 2758 | | | C-flag=1 | | 2759 +----------+--------------+---------------------------+-------------+ 2761 5.6. Error Message Processing 2763 Special rules apply to the encapsulation and transmission of error 2764 messages. 2766 GIST only generates error messages in reaction to incoming messages. 2767 Error messages MUST NOT be generated in reaction to incoming error 2768 messages. The routing and encapsulation of the error message is 2769 derived from that of the message that caused the error; in 2770 particular, local routing state is not consulted. Routing state and 2771 messaging association state MUST NOT be created to handle the error, 2772 and error messages MUST NOT be retransmitted explicitly by GIST, 2773 although they are subject to the same rate control as other messages. 2775 o If the incoming message was received in D-mode, the error MUST be 2776 sent in D-mode using the normal encapsulation, using the 2777 addressing information from the NLI object in the incoming 2778 message. If the NLI could not be determined, the error MUST be 2779 sent to the IP source of the incoming message if the S flag was 2780 set in it. The NLI object in the Error message reports 2781 information about the originator of the error. 2783 o If the incoming message was received over a messaging association, 2784 the error MUST be sent back over the same messaging association. 2786 The NSLPID in the common header of the Error message has the value 2787 zero. If for any reason the message cannot be sent (for example, 2788 because it is too large to send in D-mode, or because the MA over 2789 which the original message arrived has since been closed) an error 2790 SHOULD be logged locally. The receiver of the Error message can 2791 infer the NSLPID for the message that caused the error from the 2792 Common Header that is embedded in the Error object. 2794 5.7. Messaging Association Setup 2796 5.7.1. Overview 2798 A key attribute of GIST is that it is flexible in its ability to use 2799 existing transport and security protocols. Different transport 2800 protocols may have performance attributes appropriate to different 2801 environments; different security protocols may fit appropriately with 2802 different authentication infrastructures. Even given an initial 2803 default mandatory protocol set for GIST, the need to support new 2804 protocols in the future cannot be ruled out, and secure feature 2805 negotiation cannot be added to an existing protocol in a backwards- 2806 compatible way. Therefore, some sort of capability discovery is 2807 required. 2809 Capability discovery is carried out in Query and Response messages, 2810 using Stack-Proposal and Stack-Configuration-Data (SCD) objects. If 2811 a new messaging association is required it is then set up, followed 2812 by a Confirm. Messaging association multiplexing is achieved by 2813 short-circuiting this exchange by sending the Response or Confirm 2814 messages on an existing association (Section 4.4.3); whether to do 2815 this is a matter of local policy. The end result of this process is 2816 a messaging association which is a stack of protocols. If multiple 2817 associations exist, it is a matter of local policy how to distribute 2818 messages over them, subject to respecting the transfer attributes 2819 requested for each message. 2821 Every possible protocol for a messaging association has the following 2822 attributes: 2824 o MA-Protocol-ID, a 1-byte IANA assigned value (see Section 9). 2826 o A specification of the (non-negotiable) policies about how the 2827 protocol should be used; for example, in which direction a 2828 connection should be opened. 2830 o [Depending on the specific protocol:] Formats for an MA-protocol- 2831 options field to carry the protocol addressing and other 2832 configuration information in the SCD object. The format may 2833 differ depending on whether the field is present in the Query or 2834 Response. Some protocols do not require the definition of such 2835 additional data, in which case no corresponding MA-protocol- 2836 options field will occur in the SCD object. 2838 A Stack-Proposal object is simply a list of profiles; each profile is 2839 a sequence of MA-Protocol-IDs. A profile lists the protocols in 'top 2840 to bottom' order (e.g. TLS over TCP). A Stack-Proposal is generally 2841 accompanied by a SCD object which carries an MA-protocol-options 2842 field for any protocol listed in the Stack-Proposal which needs it. 2843 An MA-protocol-options field may apply globally, to all instances of 2844 the protocol in the Stack-Proposal; or it can be tagged as applying 2845 to a specific instance. The latter approach can for example be used 2846 to carry different port numbers for TCP depending on whether it is to 2847 be used with or without TLS. An message flow which shows several of 2848 the features of Stack-Proposal and Stack-Configuration-Data formats 2849 can be found in Appendix D. 2851 An MA-protocol-options field may also be flagged as not usable; for 2852 example, a NAT which could not handle SCTP would set this in an MA- 2853 protocol-options field about SCTP. A protocol flagged this way MUST 2854 NOT be used for a messaging association. If the Stack-Proposal and 2855 SCD are both present but not consistent, for example, if they refer 2856 to different protocols, or an MA-protocol-options field refers to a 2857 non-existent profile, an "Object Value Error" message 2858 (Appendix A.4.4.10) with subcode 5 ("Stack-Proposal - Stack- 2859 Configuration-Data Mismatch") MUST be returned and the message 2860 dropped. 2862 A node generating a SCD object MUST honour the implied protocol 2863 configurations for the period during which a messaging association 2864 might be set up; in particular, it MUST be immediately prepared to 2865 accept incoming datagrams or connections at the protocol/port 2866 combinations advertised. This MAY require the creation of listening 2867 endpoints for the transport and security protocols in question, or a 2868 node MAY keep a pool of such endpoints open for extended periods. 2869 However, the received object contents MUST be retained only for the 2870 duration of the Query/Response exchange and to allow any necessary 2871 association setup to complete. They may become invalid because of 2872 expired bindings at intermediate NATs, or because the advertising 2873 node is using agile ports. Once the setup is complete, or if it is 2874 not necessary, or fails for some reason, the object contents MUST be 2875 discarded. A default time of 30 seconds to keep the contents is 2876 RECOMMENDED. 2878 A Query requesting messaging association setup always contains a 2879 Stack-Proposal and SCD object. The Stack-Proposal MUST only include 2880 protocol configurations that are suitable for the transfer attributes 2881 of the messages that the Querying node wishes to use the messaging 2882 association for. For example, it should not simply include all 2883 configurations that the Querying node is capable of supporting. 2885 The Response always contains a Stack-Proposal and SCD object, unless 2886 multiplexing (where the Responder decides to use an existing 2887 association) occurs. For such a Response, the security protocols 2888 listed in the Stack-Proposal MUST NOT depend on the Query. A node 2889 MAY make different proposals depending on the combination of 2890 interface and NSLPID. If multiplexing does occur, which is indicated 2891 by sending the Response over an existing messaging association, the 2892 following rules apply: 2894 o The re-used messaging association MUST NOT have weaker security 2895 properties than all of the options that would have been offered in 2896 the full Response that would have been sent without re-use. 2898 o The re-used messaging association MUST have equivalent or better 2899 transport and security characteristics as at least one of the 2900 protocol configurations that was offered in the Query. 2902 Once the messaging association is set up, the Querying node repeats 2903 the responder's Stack-Proposal over it in the Confirm. The 2904 responding node MUST verify that this has not been changed as part of 2905 bidding-down attack prevention, as well as verifying the Responder 2906 cookie (Section 8.5). If either check fails, the responding node 2907 MUST NOT create the message routing state (or MUST delete it if it 2908 already exists) and SHOULD log an error condition locally. If this 2909 is the first message on a new MA, the MA MUST be torn down. See 2910 Section 8.6 for further discussion. 2912 5.7.2. Protocol Definition: Forwards-TCP 2914 This MA-Protocol-ID denotes a basic use of TCP between peers. 2915 Support for this protocol is REQUIRED. If this protocol is offered, 2916 MA-protocol-options data MUST also be carried in the SCD object. The 2917 MA-protocol-options field formats are: 2919 o in a Query: no additional options data (the MA-protocol-options 2920 length field is zero). 2922 o in a Response: 2 byte port number at which the connection will be 2923 accepted, followed by 2 pad bytes. 2925 The connection is opened in the forwards direction, from the Querying 2926 node towards the responder. The Querying node MAY use any source 2927 address and source port. The destination information MUST be derived 2928 from information in the Response: the address from the interface- 2929 address from the Network-Layer-Information object and the port from 2930 the SCD object as described above. 2932 Associations using Forwards-TCP can carry messages with the transfer 2933 attribute Reliable=True. If an error occurs on the TCP connection 2934 such as a reset, as can be detected for example by a socket exception 2935 condition, GIST MUST report this to NSLPs as discussed in 2936 Section 4.1.2. 2938 5.7.3. Protocol Definition: Transport Layer Security 2940 This MA-Protocol-ID denotes a basic use of transport layer channel 2941 security, initially in conjunction with TCP. Support for this 2942 protocol in conjunction with TCP is REQUIRED; associations using it 2943 can carry messages with transfer attributes requesting 2944 confidentiality or integrity protection. The specific TLS version 2945 will be negotiated within the TLS layer itself, but implementations 2946 MUST NOT negotiate to protocol versions prior to TLS1.0 [16] and MUST 2947 use the highest protocol version supported by both peers. 2948 Implementation of TLS1.2 [11] is RECOMMENDED. GIST nodes supporting 2949 TLS1.0 or TLS1.1 MUST- be able to negotiate the TLS ciphersuite 2950 TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD+ be able to negotiate the 2951 TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. They MAY negotiate any 2952 mutually acceptable ciphersuite that provides authentication, 2953 integrity, and confidentiality. 2955 The default mode of TLS authentication, which applies in particular 2956 to the above ciphersuites, uses a client/server X.509 certificate 2957 exchange. The Querying node acts as a TLS client, and the Responding 2958 node acts as a TLS server. Where one of the above ciphersuites is 2959 negotiated, the GIST node acting as a server MUST provide a 2960 certificate, and MUST request one from the GIST node acting as a TLS 2961 client. This allows either server-only or mutual authentication, 2962 depending on the certificates available to the client and the policy 2963 applied at the server. 2965 GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the 2966 negotiation of alternative ciphersuites is used to trigger 2967 alternative authentication procedures, such as the use of pre-shared 2968 keys [33]. The use of other authentication procedures may require 2969 additional specification work to define how they can be used as part 2970 of TLS within the GIST framework, and may or may not require the 2971 definition of additional MA-Protocol-IDs. 2973 No MA-protocol-options field is required for this TLS protocol 2974 definition. The configuration information for the transport protocol 2975 over which TLS is running (e.g. TCP port number) is provided by the 2976 MA-protocol-options for that protocol. 2978 5.7.3.1. Identity Checking in TLS 2980 After TLS authentication, a node MUST check the identity presented by 2981 the peer in order to avoid man-in-the-middle attacks, and verify that 2982 the peer is authorised to take part in signalling at the GIST layer. 2983 The authorisation check is carried out by comparing the presented 2984 identity with each Authorised Peer Database (APD) entry in turn, as 2985 discussed in Section 4.4.2. This section defines the identity 2986 comparison algorithm for a single APD entry. 2988 For TLS authentication with X.509 certificates, an identity from the 2989 DNS namespace MUST be checked against each subjectAltName extension 2990 of type dNSName present in the certificate. If no such extension is 2991 present, then the identity MUST be compared to the (most specific) 2992 Common Name in the Subject field of the certificate. When matching 2993 DNS names against dNSName or Common Name fields, matching is case- 2994 insensitive. Also, a "*" wildcard character MAY be used as the left- 2995 most name component in the certificate or identity in the APD. For 2996 example, *.example.com in the APD would match certificates for 2997 a.example.com, foo.example.com, *.example.com, etc., but would not 2998 match example.com. Similarly, a certificate for *.example.com would 2999 be valid for APD identities of a.example.com, foo.example.com, 3000 *.example.com, etc., but not example.com. 3002 Additionally, a node MUST verify the binding between the identity of 3003 the peer to which it connects and the public key presented by that 3004 peer. Nodes SHOULD implement the algorithm in Section 6 of [9] for 3005 general certificate validation, but MAY supplement that algorithm 3006 with other validation methods that achieve equivalent levels of 3007 verification (such as comparing the server certificate against a 3008 local store of already-verified certificates and identity bindings). 3010 For TLS authentication with pre-shared keys, the identity in the 3011 psk_identity_hint (for the server identity, i.e. the Responding node) 3012 or psk_identity (for the client identity, i.e. the Querying node) 3013 MUST be compared to the identities in the APD. 3015 5.8. Specific Message Routing Methods 3017 Each message routing method (see Section 3.3) requires the definition 3018 of the format of the message routing information (MRI) and Q-mode 3019 encapsulation rules. These are given in the following subsections 3020 for the MRMs currently defined. A GIST implementation on a node MUST 3021 support whatever MRMs are required by the NSLPs on that node; GIST 3022 implementations SHOULD provide support for both the MRMs defined 3023 here, in order to minimise deployment barriers for new signalling 3024 applications that need them. 3026 5.8.1. The Path-Coupled MRM 3028 5.8.1.1. Message Routing Information 3030 For the path-coupled MRM, this is conceptually the Flow Identifier as 3031 in the NSIS Framework [30]. Minimally, this could just be the flow 3032 destination address; however, to account for policy based forwarding 3033 and other issues a more complete set of header fields SHOULD be 3034 specified if possible (see Section 4.3.4 and Section 7.2 for further 3035 discussion). 3037 MRI = network-layer-version 3038 source-address prefix-length 3039 destination-address prefix-length 3040 IP-protocol 3041 diffserv-codepoint 3042 [ flow-label ] 3043 [ ipsec-SPI / L4-ports] 3045 Additional control information defines whether the flow-label, IPsec 3046 Security Parameters Index (SPI), and port information are present, 3047 and whether the IP-protocol and diffserv-codepoint fields should be 3048 interpreted as significant. The source and destination addresses 3049 MUST be real node addresses, but prefix lengths other than 32/128 3050 (for IPv4/6) MAY be used to implement address wildcarding, allowing 3051 the MRI to refer to traffic to or from a wider address range. An 3052 additional flag defines the message direction relative to the MRI 3053 (upstream vs. downstream). 3055 The MRI format allows a potentially very large number of different 3056 flag and field combinations. A GIST implementation that cannot 3057 interpret the MRI in a message MUST return an "Object Value Error" 3058 message (Appendix A.4.4.10) with subcodes 1 ("Value Not Supported") 3059 or 2 ("Invalid Flag-Field Combination") and drop the message. 3061 5.8.1.2. Downstream Q-mode Encapsulation 3063 Where the signalling message is travelling in the same ('downstream') 3064 direction as the flow defined by the MRI, the IP addressing for 3065 Q-mode encapsulated messages is as follows. Support for this 3066 encapsulation is REQUIRED. 3068 o The destination IP address MUST be the flow destination address as 3069 given in the MRI of the message payload. 3071 o By default, the source address is the flow source address, again 3072 from the MRI; therefore, the source addressing mode flag in the 3073 common header S=0. This provides the best likelihood that the 3074 message will be correctly routed through any region performing 3075 per-packet policy-based forwarding or load balancing which takes 3076 the source address into account. However, there may be 3077 circumstances where the use of the signalling source address (S=1) 3078 is preferable, such as: 3080 * In order to receive ICMP error messages about the signalling 3081 message, such as unreachable port or address. If these are 3082 delivered to the flow source rather than the signalling source, 3083 it will be very difficult for the querying node to detect that 3084 it is the last GIST node on the path. Another case is where 3085 there is an abnormally low MTU along the path, in which case 3086 the querying node needs to see the ICMP error (recall that 3087 Q-mode packets are sent with DF set). 3089 * In order to receive GIST Error messages where the error message 3090 sender could not interpret the NLI in the original message. 3092 * In order to attempt to run GIST through an unmodified NAT, 3093 which will only process and translate IP addresses in the IP 3094 header (see Section 7.2.1). 3096 Because of these considerations, use of the signalling source 3097 address is allowed as an option, with use based on local policy. 3098 A node SHOULD use the flow source address for initial Query 3099 messages, but SHOULD transition to the signalling source address 3100 for some retransmissions or as a matter of static configuration, 3101 for example if a NAT is known to be in the path out of a certain 3102 interface. The S-flag in the common header tells the message 3103 receiver which option was used. 3105 A router alert option is also included in the IP header. The option 3106 value depends on the NSLP being signalled for. In addition, it is 3107 essential that the Query mimics the actual data flow as closely as 3108 possible, since this is the basis of how the signalling message is 3109 attached to the data path. To this end, GIST SHOULD set the DiffServ 3110 codepoint and (for IPv6) flow label to match the values in the MRI. 3112 A GIST implementation SHOULD apply validation checks to the MRI, to 3113 reject Query messages that are being injected by nodes with no 3114 legitimate interest in the flow being signalled for. In general, if 3115 the GIST node can detect that no flow could arrive over the same 3116 interface as the Query, it MUST be rejected with an appropriate error 3117 message. Such checks apply only to messages with the Q-mode 3118 encapsulation, since only those messages are required to track the 3119 flow path. The main checks are that the IP version used in the 3120 encapsulation should match that of the MRI and the version(s) used on 3121 that interface, and that the full range of source addresses (the 3122 source-address masked with its prefix-length) would pass ingress 3123 filtering checks. For these cases, the error message is "MRI 3124 Validation Failure" (Appendix A.4.4.12) with subcodes 1 or 2 ("IP 3125 Version Mismatch" or "Ingress Filter Failure") respectively. 3127 5.8.1.3. Upstream Q-mode Encapsulation 3129 In some deployment scenarios it is desirable to set up routing state 3130 in the upstream direction, (i.e. from flow receiver towards the 3131 sender). This could be used to support firewall signalling to 3132 control traffic from an un-cooperative sender, or signalling in 3133 general where the flow sender was not NSIS-capable. This capability 3134 is incorporated into GIST by defining an encapsulation and processing 3135 rules for sending Query messages upstream. 3137 In general, it is not possible to determine the hop-by-hop route 3138 upstream because of asymmetric IP routing. However, in particular 3139 cases, the upstream peer can be discovered with a high degree of 3140 confidence, for example: 3142 o The upstream GIST peer is 1 IP hop away, and can be reached by 3143 tracing back through the interface on which the flow arrives. 3145 o The upstream peer is a border router of a single-homed (stub) 3146 network. 3148 This section defines an upstream Q-mode encapsulation and validation 3149 checks for when it can be used. The functionality to generate 3150 upstream Queries is OPTIONAL, but if received they MUST be processed 3151 in the normal way with some additional IP TTL checks. No special 3152 functionality is needed for this. 3154 It is possible for routing state at a given node, for a specific MRI 3155 and NSLPID, to be created by both an upstream Query exchange 3156 (initiated by the node itself), and a downstream Query exchange 3157 (where the node is the responder). If the SIDs are different, these 3158 items of routing state MUST be considered as independent; if the SIDs 3159 match, the routing state installed by the downstream exchange MUST 3160 take precedence, provided that the downstream Query passed ingress 3161 filtering checks. The rationale for this is that the downstream 3162 Query is in general a more reliable way to install state, since it 3163 directly probes the IP routing infrastructure along the flow path, 3164 whereas use of the upstream Query depends on the correctness of the 3165 Querying node's understanding of the topology. 3167 The details of the encapsulation are as follows: 3169 o The destination address SHOULD be the flow source address as given 3170 in the MRI of the message payload. An implementation with more 3171 detailed knowledge of local IP routing MAY use an alternative 3172 destination address (e.g. the address of its default router). 3174 o The source address SHOULD be the signalling node address, so in 3175 the common header S=1. 3177 o A router alert option is included as in the downstream case. 3179 o The DiffServ codepoint and (for IPv6) flow label MAY be set to 3180 match the values from the MRI as in the downstream case, and the 3181 UDP port selection is also the same. 3183 o The IP layer TTL of the message MUST be set to 255. 3185 The sending GIST implementation SHOULD attempt to send the Query via 3186 the same interface and to the same link layer neighbour from which 3187 the data packets of the flow are arriving. 3189 The receiving GIST node MAY apply validation checks to the message 3190 and MRI, to reject Query messages which have reached a node at which 3191 they can no longer be trusted. In particular, a node SHOULD reject a 3192 message which has been propagated more than one IP hop, with an 3193 "Invalid IP layer TTL" error message (Appendix A.4.4.11). This can 3194 be determined by examining the received IP layer TTL, similar to the 3195 generalised IP TTL security mechanism described in [42]. 3196 Alternatively, receipt of an upstream Query at the flow source MAY be 3197 used to trigger setup of GIST state in the downstream direction. 3198 These restrictions may be relaxed in a future version. 3200 5.8.2. The Loose-End MRM 3202 The Loose-End MRM is used to discover GIST nodes with particular 3203 properties in the direction of a given address, for example to 3204 discover a NAT along the upstream data path as in [35]. 3206 5.8.2.1. Message Routing Information 3208 For the loose-end MRM, only a simplified version of the Flow 3209 Identifier is needed. 3211 MRI = network-layer-version 3212 source-address 3213 destination-address 3215 The source address is the address of the node initiating the 3216 discovery process, for example the node that will be the data 3217 receiver in the NAT discovery case. The destination address is the 3218 address of a node which is expected to be the other side of the node 3219 to be discovered. Additional control information defines the 3220 direction of the message relative to this flow as in the path-coupled 3221 case. 3223 5.8.2.2. Downstream Q-mode Encapsulation 3225 Only one encapsulation is defined for the loose-end MRM; by 3226 convention, this is referred to as the downstream encapsulation, and 3227 is defined as follows: 3229 o The IP destination address MUST be the destination address as 3230 given in the MRI of the message payload. 3232 o By default, the IP source address is the source address from the 3233 MRI (S=0). However, the use of the signalling source address 3234 (S=1) is allowed as in the case of the path-coupled MRM. 3236 A router alert option is included in the IP header. The option value 3237 depends on the NSLP being signalled for. There are no special 3238 requirements on the setting of the DiffServ codepoint, IP layer TTL, 3239 or (for IPv6) the flow label. Nor are any special validation checks 3240 applied. 3242 6. Formal Protocol Specification 3244 This section provides a more formal specification of the operation of 3245 GIST processing, in terms of rules for transitions between states of 3246 a set of communicating state machines within a node. The following 3247 description captures only the basic protocol specification; 3248 additional mechanisms can be used by an implementation to accelerate 3249 route change processing, and these are captured in Section 7.1. A 3250 more detailed description of the GIST protocol operation in state 3251 machine syntax can be found in [47]. 3253 Conceptually, GIST processing at a node may be seen in terms of four 3254 types of cooperating state machine: 3256 1. There is a top-level state machine which represents the node 3257 itself (Node-SM). It is responsible for the processing of events 3258 which cannot be directed towards a more specific state machine, 3259 for example, inbound messages for which no routing state 3260 currently exists. This machine exists permanently, and is 3261 responsible for creating per-MRI state machines to manage the 3262 GIST handshake and routing state maintenance procedures. 3264 2. For each flow and signalling direction where the node is 3265 responsible for the creation of routing state, there is an 3266 instance of a Query-Node state machine (Querying-SM). This 3267 machine sends Query and Confirm messages and waits for Responses, 3268 according to the requirements from local API commands or timer 3269 processing, such as message repetition or routing state refresh. 3271 3. For each flow and signalling direction where the node has 3272 accepted the creation of routing state by a peer, there is an 3273 instance of a Responding-Node state machine (Responding-SM). 3274 This machine is responsible for managing the status of the 3275 routing state for that flow. Depending on policy, it MAY be 3276 responsible for [re]transmission of Response messages, or this 3277 MAY be handled by the Node-SM, and a Responding-SM is not even 3278 created for a flow until a properly formatted Confirm has been 3279 accepted. 3281 4. Messaging associations have their own lifecycle, represented by 3282 an MA-SM, from when they are first created (in an incomplete 3283 state, listening for an inbound connection or waiting for 3284 outbound connections to complete), to when they are active and 3285 available for use. 3287 Apart from the fact that the various machines can be created and 3288 destroyed by each other, there is almost no interaction between them. 3289 The machines for different flows do not interact; the Querying-SM and 3290 Responding-SM for a single flow and signalling direction do not 3291 interact. That is, the Responding-SM which accepts the creation of 3292 routing state for a flow on one interface has no direct interaction 3293 with the Querying-SM which sets up routing state on the next 3294 interface along the path. This interaction is mediated instead 3295 through the NSLP. 3297 The state machine descriptions use the terminology rx_MMMM, tg_TTTT 3298 and er_EEEE for incoming messages, API/lower layer triggers and error 3299 conditions respectively. The possible events of these types are 3300 given in the table below. In addition, timeout events denoted 3301 to_TTTT may also occur; the various timers are listed independently 3302 for each type of state machine in the following subsections. 3304 +---------------------+---------------------------------------------+ 3305 | Name | Meaning | 3306 +---------------------+---------------------------------------------+ 3307 | rx_Query | A Query has been received. | 3308 | | | 3309 | rx_Response | A Response has been received. | 3310 | | | 3311 | rx_Confirm | A Confirm has been received. | 3312 | | | 3313 | rx_Data | A Data message has been received. | 3314 | | | 3315 | rx_Message | rx_Query||rx_Response||rx_Confirm||rx_Data. | 3316 | | | 3317 | rx_MA-Hello | A MA-Hello message has been received. | 3318 | | | 3319 | tg_NSLPData | A signalling application has requested data | 3320 | | transfer (via API SendMessage). | 3321 | | | 3322 | tg_Connected | The protocol stack for a messaging | 3323 | | association has completed connecting. | 3324 | | | 3325 | tg_RawData | GIST wishes to transfer data over a | 3326 | | particular messaging association. | 3327 | | | 3328 | tg_MAIdle | GIST decides that it is no longer necessary | 3329 | | to keep an MA open for itself. | 3330 | | | 3331 | er_NoRSM | A "No Routing State" error was received. | 3332 | | | 3333 | er_MAConnect | A messaging association protocol failed to | 3334 | | complete a connection. | 3335 | | | 3336 | er_MAFailure | A messaging association failed. | 3337 +---------------------+---------------------------------------------+ 3338 Incoming Events 3340 6.1. Node Processing 3342 The Node level state machine is responsible for processing events for 3343 which no more appropriate messaging association state or routing 3344 state exists. Its structure is trivial: there is a single state 3345 ('Idle'); all events cause a transition back to Idle. Some events 3346 cause the creation of other state machines. The only events that are 3347 processed by this state machine are incoming GIST messages (Query/ 3348 Response/Confirm/Data) and API requests to send data; no other events 3349 are possible. In addition to this event processing, the Node level 3350 machine is responsible for managing listening endpoints for messaging 3351 associations. Although these relate to Responding node operation, 3352 they cannot be handled by the Responder state machine since they are 3353 not created per flow. The processing rules for each event are as 3354 follows: 3356 Rule 1 (rx_Query): 3357 use the GIST service interface to determine the signalling 3358 application policy relating to this peer 3359 // note that this interaction delivers any NSLP-Data to 3360 // the NSLP as a side effect 3361 if (the signalling application indicates that routing state should 3362 be created) then 3363 if (routing state can be created without a 3-way handshake) then 3364 create Responding-SM and transfer control to it 3365 else 3366 send Response with R=1 3367 else 3368 propagate the Query with any updated NSLP payload provided 3370 Rule 2 (rx_Response): 3371 // a routing state error 3372 discard message 3374 Rule 3 (rx_Confirm): 3375 if (routing state can be created before receiving a Confirm) then 3376 // we should already have Responding-SM for it, 3377 // which would handle this message 3378 discard message 3379 send "No Routing State" error message 3380 else 3381 create Responding-SM and pass message to it 3383 Rule 4 (rx_Data): 3384 if (node policy will only process Data messages with matching 3385 routing state) then 3386 send "No Routing State" error message 3387 else 3388 pass directly to NSLP 3390 Rule 4 (er_NoRSM): 3391 discard the message 3393 Rule 5 (tg_NSLPData): 3394 if Q-mode encapsulation is not possible for this MRI 3395 reject message with an error 3396 else 3397 if (local policy & transfer attributes say routing 3398 state is not needed) then 3399 send message statelessly 3400 else 3401 create Querying-SM and pass message to it 3403 6.2. Query Node Processing 3405 The Querying-Node state machine (Querying-SM) has three states: 3407 o Awaiting Response 3409 o Established 3411 o Awaiting Refresh 3413 The Querying-SM is created by the Node-SM machine as a result of a 3414 request to send a message for a flow in a signalling direction where 3415 the appropriate state does not exist. The Query is generated 3416 immediately and the No_Response timer is started. The NSLP data MAY 3417 be carried in the Query if local policy and the transfer attributes 3418 allow it, otherwise it MUST be queued locally pending MA 3419 establishment. Then the machine transitions to the Awaiting Response 3420 state, in which timeout-based retransmissions are handled. Data 3421 messages (rx_Data events) should not occur in this state; if they do, 3422 this may indicate a lost Response and a node MAY retransmit a Query 3423 for this reason. 3425 Once a Response has been successfully received and routing state 3426 created, the machine transitions to Established, during which NSLP 3427 data can be sent and received normally. Further Responses received 3428 in this state (which may be the result of a lost Confirm) MUST be 3429 treated the same way. The Awaiting Refresh state can be considered 3430 as a substate of Established, where a new Query has been generated to 3431 refresh the routing state (as in Awaiting Response) but NSLP data can 3432 be handled normally. 3434 The timers relevant to this state machine are as follows: 3436 Refresh_QNode: Indicates when the routing state stored by this state 3437 machine must be refreshed. It is reset whenever a Response is 3438 received indicating that the routing state is still valid. 3439 Implementations MUST set the period of this timer based on the 3440 value in the RS-validity-time field of a Response to ensure that a 3441 Query is generated before the peer's routing state expires (see 3442 Section 4.4.4). 3444 No_Response: Indicates that a Response has not been received in 3445 answer to a Query. This is started whenever a Query is sent and 3446 stopped when a Response is received. 3448 Inactive_QNode: Indicates that no NSLP traffic is currently being 3449 handled by this state machine. This is reset whenever the state 3450 machine handles NSLP data, in either direction. When it expires, 3451 the state machine MAY be deleted. The period of the timer can be 3452 set at any time via the API (SetStateLifetime), and if the period 3453 is reset in this way the timer itself MUST be restarted. 3455 The main events (including all those that cause state transitions) 3456 are shown in the figure below, tagged with the number of the 3457 processing rule that is used to handle the event. These rules are 3458 listed after the diagram. All events not shown or described in the 3459 text above are assumed to be impossible in a correct implementation 3460 and MUST be ignored. 3462 [Initialisation] +-----+ 3463 -------------------------|Birth| 3464 | +-----+ 3465 | er_NoRSM[3](from all states) rx_Response[4] 3466 | || tg_NSLPData[5] 3467 | tg_NSLPData[1] || rx_Data[7] 3468 | -------- ------- 3469 | | V | V 3470 | | V | V 3471 | +----------+ +-----------+ 3472 ---->>| Awaiting | |Established| 3473 ------| Response |---------------------------->> | | 3474 | +----------+ rx_Response[4] +-----------+ 3475 | ^ | ^ | 3476 | ^ | ^ | 3477 | -------- | | 3478 | to_No_Response[2] | | 3479 | [!nResp_reached] tg_NSLPData[5] | | 3480 | || rx_Data[7] | | 3481 | -------- | | 3482 | | V | | 3483 | to_No_Response[2] | V | | 3484 | [nResp_reached] +-----------+ rx_Response[4] | | 3485 ---------- -----------| Awaiting |----------------- | 3486 | | | Refresh |<<------------------- 3487 | | +-----------+ to_Refresh_QNode[8] 3488 | | ^ | 3489 V V ^ | to_No_Response[2] 3490 V V -------- [!nResp_reached] 3491 +-----+ 3492 |Death|<<--------------- 3493 +-----+ to_Inactive_QNode[6] 3494 (from all states) 3496 Figure 7: Query Node State Machine 3498 The processing rules are as follows: 3500 Rule 1: Store the message for later transmission 3502 Rule 2: 3503 if number of Queries sent has reached the threshold 3504 // nQuery_isMax is true 3505 indicate No Response error to NSLP 3506 destroy self 3507 else 3508 send Query 3509 start No_Response timer with new value 3511 Rule 3: 3512 // Assume the Confirm was lost in transit or the peer has reset; 3513 // restart the handshake 3514 send Query 3515 (re)start No_Response timer 3517 Rule 4: 3518 if a new MA-SM is needed create one 3519 if the R flag was set send a Confirm 3520 send any stored Data messages 3521 stop No_Response timer 3522 start Refresh_QNode timer 3523 start Inactive_QNode timer if it was not running 3524 if there was piggybacked NSLP-Data 3525 pass it to the NSLP 3526 restart Inactive_QNOde timer 3528 Rule 5: 3529 send Data message 3530 restart Inactive_QNode timer 3532 Rule 6: Terminate 3534 Rule 7: 3535 pass any data to the NSLP 3536 restart Inactive_QNode timer 3538 Rule 8: 3539 send Query 3540 start No_Response timer 3541 stop Refresh_QNode timer 3543 6.3. Responder Node Processing 3545 The Responding-Node state machine (Responding-SM) has three states: 3547 o Awaiting Confirm 3549 o Established 3551 o Awaiting Refresh 3553 The policy governing the handling of Query messages and the creation 3554 of the Responding-SM has three cases: 3556 1. No Confirm is required for a Query, and the state machine can be 3557 created immediately. 3559 2. A Confirm is required for a Query, but the state machine can 3560 still be created immediately. A timer is used to retransmit 3561 Response messages and the Responding-SM is destroyed if no valid 3562 Confirm is received. 3564 3. A Confirm is required for a Query, and the state machine can only 3565 be created when it is received; the initial Query will have been 3566 handled by the Node level machine. 3568 In case 2 the Responding-SM is created in the Awaiting Confirm state, 3569 and remains there until a Confirm is received, at which point it 3570 transitions to Established. In cases 1 and 3 the Responding-SM is 3571 created directly in the Established state. Note that if the machine 3572 is created on receiving a Query, some of the message processing will 3573 already have been performed in the Node state machine. In principle, 3574 an implementation MAY change its policy on handling a Query message 3575 at any time; however, the state machine descriptions here cover only 3576 the case where the policy is fixed while waiting for a Confirm 3577 message. 3579 In the Established state the NSLP can send and receive data normally, 3580 and any additional rx_Confirm events MUST be silently ignored. The 3581 Awaiting Refresh state can be considered a substate of Established, 3582 where a Query has been received to begin the routing state refresh. 3583 In the Awaiting Refresh state the Responding-SM behaves as in the 3584 Awaiting Confirm state, except that the NSLP can still send and 3585 receive data. In particular, in both states there is timer-based 3586 retransmission of Response messages until a Confirm is received; 3587 additional rx_Query events in these states MUST also generate a reply 3588 and restart the no_Confirm timer. 3590 The timers relevant to the operation of this state machine are as 3591 follows: 3593 Expire_RNode: Indicates when the routing state stored by this state 3594 machine needs to be expired. It is reset whenever a Query or 3595 Confirm (depending on local policy) is received indicating that 3596 the routing state is still valid. Note that state cannot be 3597 refreshed from the R-Node. If this timer fires, the routing state 3598 machine is deleted, regardless of whether a No_Confirm timer is 3599 running. 3601 No_Confirm: Indicates that a Confirm has not been received in answer 3602 to a Response. This is started/reset whenever a Response is sent 3603 and stopped when a Confirm is received. 3605 The detailed state transitions and processing rules are described 3606 below as in the Query node case. 3608 rx_Query[1] rx_Query[5] 3609 [confirmRequired] +-----+ [!confirmRequired] 3610 -------------------------|Birth|---------------------------- 3611 | +-----+ | 3612 | | rx_Confirm[2] | 3613 | ---------------------------- | 3614 | | | 3615 | rx_Query[5] | | 3616 | tg_NSLPData[7] || rx_Confirm[10] | | 3617 | || rx_Query[1] || rx_Data[4] | | 3618 | || rx_Data[6] || tg_NSLPData[3] | | 3619 | -------- -------------- | | 3620 | | V | V V V 3621 | | V | V V V 3622 | +----------+ | +-----------+ 3623 ---->>| Awaiting | rx_Confirm[8] -----------|Established| 3624 ------| Confirm |------------------------------>> | | 3625 | +----------+ +-----------+ 3626 | ^ | ^ | 3627 | ^ | tg_NSLPData[3] ^ | 3628 | -------- || rx_Query[1] | | 3629 | to_No_Confirm[9] || rx_Data[4] | | 3630 | [!nConf_reached] -------- | | 3631 | | V | | 3632 | to_No_Confirm[9] | V | | 3633 | [nConf_reached] +-----------+ rx_Confirm[8] | | 3634 ---------- ------------| Awaiting |----------------- | 3635 | | | Refresh |<<------------------- 3636 | | +-----------+ rx_Query[1] 3637 | | ^ | [confirmRequired] 3638 | | ^ | 3639 | | -------- 3640 V V to_No_Confirm[9] 3641 V V [!nConf_reached] 3642 +-----+ 3643 |Death|<<--------------------- 3644 +-----+ er_NoRSM[11] 3645 to_Expire_RNode[11] 3646 (from Established/Awaiting Refresh) 3648 Figure 8: Responder Node State Machine 3650 The processing rules are as follows: 3652 Rule 1: 3653 // a Confirm is required 3654 send Response with R=1 3655 (re)start No_Confirm timer with the initial timer value 3656 Rule 2: 3657 pass any NSLP-Data object to the NSLP 3658 start Expire_RNode timer 3660 Rule 3: send the Data message 3662 Rule 4: pass data to NSLP 3664 Rule 5: 3665 // no Confirm is required 3666 send Response with R=0 3667 start Expire_RNode timer 3669 Rule 6: 3670 drop incoming data 3671 send "No Routing State" error message 3673 Rule 7: store Data message 3675 Rule 8: 3676 pass any NSLP-Data object to the NSLP 3677 send any stored Data messages 3678 stop No_Confirm timer 3679 start Expire_RNode timer 3681 Rule 9: 3682 if number of Responses sent has reached threshold 3683 // nResp_isMax is true 3684 destroy self 3685 else 3686 send Response 3687 start No_Response timer 3689 Rule 10: 3690 // can happen e.g. a retransmitted Response causes a duplicate Confirm 3691 silently ignore 3693 Rule 11: destroy self 3695 6.4. Messaging Association Processing 3697 Messaging associations (MAs) are modelled for use within GIST with a 3698 simple three-state process. The Awaiting Connection state indicates 3699 that the MA is waiting for the connection process(es) for every 3700 protocol in the messaging association to complete; this might involve 3701 creating listening endpoints or attempting active connects. Timers 3702 may also be necessary to detect connection failure (e.g. no incoming 3703 connection within a certain period), but these are not modelled 3704 explicitly. 3706 The Connected state indicates that the MA is open and ready to use, 3707 and that the node wishes it to remain open. In this state, the node 3708 operates a timer (SendHello) to ensure that messages are regularly 3709 sent to the peer, to ensure that the peer does not tear the MA down. 3710 The node transitions from Connected to Idle (indicating that it no 3711 longer needs the association) as a matter of local policy; one way to 3712 manage the policy is to use an activity timer but this is not 3713 specified explicitly by the state machine (see also Section 4.4.5). 3715 In the Idle state, the node no longer requires the messaging 3716 association but the peer still requires it and is indicating this by 3717 sending periodic MA-Hello messages. A different timer (NoHello) 3718 operates to purge the MA when these messages stop arriving. If real 3719 data is transferred over the MA, the state machine transitions back 3720 to Connected. 3722 At any time in the Connected or Idle states, a node MAY test the 3723 connectivity to its peer and the liveness of the GIST instance at 3724 that peer by sending a MA-Hello request with R=1. Failure to receive 3725 a reply with a matching Hello-ID within a timeout MAY be taken as a 3726 reason to trigger er_MAFailure. Initiation of such a test and the 3727 timeout setting are left to the discretion of the implementaion. 3728 Note that er_MAFailure may also be signalled by indications from the 3729 underlying messaging association protocols. If a messaging 3730 association fails, this MUST be indicated back to the routing state 3731 machines which use it, and these MAY generate indications to 3732 signalling applications. In particular, if the messaging association 3733 was being used to deliver messages reliably, this MUST be reported as 3734 a NetworkNotification error (Appendix B.4). 3736 Clearly, many internal details of the messaging association protocols 3737 are hidden in this model, especially where the messaging association 3738 uses multiple protocol layers. Note also that although the existence 3739 of messaging associations is not directly visible to signalling 3740 applications, there is some interaction between the two because 3741 security-related information becomes available during the open 3742 process, and this may be indicated to signalling applications if they 3743 have requested it. 3745 The timers relevant to the operation of this state machine are as 3746 follows: 3748 SendHello: Indicates that an MA-Hello message should be sent to the 3749 remote node. The period of this timer is determined by the MA- 3750 Hold-Time sent by the remote node during the Query/Response/ 3751 Confirm exchange. 3753 NoHello: Indicates that no MA-Hello has been received from the 3754 remote node for a period of time. The period of this timer is 3755 sent to the remote node as the MA-Hold-Time during the Query/ 3756 Response exchange. 3758 The detailed state transitions and processing rules are described 3759 below as in the Query node case. 3761 [Initialisation] +-----+ 3762 ----------------------------|Birth| 3763 | +-----+ tg_RawData[1] 3764 | || rx_Message[2] 3765 | || rx_MA-Hello[3] 3766 | tg_RawData[5] || to_SendHello[4] 3767 | -------- -------- 3768 | | V | V 3769 | | V | V 3770 | +----------+ +-----------+ 3771 ---->>| Awaiting | tg_Connected[6] | Connected | 3772 ------|Connection|----------------------->>| | 3773 | +----------+ +-----------+ 3774 | ^ | 3775 | tg_RawData[1] ^ | 3776 | || rx_Message[2] | | tg_MAIdle[7] 3777 | | V 3778 | | V 3779 | er_MAConnect[8] +-----+ to_NoHello[8] +-----------+ 3780 ---------------->>|Death|<<----------------| Idle | 3781 +-----+ +-----------+ 3782 ^ ^ | 3783 ^ ^ | 3784 --------------- -------- 3785 er_MAFailure[8] rx_MA-Hello[9] 3786 (from Connected/Idle) 3788 Figure 9: Messaging Association State Machine 3790 The processing rules are as follows: 3792 Rule 1: 3793 pass message to transport layer 3794 if the NoHello timer was running, stop it 3795 (re)start SendHello 3797 Rule 2: 3798 pass message to Node-SM, or R-SM (for a Confirm), 3799 or Q-SM (for a Response) 3800 if the NoHello timer was running, stop it 3801 Rule 3: 3802 if reply requested 3803 send MA-Hello 3804 restart SendHello timer 3806 Rule 4: 3807 send MA-Hello message 3808 restart SendHello timer 3810 Rule 5: queue message for later transmission 3812 Rule 6: 3813 pass outstanding queued messages to transport layer 3814 stop any timers controlling connection establishment 3815 start SendHello timer 3817 Rule 7: 3818 stop SendHello timer 3819 start NoHello timer 3821 Rule 8: 3822 report failure to routing state machines and signalling applications 3823 destroy self 3825 Rule 9: 3826 if reply requested 3827 send MA-Hello 3828 restart NoHello timer 3830 7. Additional Protocol Features 3832 7.1. Route Changes and Local Repair 3834 7.1.1. Introduction 3836 When IP layer re-routing takes place in the network, GIST and 3837 signalling application state need to be updated for all flows whose 3838 paths have changed. The updates to signalling application state 3839 depend mainly on the signalling application: for example, if the path 3840 characteristics have actually changed, simply moving state from the 3841 old to the new path is not sufficient. Therefore, GIST cannot carry 3842 out the complete path update processing. Its responsibilities are to 3843 detect the route change, update its local routing state consistently, 3844 and inform interested signalling applications at affected nodes. 3846 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 3847 x +--+ +--+ +--+ x Initial 3848 x .|C1|_.....|D1|_.....|E1| x Configuration 3849 x . +--+. .+--+. .+--+\. x 3850 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 3851 +-+ +-+ . .. .. . +-+ 3852 ...|A|_......|B|/ .. .. .|F|_.... 3853 +-+ +-+ . . . . . . +-+ 3854 . . . . . . 3855 . +--+ +--+ +--+ . 3856 .|C2|_.....|D2|_.....|E2|/ 3857 +--+ +--+ +--+ 3859 +--+ +--+ +--+ Configuration 3860 .|C1|......|D1|......|E1| after failure 3861 . +--+ .+--+ +--+ of E1-F link 3862 . \. . \. ./ 3863 +-+ +-+ . .. .. +-+ 3864 ...|A|_......|B|. .. .. .|F|_.... 3865 +-+ +-+\ . . . . . +-+ 3866 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 3867 x . +--+ +--+ +--+ . x 3868 x .|C2|_.....|D2|_.....|E2|/ x 3869 x +--+ +--+ +--+ x 3870 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 3872 ........... = physical link topology 3873 >>xxxxxxx>> = flow direction 3874 _.......... = outgoing link for flow xxxxxx given 3875 by local forwarding table 3877 Figure 10: A Re-Routing Event 3879 Route change management is complicated by the distributed nature of 3880 the problem. Consider the re-routing event shown in Figure 10. An 3881 external observer can tell that the main responsibility for 3882 controlling the updates will probably lie with nodes B and F; 3883 however, E1 is best placed to detect the event quickly at the GIST 3884 level, and C1 and D1 could also attempt to initiate the repair. 3886 The NSIS framework [30] makes the assumption that signalling 3887 applications are soft-state based and operate end to end. In this 3888 case, because GIST also periodically updates its picture of routing 3889 state, route changes will eventually be repaired automatically. The 3890 specification as already given includes this functionality. However, 3891 especially if upper layer refresh times are extended to reduce 3892 signalling load, the duration of inconsistent state may be very long 3893 indeed. Therefore, GIST includes logic to exchange prompt 3894 notifications with signalling applications, to allow local repair if 3895 possible. The additional mechanisms to achieve this are described in 3896 the following subsections. To a large extent, these additions can be 3897 seen as implementation issues; the protocol messages and their 3898 significance are not changed, but there are extra interactions 3899 through the API between GIST and signalling applications, and 3900 additional triggers for transitions between the various GIST states. 3902 7.1.2. Route Change Detection Mechanisms 3904 There are two aspects to detecting a route change at a single node: 3906 o Detecting that the outgoing path, in the direction of the Query, 3907 has or may have changed. 3909 o Detecting that the incoming path, in the direction of the 3910 Response, has (or may have) changed, in which case the node may no 3911 longer be on the path at all. 3913 At a single node, these processes are largely independent, although 3914 clearly a change in one direction at a node corresponds to a change 3915 in the opposite direction at its peer. Note that there are two 3916 possible forms for a route change: the interface through which a flow 3917 leaves or enters a node may change, and the adjacent peer may change. 3918 In general, a route change can include one or the other or both (or 3919 indeed neither, although such changes are very hard to detect). 3921 The route change detection mechanisms available to a node depend on 3922 the MRM in use and the role the node played in setting up the routing 3923 state in the first place (i.e. as Querying or Responding node). The 3924 following discussion is specific to the case of the path-coupled MRM 3925 using downstream Queries only; other scenarios may require other 3926 methods. However, the repair logic described in the subsequent 3927 subsections is intended to be universal. 3929 There are five mechanisms for a node to detect that a route change 3930 has occurred, which are listed below. They apply differently 3931 depending on whether the change is in the Query or Response 3932 direction, and these differences are summarised in the following 3933 table. 3935 Local Trigger: In local trigger mode, GIST finds out from the local 3936 forwarding table that the next hop has changed. This only works 3937 if the routing change is local, not if it happens a few IP routing 3938 hops away, including the case that it happens at a GIST-unaware 3939 node. 3941 Extended Trigger: Here, GIST checks a link-state topology database 3942 to discover that the path has changed. This makes certain 3943 assumptions on consistency of IP route computation and only works 3944 within a single area for OSPF [17] and similar link-state 3945 protocols. Where available, this offers the most accurate and 3946 rapid indication of route changes, but requires more access to the 3947 routing internals than a typical operating system may provide. 3949 GIST C-mode Monitoring: GIST may find that C-mode packets are 3950 arriving (from either peer) with a different IP layer TTL or on a 3951 different interface. This provides no direct information about 3952 the new flow path, but indicates that routing has changed and that 3953 rediscovery may be required. 3955 Data Plane Monitoring: The signalling application on a node may 3956 detect a change in behaviour of the flow, such as IP layer TTL 3957 change, arrival on a different interface, or loss of the flow 3958 altogether. The signalling application on the node is allowed to 3959 notify this information locally to GIST (Appendix B.6). 3961 GIST Probing: According to the specification, each GIST node MUST 3962 periodically repeat the discovery (Query/Response) operation. 3963 Values for the probe frequency are discussed in Section 4.4.4. 3964 The period can be negotiated independently for each GIST hop, so 3965 nodes that have access to the other techniques listed above MAY 3966 use long periods between probes. The querying node will discover 3967 the route change by a modification in the Network-Layer- 3968 Information in the Response. The responding node can detect a 3969 change in the upstream peer similarly; further, if the responding 3970 node can store the interface on which Queries arrive, it can 3971 detect if this interface changes even when the peer does not. 3973 +-------------+--------------------------+--------------------------+ 3974 | Method | Query direction | Response direction | 3975 +-------------+--------------------------+--------------------------+ 3976 | Local | Discovers new interface | Not applicable | 3977 | Trigger | (and peer if local) | | 3978 | | | | 3979 | Extended | Discovers new interface | May determine that route | 3980 | Trigger | and may determine new | from peer will have | 3981 | | peer | changed | 3982 | | | | 3983 | C-mode | Provides hint that | Provides hint that | 3984 | Monitoring | change has occurred | change has occurred | 3985 | | | | 3986 | Data Plane | Not applicable | NSLP informs GIST that a | 3987 | Monitoring | | change may have occurred | 3988 | | | | 3989 | Probing | Discovers changed NLI in | Discovers changed NLI in | 3990 | | Response | Query | 3991 +-------------+--------------------------+--------------------------+ 3993 7.1.3. GIST Behaviour Supporting Re-Routing 3995 The basic GIST behaviour necessary to support re-routing can be 3996 modelled using a 3-level classification of the validity of each item 3997 of current routing state. (In addition to current routing state, 3998 NSIS can maintain past routing state, described in Section 7.1.4 3999 below.) This classification applies separately to the Querying and 4000 Responding node for each pair of GIST peers. The levels are: 4002 Bad: The routing state is either missing altogether, or not safe to 4003 use to send data. 4005 Tentative: The routing state may have changed, but it is still 4006 usable for sending NSLP data pending verification. 4008 Good: The routing state has been established and no events affecting 4009 it have since been detected. 4011 These classifications are not identical to the states described in 4012 Section 6, but there are dependencies between them. Specifically, 4013 routing state is considered Bad until the state machine first enters 4014 the Established state, at which point it becomes Good. Thereafter, 4015 the status may be invalidated for any of the reasons discussed above; 4016 it is an implementation issue to decide which techniques to implement 4017 in any given node, and how to reclassify routing state (as Bad or 4018 Tentative) for each. The status returns to Good, either when the 4019 state machine re-enters the Established state, or if GIST can 4020 determine from direct examination of the IP routing or forwarding 4021 tables that the peer has not changed. When the status returns to 4022 Good, GIST MUST if necessary update its routing state table so that 4023 the relationships between MRI/SID/NSLPID tuples and messaging 4024 associations are up to date. 4026 When classification of the routing state for the downstream direction 4027 changes to Bad/Tentative because of local IP routing indications, 4028 GIST MAY automatically change the classification in the upstream 4029 direction to Tentative unless local routing indicates that this is 4030 not necessary. This SHOULD NOT be done in the case where the initial 4031 change was indicated by the signalling application. This mechanism 4032 accounts for the fact that a routing change may affect several nodes, 4033 and so can be an indication that upstream routing may also have 4034 changed. In any case, whenever GIST updates the routing status, it 4035 informs the signalling application with the NetworkNotification API 4036 (Appendix B.4), unless the change was caused via the API in the first 4037 place. 4039 The GIST behaviour for state repair is different for the Querying and 4040 Responding node. At the Responding node, there is no additional 4041 behaviour, since the Responding node cannot initiate protocol 4042 transitions autonomously, it can only react to the Querying node. 4043 The Querying node has three options, depending on how the transition 4044 from 'Good' was initially caused: 4046 1. To inspect the IP routing/forwarding table and verifying that the 4047 next peer has not changed. This technique MUST NOT be used if 4048 the transition was caused by a signalling application, but SHOULD 4049 be used otherwise if available. 4051 2. To move to the 'Awaiting Refresh' state. This technique MUST NOT 4052 be used if the current status is 'Bad', since data is being 4053 incorrectly delivered. 4055 3. To move to the 'Awaiting Response' state. This technique may be 4056 used at any time, but has the effect of freezing NSLP 4057 communication while GIST state is being repaired. 4059 The second and third techniques trigger the execution of a GIST 4060 handshake to carry out the repair. It may be desirable to delay the 4061 start of the handshake process, either to wait for the network to 4062 stabilise, to avoid flooding the network with Query traffic for a 4063 large number of affected flows, or to wait for confirmation that the 4064 node is still on the path from the upstream peer. One approach is to 4065 delay the handshake until there is NSLP data to be transmitted. 4066 Implementation of such delays is a matter of local policy; however, 4067 GIST MUST begin the handshake immediately if the status change was 4068 caused by an InvalidateRoutingState API call marked as 'Urgent', and 4069 SHOULD begin it if the upstream routing state is still known to be 4070 Good. 4072 7.1.4. Load Splitting and Route Flapping 4074 The Q-mode encapsulation rules of Section 5.8 try to ensure that the 4075 Query messages discovering the path mimic the flow as accurately as 4076 possible. However, in environments where there is load balancing 4077 over multiple routes, and this is based on header fields differing 4078 between flow and Q-mode packets or done on a round-robin basis, the 4079 path discovered by the Query may vary from one handshake to the next 4080 even though the underlying network is stable. This will appear to 4081 GIST as a route flap; route flapping can also be caused by problems 4082 in the basic network connectivity or routing protocol operation. For 4083 example, a mobile node might be switching back and forth between two 4084 links, or might appear to have disappeared even though it is still 4085 attached to the network via a different route. 4087 This specification does not define mechanisms for GIST to manage 4088 multiple parallel routes or an unstable route; instead, GIST MAY 4089 expose this to the NSLP, which can then manage it according to 4090 signalling application requirements. The algorithms already 4091 described always maintain the concept of the current route, i.e. the 4092 latest peer discovered for a particular flow. Instead, GIST allows 4093 the use of prior signalling paths for some period while the 4094 signalling applications still need them. Since NSLP peers are a 4095 single GIST hop apart, the necessary information to represent a path 4096 can be just an entry in the node's routing state table for that flow 4097 (more generally, anything that uniquely identifies the peer, such as 4098 the NLI, could be used). Rather than requiring GIST to maintain 4099 multiple generations of this information, it is provided to the 4100 signalling application in the same node in an opaque form for each 4101 message that is received from the peer. The signalling application 4102 can store it if necessary and provide it back to the GIST layer in 4103 case it needs to be used. Because this is a reference to information 4104 about the source of a prior signalling message, it is denoted 'SII- 4105 Handle' (for Source Identification Information) in the abstract API 4106 of Appendix B. 4108 Note that GIST if possible SHOULD use the same SII-Handle for 4109 multiple sessions to the same peer, since this then allows signalling 4110 applications to aggregate some signalling, such as summary refreshes 4111 or bulk teardowns. Messages sent using the SII-Handle MUST bypass 4112 the routing state tables at the sender, and this MUST be indicated by 4113 setting the E flag in the common header (Appendix A.1). Messages 4114 other than Data messages MUST NOT be sent in this way. At the 4115 receiver, GIST MUST NOT validate the MRI/SID/NSLPID against local 4116 routing state and instead indicates the mode of reception to 4117 signalling applications through the API (Appendix B.2). Signalling 4118 applications should validate the source and effect of the message 4119 themselves, and if appropriate should in particular indicate to GIST 4120 (see Appendix B.5) that routing state is no longer required for this 4121 flow. This is necessary to prevent GIST in nodes on the old path 4122 initiating routing state refresh and thus causing state conflicts at 4123 the crossover router. 4125 GIST notifies signalling applications about route modifications as 4126 two types of event, additions and deletions. An addition is notified 4127 as a change of the current routing state according to the Bad/ 4128 Tentative/Good classification above, while deletion is expressed as a 4129 statement that an SII-Handle no longer lies on the path. Both can be 4130 reported through the NetworkNotification API call (Appendix B.4). A 4131 minimal implementation MAY notify a route change as a single (add, 4132 delete) operation; however, a more sophisticated implementation MAY 4133 delay the delete notification, for example if it knows that the old 4134 route continues to be used in parallel, or that the true route is 4135 flapping between the two. It is then a matter of signalling 4136 application design whether to tear down state on the old path, leave 4137 it unchanged, or modify it in some signalling application specific 4138 way to reflect the fact that multiple paths are operating in 4139 parallel. 4141 7.1.5. Signalling Application Operation 4143 Signalling applications can use these functions as provided by GIST 4144 to carry out rapid local repair following re-routing events. The 4145 signalling application instances carry out the multi-hop aspects of 4146 the procedure, including crossover node detection, and tear-down/ 4147 reinstallation of signalling application state; they also trigger 4148 GIST to carry out the local routing state maintenance operations over 4149 each individual hop. The local repair procedures depend heavily on 4150 the fact that stateful NSLP nodes are a single GIST hop apart; this 4151 is enforced by the details of the GIST peer discovery process. 4153 The following outline description of a possible set of NSLP actions 4154 takes the scenario of Figure 10 as an example. 4156 1. The signalling application at node E1 is notified by GIST of 4157 route changes affecting the downstream and upstream directions. 4158 The downstream status was updated to Bad because of a trigger 4159 from the local forwarding tables, and the upstream status changed 4160 automatically to Tentative as a consequence. The signalling 4161 application at E1 MAY begin local repair immediately, or MAY 4162 propagate a notification upstream to D1 that re-routing has 4163 occurred. 4165 2. The signalling application at node D1 is notified of the route 4166 change, either by signalling application notifications or from 4167 the GIST level (e.g. by a trigger from a link-state topology 4168 database). If the information propagates faster within the IP 4169 routing protocol, GIST will change the upstream/downstream 4170 routing state to Tentative/Bad automatically, and this will cause 4171 the signalling application to propagate the notification further 4172 upstream. 4174 3. This process continues until the notification reaches node A. 4175 Here, there is no downstream routing change, so GIST only learns 4176 of the update via the signalling application trigger. Since the 4177 upstream status is still Good, it therefore begins the repair 4178 handshake immediately. 4180 4. The handshake initiated by node A causes its downstream routing 4181 state to be confirmed as Good and unchanged there; it also 4182 confirms the (Tentative) upstream routing state at B as Good. 4183 This is enough to identify B as the crossover router, and the 4184 signalling application and GIST can begin the local repair 4185 process. 4187 An alternative way to reach step (4) is that node B is able to 4188 determine autonomously that there is no likelihood of an upstream 4189 route change. For example, it could be an area border router and the 4190 route change is only intra-area. In this case, the signalling 4191 application and GIST will see that the upstream state is Good and can 4192 begin the local repair directly. 4194 After a route deletion, a signalling application may wish to remove 4195 state at another node which is no longer on the path. However, since 4196 it is no longer on the path, in principle GIST can no longer send 4197 messages to it. In general, provided this state is soft, it will 4198 time out anyway; however, the timeouts involved may have been set to 4199 be very long to reduce signalling load. Instead, signalling 4200 applications MAY use the SII-Handle described above to route explicit 4201 teardown messages. 4203 7.2. NAT Traversal 4205 GIST messages, for example for the path-coupled MRM, must carry 4206 addressing and higher layer information as payload data in order to 4207 define the flow signalled for. (This applies to all GIST messages, 4208 regardless of how they are encapsulated or which direction they are 4209 travelling in.) At an addressing boundary the data flow packets will 4210 have their headers translated; if the signalling payloads are not 4211 translated consistently, the signalling messages will refer to 4212 incorrect (and probably meaningless) flows after passing through the 4213 boundary. In addition, GIST handshake messages carry additional 4214 addressing information about the GIST nodes themselves, and this must 4215 also be processed appropriately when traversing a NAT. 4217 There is a dual problem of whether the GIST peers either side of the 4218 boundary can work out how to address each other, and whether they can 4219 work out what translation to apply to the signalling packet payloads. 4220 Existing generic NAT traversal techniques such as STUN [27] or TURN 4221 [28] can operate only on the two addresses visible in the IP header. 4222 It is therefore intrinsically difficult to use these techniques to 4223 discover a consistent translation of the three or four interdependent 4224 addresses for the flow and signalling source and destination. 4226 For legacy NATs and MRMs that carry addressing information, the base 4227 GIST specification is therefore limited to detecting the situation 4228 and triggering the appropriate error conditions to terminate the 4229 signalling path. (MRMs that do not contain addressing information 4230 could traverse such NATs safely, with some modifications to the GIST 4231 processing rules. Such modifications could be described in the 4232 documents defining such MRMs.) Legacy NAT handling is covered in 4233 Section 7.2.1 below. A more general solution can be constructed 4234 using GIST-awareness in the NATs themselves; this solution is 4235 outlined in Section 7.2.2 with processing rules in Section 7.2.3. 4237 In all cases, GIST interaction with the NAT is determined by the way 4238 the NAT handles the Query/Response messages in the initial GIST 4239 handshake; these messages are UDP datagrams. Best current practice 4240 for NAT treatment of UDP traffic is defined in [39], and the legacy 4241 NAT handling defined in this specification is fully consistent with 4242 that document. The GIST-aware NAT traversal technique is equivalent 4243 to requiring an Application Layer Gateway in the NAT for a specific 4244 class of UDP transactions, namely those where the destination UDP 4245 port for the initial message is the GIST port (see Section 9). 4247 7.2.1. Legacy NAT Handling 4249 Legacy NAT detection during the GIST handshake depends on analysis of 4250 the IP header and S flag in the GIST common header, and the NLI 4251 object included in the handshake messages. The message sequence 4252 proceeds differently depending on whether the Querying node is on the 4253 internal or external side of the NAT. 4255 For the case of the Querying node on the internal side of the NAT, if 4256 the S flag is not set in the Query (S=0), a legacy NAT cannot be 4257 detected. The receiver will generate a normal Response to the 4258 interface-address given in the NLI in the Query, but the interface- 4259 address will not be routable and the Response will not be delivered. 4260 If retransmitted Queries keep S=0, this behaviour will persist until 4261 the Querying node times out. The signalling path will thus terminate 4262 at this point, not traversing the NAT. 4264 The situation changes once S=1 in a Query; note the Q-mode 4265 encapsulation rules recommend that S=1 is used at least for some 4266 retransmissions (see Section 5.8). If S=1, the receiver MUST check 4267 the source address in the IP header against the interface-address in 4268 the NLI, and if these addresses do not match this indicates that a 4269 legacy NAT has been found. For MRMs which contain addressing 4270 information that needs translation, legacy NAT traversal is not 4271 possible. The receiver MUST return an "Object Type Error" message 4272 (Appendix A.4.4.9) with subcode 4 ("Untranslated Object") indicating 4273 the MRI as the object in question. The error message MUST be 4274 addressed to the source address from the IP header of the incoming 4275 message. The Responding node SHOULD use the destination IP address 4276 of the original datagram as the source address for IP header of the 4277 Response; this makes it more likely that the NAT will accept the 4278 incoming message, since it looks like a normal UDP/IP request/reply 4279 exchange. If this message is able to traverse back through the NAT, 4280 the Querying node will terminate the handshake immediately; 4281 otherwise, this reduces to the previous case of a lost Response and 4282 the Querying node will give up on reaching its retransmission limit. 4284 When the Querying node is on the external side of the NAT, the Query 4285 will only traverse the NAT if some static configuration has been 4286 carried out on the NAT to forward GIST Q-mode traffic to a node on 4287 the internal network. Regardless of the S-flag in the Query, the 4288 Responding node cannot directly detect the presence of the NAT. It 4289 MUST send a normal Response with S=1 to an address derived from the 4290 Querying node's NLI which will traverse the NAT as normal UDP 4291 traffic. The Querying node MUST check the source address in the IP 4292 header with the NLI in the Response, and when it finds a mismatch it 4293 MUST terminate the handshake. 4295 Note that in either of the error cases (internal or external Querying 4296 node), an alternative to terminating the handshake could be to invoke 4297 some legacy NAT traversal procedure. This specification does not 4298 define any such procedure, although one possible approach is 4299 described in [45]. Any such traversal procedure MUST be incorporated 4300 into GIST using the existing GIST extensibility capabilities. Note 4301 also that this detection process only functions with the handshake 4302 exchange; it cannot operate on simple Data messages, whether they are 4303 Q-mode or normally encapsulated. Nodes SHOULD NOT send Data messages 4304 outside a messaging association if they cannot ensure that they are 4305 operating in an environment free of legacy NATs. 4307 7.2.2. GIST-aware NAT Traversal 4309 The most robust solution to the NAT traversal problem is to require 4310 that a NAT is GIST-aware, and to allow it to modify messages based on 4311 the contents of the MRI. This makes the assumption that NATs only 4312 rewrite the header fields included in the MRI, and not other higher 4313 layer identifiers. Provided this is done consistently with the data 4314 flow header translation, signalling messages can be valid each side 4315 of the boundary, without requiring the NAT to be signalling 4316 application aware. Note, however, that if the NAT does not 4317 understand the MRI, and the N-flag in the MRI is clear (see 4318 Appendix A.3.1), it should reject the message with an "Object Type 4319 Error" message (Appendix A.4.4.9) with subcode 4 ("Untranslated 4320 Object"). 4322 The basic concept is that GIST-aware NATs modify any signalling 4323 messages that have to be able to be interpreted without routing state 4324 being available; these messages are identified by the context-free 4325 flag C=1 in the common header, and include the Query in GIST 4326 handshake. In addition, NATs have to modify the remaining handshake 4327 messages that set up routing state. When routing state is set up, 4328 GIST records how subsequent messages related to that routing state 4329 should be translated; if no routing state is being used for a 4330 message, GIST directly uses the modifications made by the NAT to 4331 translate it. 4333 This specification defines an additional NAT traversal object that a 4334 NAT inserts into all Q-mode encapsulated messages with the context- 4335 free flag C=1, and which GIST echoes back in any replies, i.e. 4336 Response or Error messages. NATs apply GIST-specific processing only 4337 to Q-mode encapsulated messages with C=1, or D-mode messages carrying 4338 the NAT traversal object. All other GIST messages, either in C-mode, 4339 or D-mode messages with no NAT-Traversal object, should be treated as 4340 normal data traffic by the NAT, i.e. with IP and transport layer 4341 header translation but no GIST-specific processing. Note that the 4342 distinction between Q-mode and D-mode encapsulation may not be 4343 observable to the NAT, which is why the setting of the C-flag or 4344 presence of the NAT traversal object are used as interception 4345 criteria. The NAT decisions are based purely on the value of the 4346 C-flag and the presence of the NAT traversal object, not on the 4347 message type. 4349 The NAT-Traversal object (Appendix A.3.9), carries the translation 4350 between the MRIs which are appropriate for the internal and external 4351 sides of the NAT. It also carries a list of which other objects in 4352 the message have been translated. This should always include the 4353 NLI, and the Stack-Configuration-Data if present; if GIST is extended 4354 with further objects that carry addressing data, this list allows a 4355 message receiver to know if the new objects were supported by the 4356 NAT. Finally, the NAT-Traversal object MAY be used to carry data to 4357 assist the NAT in back-translating D-mode responses; this could be 4358 the original NLI or SCD, or opaque equivalents in the case of 4359 topology hiding. 4361 A consequence of this approach is that the routing state tables at 4362 the signalling application peers each side of the NAT are no longer 4363 directly compatible. In particular, they use different MRI values to 4364 refer to the same flow. However, messages after the Query/Response 4365 (the initial Confirm and subsequent Data messages) need to use a 4366 common MRI, since the NAT does not rewrite these, and this is chosen 4367 to be the MRI of the Querying node. It is the responsibility of the 4368 Responding node to translate between the two MRIs on inbound and 4369 outbound messages, which is why the unmodified MRI is propagated in 4370 the NAT-Traversal object. 4372 7.2.3. Message Processing Rules 4374 This specification normatively defines the behaviour of a GIST node 4375 receiving a message containing a NAT-Traversal object. However, it 4376 does not define normative behaviour for a NAT translating GIST 4377 messages, since much of this will depend on NAT implementation and 4378 policy about allocating bindings. In addition, it is not necessary 4379 for a GIST implementation itself. Therefore, those aspects of the 4380 following description are informative; full details of NAT behaviour 4381 for handling GIST messages can be found in [46]. 4383 A possible set of operations for a NAT to process a message with C=1 4384 is as follows. Note that for a Data message, only a subset of the 4385 operations is applicable. 4387 1. Verify that bindings for any data flow are actually in place. 4389 2. Create a new Message-Routing-Information object with fields 4390 modified according to the data flow bindings. 4392 3. Create bindings for subsequent C-mode signalling based on the 4393 information in the Network-Layer-Information and Stack- 4394 Configuration-Data objects. 4396 4. Create new Network-Layer-Information and if necessary Stack- 4397 Configuration-Data objects with fields to force D-mode response 4398 messages through the NAT, and to allow C-mode exchanges using the 4399 C-mode signalling bindings. 4401 5. Add a NAT-Traversal object, listing the objects which have been 4402 modified and including the unmodified MRI and any other data 4403 needed to interpret the response. If a NAT-Traversal object is 4404 already present, in the case of a sequence of NATs, the list of 4405 modified objects may be updated and further opaque data added, 4406 but the MRI contained in it is left unchanged. 4408 6. Encapsulate the message according to the normal rules of this 4409 specification for the Q-mode encapsulation. If the S-flag was 4410 set in the original message, the same IP source address selection 4411 policy should be applied to the forwarded message. 4413 7. Forward the message with these new payloads. 4415 A GIST node receiving such a message MUST verify that all mandatory 4416 objects containing addressing have been translated correctly, or else 4417 reject the message with an "Object Type Error" message 4418 (Appendix A.4.4.9) with subcode 4 ("Untranslated Object"). The error 4419 message MUST include the NAT-Traversal object as the first TLV after 4420 the common header, and this is also true for any other error message 4421 generated as a reply. Otherwise, the message is processed 4422 essentially as normal. If no state needs to be updated for the 4423 message, the NAT-Traversal object can be effectively ignored. The 4424 other possibility is that a Response must be returned, either because 4425 the message is the beginning of a handshake for a new flow, or it is 4426 a refresh for existing state. In both cases, the GIST node MUST 4427 create the Response in the normal way using the local form of the 4428 MRI, and its own NLI and (if necessary) SCD. It MUST also include 4429 the NAT-Traversal object as the first object in the Response after 4430 the common header. 4432 A NAT will intercept D-mode messages containing such echoed NAT- 4433 Traversal objects. The NAT processing is a subset of the processing 4434 for the C=1 case: 4436 1. Verify the existence of bindings for the data flow. 4438 2. Leave the Message-Routing-Information object unchanged. 4440 3. Modify the NLI and SCD objects for the Responding node if 4441 necessary, and create or update any bindings for C-mode 4442 signalling traffic. 4444 4. Forward the message. 4446 A GIST node receiving such a message (Response or Error) MUST use the 4447 MRI from the NAT-Traversal object as the key to index its internal 4448 routing state; it MAY also store the translated MRI for additional 4449 (e.g. diagnostic) information, but this is not used in the GIST 4450 processing. The remainder of GIST processing is unchanged. 4452 Note that Confirm messages are not given GIST-specific processing by 4453 the NAT. Thus, a Responding node which has delayed state 4454 installation until receiving the Confirm, only has available the 4455 untranslated MRI describing the flow, and the untranslated NLI as 4456 peer routing state. This would prevent the correct interpretation of 4457 the signalling messages; also, subsequent Query (refresh) messages 4458 would always be seen as route changes because of the NLI change. 4459 Therefore, a Responding node that wishes to delay state installation 4460 until receiving a Confirm must somehow reconstruct the translations 4461 when the Confirm arrives. How to do this is an implementation issue; 4462 one approach is to carry the translated objects as part of the 4463 Responder cookie which is echoed in the Confirm. Indeed, for one of 4464 the cookie constructions in Section 8.5 this is automatic. 4466 7.3. Interaction with IP Tunnelling 4468 The interaction between GIST and IP tunnelling is very simple. An IP 4469 packet carrying a GIST message is treated exactly the same as any 4470 other packet with the same source and destination addresses: in other 4471 words, it is given the tunnel encapsulation and forwarded with the 4472 other data packets. 4474 Tunnelled packets will not be identifiable as GIST messages until 4475 they leave the tunnel, since any router alert option and the standard 4476 GIST protocol encapsulation (e.g. port numbers) will be hidden within 4477 the standard tunnel encapsulation. If signalling is needed for the 4478 tunnel itself, this has to be initiated as a separate signalling 4479 session by one of the tunnel endpoints - that is, the tunnel counts 4480 as a new flow. Because the relationship between signalling for the 4481 microflow and signalling for the tunnel as a whole will depend on the 4482 signalling application in question, it is a signalling application 4483 responsibility to be aware of the fact that tunnelling is taking 4484 place and to carry out additional signalling if necessary; in other 4485 words, at least one tunnel endpoint must be signalling application 4486 aware. 4488 In some cases, it is the tunnel exit point (i.e. the node where 4489 tunnelled data and downstream signalling packets leave the tunnel) 4490 that will wish to carry out the tunnel signalling, but this node will 4491 not have knowledge or control of how the tunnel entry point is 4492 carrying out the data flow encapsulation. The information about how 4493 the inner MRI/SID relate to the tunnel MRI/SID needs to be carried in 4494 the signalling data from the tunnel entry point; this functionality 4495 is the equivalent to the RSVP SESSION_ASSOC object of [19]. In the 4496 NSIS protocol suite, these bindings are managed by the signalling 4497 applications, either implicitly (e.g. by SID re-use) or explicitly by 4498 carrying objects that bind the inner and outer SIDs as part of the 4499 NSLP payload. 4501 7.4. IPv4-IPv6 Transition and Interworking 4503 GIST itself is essentially IP version neutral: version dependencies 4504 are isolated in the formats of the Message-Routing-Information, 4505 Network-Layer-Information and Stack-Configuration-Data objects, and 4506 GIST also depends on the version independence of the protocols that 4507 support messaging associations. In mixed environments, GIST 4508 operation will be influenced by the IP transition mechanisms in use. 4509 This section provides a high level overview of how GIST is affected, 4510 considering only the currently predominant mechanisms. 4512 Dual Stack: (As described in [36].) In mixed environments, GIST 4513 MUST use the same IP version for Q-mode encapsulated messages as 4514 given by the MRI of the flow it is signalling for, and SHOULD do 4515 so for other signalling also (see Section 5.2.2). Messages with 4516 mismatching versions MUST be rejected with an "MRI Validation 4517 Failure" error message (Appendix A.4.4.12) with subcode 1 ("IP 4518 Version Mismatch"). The IP version used in D-mode is closely tied 4519 to the IP version used by the data flow, so it is intrinsically 4520 impossible for an IPv4-only or IPv6-only GIST node to support 4521 signalling for flows using the other IP version. Hosts which are 4522 dual stack for applications and routers which are dual stack for 4523 forwarding need GIST implementations which can support both IP 4524 versions. Applications with a choice of IP versions might select 4525 a version based on which could be supported in the network by 4526 GIST, which could be established by invoking parallel discovery 4527 procedures. 4529 Packet Translation: (Applicable to SIIT [8].) Some transition 4530 mechanisms allow IPv4 and IPv6 nodes to communicate by placing 4531 packet translators between them. From the GIST perspective, this 4532 should be treated essentially the same way as any other NAT 4533 operation (e.g. between internal and external addresses) as 4534 described in Section 7.2. The translating node needs to be GIST- 4535 aware; it will have to translate the addressing payloads between 4536 IPv4 and IPv6 formats for flows which cross between the two. The 4537 translation rules for the fields in the MRI payload (including 4538 e.g. DiffServ-codepoint and flow-label) are as defined in [8]. 4539 The same analysis applies to NAT-PT, although this technique is no 4540 longer proposed as a general purpose transition mechanism [41]. 4542 Tunnelling: (Applicable to 6to4 [20].) Many transition mechanisms 4543 handle the problem of how an end to end IPv6 (or IPv4) flow can be 4544 carried over intermediate IPv4 (or IPv6) regions by tunnelling; 4545 the methods tend to focus on minimising the tunnel administration 4546 overhead. For GIST, the treatment should be similar to any other 4547 IP tunnelling mechanism, as described in Section 7.3. In 4548 particular, the end to end flow signalling will pass transparently 4549 through the tunnel, and signalling for the tunnel itself will have 4550 to be managed by the tunnel endpoints. However, additional 4551 considerations may arise because of special features of the tunnel 4552 management procedures. In particular, [21] is based on using an 4553 anycast address as the destination tunnel endpoint. GIST MAY use 4554 anycast destination addresses in the Q-mode encapsulation of 4555 D-mode messages if necessary, but MUST NOT use them in the 4556 Network-Layer-Information addressing field; unicast addresses MUST 4557 be used instead. Note that the addresses from the IP header are 4558 not used by GIST in matching requests and replies, so there is no 4559 requirement to use anycast source addresses. 4561 8. Security Considerations 4563 The security requirement for GIST is to protect the signalling plane 4564 against identified security threats. For the signalling problem as a 4565 whole, these threats have been outlined in [31]; the NSIS framework 4566 [30] assigns a subset of the responsibilities to the NTLP. The main 4567 issues to be handled can be summarised as: 4569 Message Protection: Signalling message content can be protected 4570 against eavesdropping, modification, injection and replay while in 4571 transit. This applies both to GIST payloads, and GIST should also 4572 provide such protection as a service to signalling applications 4573 between adjacent peers. 4575 Routing State Integrity Protection: It is important that signalling 4576 messages are delivered to the correct nodes, and nowhere else. 4577 Here, 'correct' is defined as 'the appropriate nodes for the 4578 signalling given the Message-Routing-Information'. In the case 4579 where the MRI is based on the Flow Identification for path-coupled 4580 signalling, 'appropriate' means 'the same nodes that the 4581 infrastructure will route data flow packets through'. GIST has no 4582 role in deciding whether the data flow itself is being routed 4583 correctly; all it can do is ensure the signalling is routed 4584 consistently with it. GIST uses internal state to decide how to 4585 route signalling messages, and this state needs to be protected 4586 against corruption. 4588 Prevention of Denial of Service Attacks: GIST nodes and the network 4589 have finite resources (state storage, processing power, 4590 bandwidth). The protocol tries to minimise exhaustion attacks 4591 against these resources and not allow GIST nodes to be used to 4592 launch attacks on other network elements. 4594 The main additional issue is handling authorisation for executing 4595 signalling operations (e.g. allocating resources). This is assumed 4596 to be done in each signalling application. 4598 In many cases, GIST relies on the security mechanisms available in 4599 messaging associations to handle these issues, rather than 4600 introducing new security measures. Obviously, this requires the 4601 interaction of these mechanisms with the rest of the GIST protocol to 4602 be understood and verified, and some aspects of this are discussed in 4603 Section 5.7. 4605 8.1. Message Confidentiality and Integrity 4607 GIST can use messaging association functionality, specifically in 4608 this version TLS (Section 5.7.3), to ensure message confidentiality 4609 and integrity. Implementation of this functionality is REQUIRED but 4610 its use for any given flow or signalling application is OPTIONAL. In 4611 some cases, confidentiality of GIST information itself is not likely 4612 to be a prime concern, in particular since messages are often sent to 4613 parties which are unknown ahead of time, although the content visible 4614 even at the GIST level gives significant opportunities for traffic 4615 analysis. Signalling applications may have their own mechanism for 4616 securing content as necessary; however, they may find it convenient 4617 to rely on protection provided by messaging associations, since it 4618 runs unbroken between signalling application peers. 4620 8.2. Peer Node Authentication 4622 Cryptographic protection (of confidentiality or integrity) requires a 4623 security association with session keys. These can be established by 4624 an authentication and key exchange protocol based on shared secrets, 4625 public key techniques or a combination of both. Authentication and 4626 key agreement is possible using the protocols associated with the 4627 messaging association being secured. TLS incorporates this 4628 functionality directly. GIST nodes rely on the messaging association 4629 protocol to authenticate the identity of the next hop, and GIST has 4630 no authentication capability of its own. 4632 With routing state discovery, there are few effective ways to know 4633 what is the legitimate next or previous hop as opposed to an 4634 impostor. In other words, cryptographic authentication here only 4635 provides assurance that a node is 'who' it is (i.e. the legitimate 4636 owner of identity in some namespace), not 'what' it is (i.e. a node 4637 which is genuinely on the flow path and therefore can carry out 4638 signalling for a particular flow). Authentication provides only 4639 limited protection, in that a known peer is unlikely to lie about its 4640 role. Additional methods of protection against this type of attack 4641 are considered in Section 8.3 below. 4643 It is an implementation issue whether peer node authentication should 4644 be made signalling application dependent; for example, whether 4645 successful authentication could be made dependent on presenting 4646 credentials related to a particular signalling role (e.g. signalling 4647 for QoS). The abstract API of Appendix B leaves open such policy and 4648 authentication interactions between GIST and the NSLP it is serving. 4649 However, it does allow applications to inspect the authenticated 4650 identity of the peer to which a message will be sent before 4651 transmission. 4653 8.3. Routing State Integrity 4655 Internal state in a node (see Section 4.2) is used to route messages. 4656 If this state is corrupted, signalling messages may be misdirected. 4658 In the case where the MRM is path-coupled, the messages need to be 4659 routed identically to the data flow described by the MRI, and the 4660 routing state table is the GIST view of how these flows are being 4661 routed through the network in the immediate neighbourhood of the 4662 node. Routes are only weakly secured (e.g. there is no cryptographic 4663 binding of a flow to a route), and there is no authoritative 4664 information about flow routes other than the current state of the 4665 network itself. Therefore, consistency between GIST and network 4666 routing state has to be ensured by directly interacting with the IP 4667 routing mechanisms to ensure that the signalling peers are the 4668 appropriate ones for any given flow. An overview of security issues 4669 and techniques in this context is provided in [38]. 4671 In one direction, peer identification is installed and refreshed only 4672 on receiving a Response (compare Figure 5). This MUST echo the 4673 cookie from a previous Query, which will have been sent along the 4674 flow path with the Q-mode encapsulation, i.e. end-to-end addressed. 4675 Hence, only the true next peer or an on-path attacker will be able to 4676 generate such a message, provided freshness of the cookie can be 4677 checked at the querying node. 4679 In the other direction, peer identification MAY be installed directly 4680 on receiving a Query containing addressing information for the 4681 signalling source. However, any node in the network could generate 4682 such a message; indeed, many nodes in the network could be the 4683 genuine upstream peer for a given flow. To protect against this, 4684 four strategies are used: 4686 Filtering: the receiving node MAY reject signalling messages which 4687 claim to be for flows with flow source addresses which could be 4688 ruled out by ingress filtering. An extension of this technique 4689 would be for the receiving node to monitor the data plane and to 4690 check explicitly that the flow packets are arriving over the same 4691 interface and if possible from the same link layer neighbour as 4692 the D-mode signalling packets. If they are not, it is likely that 4693 at least one of the signalling or flow packets is being spoofed. 4695 Return routability checking: the receiving node MAY refuse to 4696 install upstream state until it has completed a Confirm handshake 4697 with the peer. This echoes the Response cookie of the Response, 4698 and discourages nodes from using forged source addresses. This 4699 also plays a role in denial of service prevention, see below. 4701 Authorisation: a stronger approach is to carry out a peer 4702 authorisation check (see Section 4.4.2) as part of messaging 4703 association setup. The ideal situation is that the receiving node 4704 can determine the correct upstream node address from routing table 4705 analysis or knowledge of local topology constraints, and then 4706 verify from the authorised peer database (APD) that the peer has 4707 this IP address. This is only technically feasible in a limited 4708 set of deployment environments. The APD can also be used to list 4709 the subsets of nodes which are feasible peers for particular 4710 source or destination subnets, or to blacklist nodes which have 4711 previously originated attacks or exist in untrustworthy networks, 4712 which provide weaker levels of authorisation checking. 4714 SID segregation: The routing state lookup for a given MRI and NSLPID 4715 MUST also take the SID into account. A malicious node can only 4716 overwrite existing GIST routing state if it can guess the 4717 corresponding SID; it can insert state with random SID values, but 4718 generally this will not be used to route signalling messages for 4719 which state has already been legitimately established. 4721 8.4. Denial of Service Prevention and Overload Protection 4723 GIST is designed so that in general each Query only generates at most 4724 one Response which is at most only slightly larger than the Query, so 4725 that a GIST node cannot become the source of a denial of service 4726 amplification attack. (There is a special case of retransmitted 4727 Response messages, see Section 5.3.3.) 4729 However, GIST can still be subjected to denial-of-service attacks 4730 where an attacker using forged source addresses forces a node to 4731 establish state without return routability, causing a problem similar 4732 to TCP SYN flood attacks. Furthermore, an adversary might use 4733 modified or replayed unprotected signalling messages as part of such 4734 an attack. There are two types of state attacks and one 4735 computational resource attack. In the first state attack, an 4736 attacker floods a node with messages that the node has to store until 4737 it can determine the next hop. If the destination address is chosen 4738 so that there is no GIST-capable next hop, the node would accumulate 4739 messages for several seconds until the discovery retransmission 4740 attempt times out. The second type of state-based attack causes GIST 4741 state to be established by bogus messages. A related computational/ 4742 network-resource attack uses unverified messages to cause a node 4743 query an authentication or authorisation infrastructure, or attempt 4744 to cryptographically verify a digital signature. 4746 We use a combination of two defences against these attacks: 4748 1. The responding node need not establish a session or discover its 4749 next hop on receiving the Query, but MAY wait for a Confirm, 4750 possibly on a secure channel. If the channel exists, the 4751 additional delay is one one-way delay and the total is no more 4752 than the minimal theoretically possible delay of a three-way 4753 handshake, i.e., 1.5 node-to-node round-trip times. The delay 4754 gets significantly larger if a new connection needs to be 4755 established first. 4757 2. The Response to the Query contains a cookie, which is repeated in 4758 the Confirm. State is only established for messages that contain 4759 a valid cookie. The setup delay is also 1.5 round-trip times. 4760 This mechanism is similar to that in SCTP [40] and other modern 4761 protocols. 4763 There is a potential overload condition if a node is flooded with 4764 Query or Confirm messages. One option is for the node to bypass 4765 these messages altogether as described in Section 4.3.2, effectively 4766 falling back to being a non-NSIS node. If this is not possible, a 4767 node MAY still choose to limit the rate at which it processes Query 4768 messages and discard the excess, although it SHOULD first adapt its 4769 policy to one of sending Responses statelessly if it is not already 4770 doing so. A conformant GIST node will automatically decrease the 4771 load by retransmitting Queries with an exponential backoff. A non- 4772 conformant node (launching a DoS attack) can generate uncorrelated 4773 Queries at an arbitrary rate, which makes it hard to apply rate- 4774 limiting without also affecting genuine handshake attempts. However, 4775 if Confirm messages are requested, the cookie binds the message to a 4776 Querying node address which has been validated by a return 4777 routability check and rate-limits can be applied per-source. 4779 Once a node has decided to establish routing state, there may still 4780 be transport and security state to be established between peers. 4781 This state setup is also vulnerable to denial of service attacks. 4782 GIST relies on the implementations of the lower layer protocols that 4783 make up messaging associations to mitigate such attacks. In the 4784 current specification, the querying node is always the one wishing to 4785 establish a messaging association, so it is the responding node that 4786 needs to be protected. It is possible for an attacking node to 4787 execute these protocols legally to set up large numbers of 4788 associations that were never used, and responding node 4789 implementations MAY use rate-limiting or other techniques to control 4790 the load in such cases. 4792 Signalling applications can use the services provided by GIST to 4793 defend against certain (e.g. flooding) denial of service attacks. In 4794 particular, they can elect to process only messages from peers that 4795 have passed a return routability check or been authenticated at the 4796 messaging association level (see Appendix B.2). Signalling 4797 applications that accept messages under other circumstances (in 4798 particular, before routing state has been fully established at the 4799 GIST level) need to take this into account when designing their 4800 denial of service prevention mechanisms, for example by not creating 4801 local state as a result of processing such messages. Signalling 4802 applications can also manage overload by invoking flow control, as 4803 described in Section 4.1.1. 4805 8.5. Requirements on Cookie Mechanisms 4807 The requirements on the Query cookie can be summarised as follows: 4809 Liveness: The cookie must be live, that is, it must change from one 4810 handshake to the next. To prevent replay attacks. 4812 Unpredictability: The cookie must not be guessable e.g. from a 4813 sequence or timestamp. To prevent direct forgery based on seeing 4814 a history of captured messages. 4816 Easily validated: It must be efficient for the Q-Node to validate 4817 that a particular cookie matches an in-progress handshake, for a 4818 routing state machine which already exists. To discard responses 4819 which have been randomly generated by an adversary, or to discard 4820 responses to queries which were generated with forged source 4821 addresses or an incorrect address in the included NLI object. 4823 Uniqueness: The cookie must be unique to a given handshake since it 4824 is actually used to match the Response to a handshake anyway, e.g. 4825 because of messaging association multiplexing. 4827 Likewise, the requirements on the Responder cookie can be summarised 4828 as follows: 4830 Liveness: The cookie must be live as above, to prevent replay 4831 attacks. 4833 Creation simplicity: The cookie must be lightweight to generatem, to 4834 avoid resource exhaustion at the responding node. 4836 Validation simplicity: It must be simple for the R-node to validate 4837 that an R-cookie was generated by itself and no-one else, without 4838 storing state about the handshake it was generated for. 4840 Binding: The cookie must be bound to the routing state that will be 4841 installed, to prevent use with different routing state e.g. in a 4842 modified Confirm. The routing state here includes the Peer- 4843 Identity and Interface-Address given in the NLI of the Query, and 4844 the MRI/NSLPID for the messaging. 4846 It can also include the interface on which the Query was received 4847 for use later in route change detection (Section 7.1.2). Since a 4848 Q-mode encapsulated message is the one that will best follow the 4849 data path, subsequent changes in this arrival interface indicate 4850 route changes between the peers. 4852 A suitable implementation for the Q-Cookie is a cryptographically 4853 strong random number which is unique for this routing state machine 4854 handshake. A node MUST implement this or an equivalently strong 4855 mechanism. Guidance on random number generation can be found in 4856 [32]. 4858 A suitable basic implementation for the R-Cookie is as follows: 4860 R-Cookie = liveness data + reception interface 4861 + hash (locally known secret, 4862 Q-Node NLI identity and address, MRI, NSLPID, 4863 liveness data) 4865 A node MUST implement this or an equivalently strong mechanism. 4866 There are several alternatives for the liveness data. One is to use 4867 a timestamp like SCTP. Another is to give the local secret a (rapid) 4868 rollover, with the liveness data as the generation number of the 4869 secret, like IKEv2. In both cases, the liveness data has to be 4870 carried outside the hash, to allow the hash to be verified at the 4871 Responder. Another approach is to replace the hash with encryption 4872 under a locally known secret, in which case the liveness data does 4873 not need to be carried in the clear. Any symmetric cipher immune to 4874 known plaintext attacks can be used. In the case of GIST-aware NAT 4875 traversal with delayed state installation it is necessary to carry 4876 additional data in the cookie; appropriate constructions are 4877 described in [46]. 4879 To support the validation simplicity requirement, the Responder can 4880 check the liveness data to filter out some blind (flooding) attacks 4881 before beginning any cryptographic cookie verification. To support 4882 this usage, the liveness data must be carried in the clear and not be 4883 easily guessable; this rules out the timestamp approach, and suggests 4884 the use of sequence of secrets with the liveness data identifying the 4885 position in the sequence. The secret strength and rollover frequency 4886 must be high enough that the secret cannot be brute-forced during its 4887 lifetime. Note that any node can use a Query to discover the current 4888 liveness data, so it remains hard to defend against sophisticated 4889 attacks which disguise such probes within a flood of Queries from 4890 forged source addresses. Therefore, it remains important to use an 4891 efficient hashing mechanism or equivalent. 4893 If a node receives a message for which cookie validation fails, it 4894 MAY return an "Object Value Error" message (Appendix A.4.4.10) with 4895 subcode 4 ("Invalid Cookie") to the sender and SHOULD log an error 4896 condition locally, as well as dropping the message. However, sending 4897 the error in general makes a node a source of backscatter. 4899 Therefore, this MUST only be enabled selectively, e.g. during initial 4900 deployment or debugging. 4902 8.6. Security Protocol Selection Policy 4904 This specification defines a single mandatory-to-implement security 4905 protocol (TLS, Section 5.7.3). However, it is possible to define 4906 additional security protocols in the future, for example to allow re- 4907 use with other types of credentials, or migrate towards protocols 4908 with stronger security properties. In addition, use of any security 4909 protocol for a messaging association is optional. Security protocol 4910 selection is carried out as part of the GIST handshake mechanism 4911 (Section 4.4.1). 4913 The selection process may be vulnerable to downgrade attacks, where a 4914 man in the middle modifies the capabilities offered in the Query or 4915 Response to mislead the peers into accepting a lower level of 4916 protection than is achievable. There is a two part defence against 4917 such attacks (the following is based the same concepts as [26]): 4919 1. The Response does not depend on the Stack-Proposal in the Query 4920 (see Section 5.7.1). Therefore, tampering with the Query has no 4921 effect on the resulting messaging association configuration. 4923 2. The Responding node's Stack-Proposal is echoed in the Confirm. 4924 The Responding node checks this to validate that the proposal it 4925 made in the Response is the same as the one received by the 4926 Querying node. Note that as a consequence of the previous point, 4927 the Responding node does not have to remember the proposal 4928 explicitly, since it is a static function of local policy. 4930 The validity of the second part depends on the strength of the 4931 security protection provided for the Confirm. If the Querying node 4932 is prepared to create messaging associations with null security 4933 properties (e.g. TCP only), the defence is ineffective, since the 4934 man in the middle can re-insert the original Responder's Stack- 4935 Proposal, and the Responding node will assume that the minimal 4936 protection is a consequence of Querying node limitations. However, 4937 if the messaging association provides at least integrity protection 4938 that cannot be broken in real-time, the Confirm cannot be modified in 4939 this way. Therefore, if the Querying node does not apply a security 4940 policy to the messaging association protocols to be created that 4941 ensures at least this minimal level of protection is met, it remains 4942 open to the threat that a downgrade has occurred. Applying such a 4943 policy ensures capability discovery process will result in the setup 4944 of a messaging association with the correct security properties as 4945 appropriate for the two peers involved. 4947 8.7. Residual Threats 4949 Taking the above security mechanisms into account, the main residual 4950 threats against NSIS are three types of on-path attack, 4951 vulnerabilities from particular limited modes of TLS usage, and 4952 implementation-related weaknesses. 4954 An on-path attacker who can intercept the initial Query can do most 4955 things it wants to the subsequent signalling. It is very hard to 4956 protect against this at the GIST level; the only defence is to use 4957 strong messaging association security to see whether the Responding 4958 node is authorised to take part in NSLP signalling exchanges. To 4959 some extent, this behaviour is logically indistinguishable from 4960 correct operation, so it is easy to see why defence is difficult. 4961 Note that an on-path attacker of this sort can do anything to the 4962 traffic as well as the signalling. Therefore, the additional threat 4963 induced by the signalling weakness seems tolerable. 4965 At the NSLP level, there is a concern about transitivity of trust of 4966 correctness of routing along the signalling chain. The NSLP at the 4967 querying node can have good assurance that it is communicating with 4968 an on-path peer or a node delegated by the on-path node by depending 4969 on the security protection provided by GIST. However, it has no 4970 assurance that the node beyond the responder is also on-path, or that 4971 the MRI (in particular) is not being modified by the responder to 4972 refer to a different flow. Therefore, if it sends signalling 4973 messages with payloads (e.g. authorisation tokens) which are valuable 4974 to nodes beyond the adjacent hop, it is up to the NSLP to ensure that 4975 the appropriate chain of trust exists. This could be achieved using 4976 higher layer security protection such as CMS [29]. 4978 There is a further residual attack by a node which is not on the path 4979 of the Query, but is on the path of the Response, or is able to use a 4980 Response from one handshake to interfere with another. The attacker 4981 modifies the Response to cause the Querying node to form an adjacency 4982 with it rather than the true peer. In principle, this attack could 4983 be prevented by including an additional cryptographic object in the 4984 Response which ties the Response to the initial Query and the routing 4985 state and can be verified by the Querying node. 4987 GIST depends on TLS for peer node authentication, and subsequent 4988 channel security. The analysis in [31] indicates the threats that 4989 arise when the peer node authentication is incomplete, specifically 4990 when unilateral authentication is performed (one node authenticates 4991 the other, but not vice versa). In this specification, mutual 4992 authentication can be supported either by certificate exchange or the 4993 use of pre-shared keys (see Section 5.7.3); if some other TLS 4994 authentication mechanism is negotiated, its properties would have to 4995 be analysed to determine acceptability for use with GIST. If mutual 4996 authentication is performed, the requirements for NTLP security are 4997 met. 4999 However, in the case of certificate exchange, this specification 5000 allows the possibility that only a server certificate is provided, 5001 which means that the Querying node authenticates the Responding node 5002 but not vice versa. Accepting such unilateral authentication allows 5003 for partial security in environments where client certificates are 5004 not widespread, and is better than no security at all; however, it 5005 does expose the Responding node to certain threats described in 5006 section 3.1 of [31]. For example, the Responding node cannot verify 5007 whether there is a man-in-the-middle between it and the Querying 5008 node, which could be manipulating the signalling messages, and it 5009 cannot verify the identity of the Querying node if it requests 5010 authorisation of resources. Note that in the case of host-network 5011 signalling, the Responding node could be either the host or the first 5012 hop router, depending on the signalling direction. Because of these 5013 vulnerabilities, modes or deployments of TLS which do not provide 5014 mutual authentication can be considered as at best transitional 5015 stages rather than providing a robust security solution. 5017 Certain security aspects of GIST operation depend on signalling 5018 application behaviour: a poorly implemented or compromised NSLP could 5019 degrade GIST security. However, the degradation would only affect 5020 GIST handling of the NSLP's own signalling traffic or overall 5021 resource usage at the node where the weakness occurred, and 5022 implementation weakness or compromise could have just as great an 5023 effect within the NSLP itself. GIST depends on NSLPs to choose SIDs 5024 appropriately (Section 4.1.3). If NSLPs choose non-random SIDs this 5025 makes off-path attacks based on SID guessing easier to carry out. 5026 NSLPs can also leak information in structured SIDs, but they could 5027 leak similar information in the NLSP payload data anyway. 5029 9. IANA Considerations 5031 This section defines the registries and initial codepoint assignments 5032 for GIST. It also defines the procedural requirements to be followed 5033 by IANA in allocating new codepoints. Note that the guidelines on 5034 the technical criteria to be followed in evaluating requests for new 5035 codepoint assignments are covered normatively in a separate document 5036 which considers the NSIS protocol suite in a unified way. That 5037 document discusses the general issue of NSIS extensibility, as well 5038 as the technical criteria for particular registries; see [13] for 5039 further details. 5041 The registry definitions that follow leave large blocks of codes 5042 marked "Reserved - not to be allocated". This is to allow a future 5043 revision of this specification or another Standards Track document to 5044 modify the relative space given to different allocation policies 5045 without having to change the initial rules retrospectively if they 5046 turn out to have been inappropriate, e.g. if the space for one 5047 particular policy is exhausted too quickly. 5049 The allocation policies used in this section follow the guidance 5050 given in [5]. In addition, for a number of the GIST registries, this 5051 specification also defines private/experimental ranges as discussed 5052 in [10]. Note that the only environment in which these codepoints 5053 can validly be used is a closed one in which the experimenter knows 5054 all the experiments in progress. 5056 This specification allocates the following codepoints in existing 5057 registries: 5059 Well-known UDP port XXX as the destination port for Q-mode 5060 encapsulated GIST messages (Section 5.3). 5062 This specification creates the following registries with the 5063 structures as defined below: 5065 NSLP Identifiers: Each signalling application requires the 5066 assignment of one or more NSLPIDs. The following NSLPID is 5067 allocated by this specification: 5069 +---------+---------------------------------------------------------+ 5070 | NSLPID | Application | 5071 +---------+---------------------------------------------------------+ 5072 | 0 | Used for GIST messages not related to any signalling | 5073 | | application. | 5074 +---------+---------------------------------------------------------+ 5076 Every other NSLPID that uses an MRM which requires RAO usage MUST 5077 be associated with a specific RAO value; multiple NSLPIDs MAY be 5078 associated with the same RAO value. RAO value assignments require 5079 a specification of the processing associated with messages that 5080 carry the value. NSLP specifications MUST normatively depend on 5081 this document for the processing, specifically Section 4.3.1, 5082 Section 4.3.4 and Section 5.3.2. The NSLPID is a 16 bit integer, 5083 and allocation policies for further values are as follows: 5085 1-32703: IESG Approval 5087 32704-32767: Private/Experimental Use 5089 32768-65536: Reserved - not to be allocated 5091 GIST Message Type: The GIST common header (Appendix A.1) contains a 5092 7-bit message type field. The following values are allocated by 5093 this specification: 5095 +---------+----------+ 5096 | MType | Message | 5097 +---------+----------+ 5098 | 0 | Query | 5099 | | | 5100 | 1 | Response | 5101 | | | 5102 | 2 | Confirm | 5103 | | | 5104 | 3 | Data | 5105 | | | 5106 | 4 | Error | 5107 | | | 5108 | 5 | MA-Hello | 5109 +---------+----------+ 5111 Allocation policies for further values are as follows: 5113 6-31: Standards Action 5115 32-55: Expert Review 5117 56-63: Private/Experimental Use 5119 64-127: Reserved - not to be allocated 5121 Object Types: There is a 12-bit field in the object header 5122 (Appendix A.2). The following values for object type are defined 5123 by this specification: 5125 +---------+-----------------------------+ 5126 | OType | Object Type | 5127 +---------+-----------------------------+ 5128 | 0 | Message Routing Information | 5129 | | | 5130 | 1 | Session ID | 5131 | | | 5132 | 2 | Network Layer Information | 5133 | | | 5134 | 3 | Stack Proposal | 5135 | | | 5136 | 4 | Stack Configuration Data | 5137 | | | 5138 | 5 | Query Cookie | 5139 | | | 5140 | 6 | Responder Cookie | 5141 | | | 5142 | 7 | NAT Traversal | 5143 | | | 5144 | 8 | NSLP Data | 5145 | | | 5146 | 9 | Error | 5147 | | | 5148 | 10 | Hello ID | 5149 +---------+-----------------------------+ 5151 Allocation policies for further values are as follows: 5153 10-1023: Standards Action 5155 1024-1999: Specification Required 5157 2000-2047: Private/Experimental Use 5159 2048-4095: Reserved - not to be allocated 5161 When a new object type is allocated according to one of the first 5162 two policies, the specification MUST provide the object format and 5163 define the setting of the extensibility bits (A/B, see 5164 Appendix A.2.1). 5166 Message Routing Methods: GIST allows multiple message routing 5167 methods (see Section 3.3). The MRM is indicated in the leading 5168 byte of the MRI object (Appendix A.3.1). This specification 5169 defines the following values: 5171 +------------+------------------------+ 5172 | MRM-ID | Message Routing Method | 5173 +------------+------------------------+ 5174 | 0 | Path Coupled MRM | 5175 | | | 5176 | 1 | Loose End MRM | 5177 +------------+------------------------+ 5179 Allocation policies for further values are as follows: 5181 2-63: Standards Action 5183 64-119: Expert Review 5185 120-127: Private/Experimental Use 5187 128-255: Reserved - not to be allocated 5189 When a new MRM is defined according to one of the first two 5190 policies, a specification document will be required. This MUST 5191 provide the information described in Section 3.3. 5193 MA-Protocol-IDs: Each protocol that can be used in a messaging 5194 association is identified by a 1-byte MA-Protocol-ID 5195 (Section 5.7). Note that the MA-Protocol-ID is not an IP Protocol 5196 number; indeed, some of the messaging association protocols - such 5197 as TLS - do not have an IP Protocol number. This is used as a tag 5198 in the Stack-Proposal and Stack-Configuration-Data objects 5199 (Appendix A.3.4 and Appendix A.3.5). The following values are 5200 defined by this specification: 5202 +---------------------+-----------------------------------------+ 5203 | MA-Protocol-ID | Protocol | 5204 +---------------------+-----------------------------------------+ 5205 | 0 | Reserved - not to be allocated | 5206 | | | 5207 | 1 | TCP opened in the forwards direction | 5208 | | | 5209 | 2 | TLS initiated in the forwards direction | 5210 +---------------------+-----------------------------------------+ 5212 Allocation policies for further values are as follows: 5214 3-63: Standards Action 5216 64-119: Expert Review 5218 120-127: Private/Experimental Use 5220 128-255: Reserved - not to be allocated 5222 When a new MA-Protocol-ID is allocated according to one of the 5223 first two policies, a specification document will be required. 5224 This MUST define the format for the MA-protocol-options field (if 5225 any) in the Stack-Configuration-Data object that is needed to 5226 define its configuration. If a protocol is to be used for 5227 reliable message transfer, it MUST be described how delivery 5228 errors are to be detected by GIST. Extensions to include new 5229 channel security protocols MUST include a description of how to 5230 integrate the functionality described in Section 3.9 with the rest 5231 of GIST operation. If the new MA-Protocol-ID can be used in 5232 conjunction with existing ones (for example, a new transport 5233 protocol which could be used with Transport Layer Security), the 5234 specification MUST define the interaction between the two. 5236 Error Codes/Subcodes: There is a 2 byte error code and 1 byte 5237 subcode in the Value field of the Error object (Appendix A.4.1). 5238 Error codes 1-12 are defined in Appendix A.4.4 together with 5239 subcodes 0-5 (code 1), 0-5 (code 9), 0-5 (code 10), and 0-2 (code 5240 12). Additional codes and subcodes are allocated on a first-come, 5241 first-served basis. When a new code/subcode combination is 5242 allocated, the following information MUST be provided: 5244 Error case: textual name of error 5246 Error class: from the categories given in Appendix A.4.3 5248 Error code: allocated by IANA, if a new code is required 5250 Error subcode: subcode point, also allocated by IANA 5252 Additional information: what additional information fields it is 5253 mandatory to include in the error message, from Appendix A.4.2 5255 Additional Information Types: An Error object (Appendix A.4.1) may 5256 contain Additional Information fields. Each possible field type 5257 is identified by a 16-bit AI-Type. AI-Types 1-4 are defined in 5258 Appendix A.4.2; additional AI-Types are allocated on a first-come, 5259 first-served basis. 5261 10. Acknowledgements 5263 This document is based on the discussions within the IETF NSIS 5264 working group. It has been informed by prior work and formal and 5265 informal inputs from: Cedric Aoun, Attila Bader, Vitor Bernado, 5266 Roland Bless, Bob Braden, Marcus Brunner, Benoit Campedel, Yoshiko 5267 Chong, Luis Cordeiro, Elwyn Davies, Michel Diaz, Christian Dickmann, 5268 Pasi Eronen, Alan Ford, Xiaoming Fu, Bo Gao, Ruediger Geib, Eleanor 5269 Hepworth, Thomas Herzog, Cheng Hong, Teemu Huovila, Jia Jia, Cornelia 5270 Kappler, Georgios Karagiannis, Ruud Klaver, Max Laier, Chris Lang, 5271 Lauri Liuhto, John Loughney, Allison Mankin, Jukka Manner, Pete 5272 McCann, Andrew McDonald, Mac McTiffin, Glenn Morrow, Dave Oran, 5273 Andreas Pashalidis, Henning Peters, Tom Phelan, Akbar Rahman, Takako 5274 Sanda, Charles Shen, Melinda Shore, Martin Stiemerling, Martijn 5275 Swanink, Mike Thomas, Hannes Tschofenig, Sven van den Bosch, Nuutti 5276 Varis, Michael Welzl, Lars Westberg, and Mayi Zoumaro-djayoon. Parts 5277 of the TLS usage description (Section 5.7.3) were derived from the 5278 Diameter base protocol specification, RFC3588. In addition, Hannes 5279 Tschofenig provided a detailed set of review comments on the security 5280 section, and Andrew McDonald provided the formal description for the 5281 initial packet formats and the name matching algorithm for TLS. 5282 Chris Lang's implementation work provided objective feedback on the 5283 clarity and feasibility of the specification, and he also provided 5284 the state machine description and the initial error catalogue and 5285 formats. Magnus Westerlund carried out a detailed AD review which 5286 identified a number of issues and led to significant clarifications, 5287 which was followed by an even more detailed IESG review, with 5288 comments from Jari Arkko, Ross Callon, Brian Carpenter, Lisa 5289 Dusseault, Lars Eggert, Ted Hardie, Sam Hartman, Russ Housley, Cullen 5290 Jennings, Tim Polk, and a very detailed analysis by Adrian Farrel 5291 from the Routing Area directorate; Suresh Krishnan carried out a 5292 detailed review for the Gen-ART. 5294 11. References 5296 11.1. Normative References 5298 [1] Braden, R., "Requirements for Internet Hosts - Communication 5299 Layers", STD 3, RFC 1122, October 1989. 5301 [2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 5302 June 1995. 5304 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 5305 Levels", BCP 14, RFC 2119, March 1997. 5307 [4] Schiller, J., "Cryptographic Algorithms for Use in the Internet 5308 Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005. 5310 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 5311 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 5313 [6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 5314 Specification", RFC 2460, December 1998. 5316 [7] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 5317 the Differentiated Services Field (DS Field) in the IPv4 and 5318 IPv6 Headers", RFC 2474, December 1998. 5320 [8] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 5321 RFC 2765, February 2000. 5323 [9] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, 5324 R., and W. Polk, "Internet X.509 Public Key Infrastructure 5325 Certificate and Certificate Revocation List (CRL) Profile", 5326 RFC 5280, May 2008. 5328 [10] Narten, T., "Assigning Experimental and Testing Numbers 5329 Considered Useful", BCP 82, RFC 3692, January 2004. 5331 [11] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 5332 Protocol Version 1.2", RFC 5246, August 2008. 5334 [12] Crocker, D. and P. Overell, "Augmented BNF for Syntax 5335 Specifications: ABNF", STD 68, RFC 5234, January 2008. 5337 [13] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and 5338 Extending the NSIS Protocol Family", draft-ietf-nsis-ext-02 5339 (work in progress), March 2009. 5341 11.2. Informative References 5343 [14] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 5345 [15] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 5346 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 5347 Specification", RFC 2205, September 1997. 5349 [16] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 5350 RFC 2246, January 1999. 5352 [17] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 5354 [18] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 5355 RFC 2711, October 1999. 5357 [19] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP 5358 Operation Over IP Tunnels", RFC 2746, January 2000. 5360 [20] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 5361 IPv4 Clouds", RFC 3056, February 2001. 5363 [21] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 5364 RFC 3068, June 2001. 5366 [22] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 5367 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 5368 September 2001. 5370 [23] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and 5371 G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 5372 RFC 3209, December 2001. 5374 [24] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., 5375 Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., 5376 Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint- 5377 Based LSP Setup using LDP", RFC 3212, January 2002. 5379 [25] Grossman, D., "New Terminology and Clarifications for 5380 Diffserv", RFC 3260, April 2002. 5382 [26] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 5383 Haukka, "Security Mechanism Agreement for the Session 5384 Initiation Protocol (SIP)", RFC 3329, January 2003. 5386 [27] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 5387 Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. 5389 [28] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 5390 Relays around NAT (TURN): Relay Extensions to Session 5391 Traversal Utilities for NAT (STUN)", draft-ietf-behave-turn-14 5392 (work in progress), April 2009. 5394 [29] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, 5395 July 2004. 5397 [30] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 5398 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 5399 June 2005. 5401 [31] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 5402 Steps in Signaling (NSIS)", RFC 4081, June 2005. 5404 [32] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 5405 Requirements for Security", BCP 106, RFC 4086, June 2005. 5407 [33] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 5408 Transport Layer Security (TLS)", RFC 4279, December 2005. 5410 [34] Conta, A., Deering, S., and M. Gupta, "Internet Control Message 5411 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 5412 Specification", RFC 4443, March 2006. 5414 [35] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/ 5415 Firewall NSIS Signaling Layer Protocol (NSLP)", 5416 draft-ietf-nsis-nslp-natfw-20 (work in progress), 5417 November 2008. 5419 [36] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 5420 IPv6 Hosts and Routers", RFC 4213, October 2005. 5422 [37] Kent, S. and K. Seo, "Security Architecture for the Internet 5423 Protocol", RFC 4301, December 2005. 5425 [38] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 5426 Nordmark, "Mobile IP Version 6 Route Optimization Security 5427 Design Background", RFC 4225, December 2005. 5429 [39] Audet, F. and C. Jennings, "Network Address Translation (NAT) 5430 Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, 5431 January 2007. 5433 [40] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 5434 September 2007. 5436 [41] Aoun, C. and E. Davies, "Reasons to Move the Network Address 5437 Translator - Protocol Translator (NAT-PT) to Historic Status", 5438 RFC 4966, July 2007. 5440 [42] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, 5441 "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, 5442 October 2007. 5444 [43] Floyd, S. and V. Jacobson, "The Synchronisation of Periodic 5445 Routing Messages", SIGCOMM Symposium on Communications 5446 Architectures and Protocols pp. 33--44, September 1993. 5448 [44] Hancock, R E., "Using the Router Alert Option for Packet 5449 Interception in GIST", draft-hancock-nsis-gist-rao-00 (work in 5450 progress), July 2008. 5452 [45] Pashalidis, A. and H. Tschofenig, "GIST Legacy NAT Traversal", 5453 draft-pashalidis-nsis-gist-legacynats-02 (work in progress), 5454 July 2007. 5456 [46] Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal", 5457 draft-pashalidis-nsis-gimps-nattraversal-05 (work in progress), 5458 July 2007. 5460 [47] Tsenov, T., Tschofenig, H., Fu, X., Aoun, C., and E. Davies, 5461 "GIST State Machine", draft-ietf-nsis-ntlp-statemachine-06 5462 (work in progress), November 2008. 5464 [48] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 5465 Robustness to Blind In-Window Attacks", 5466 draft-ietf-tcpm-tcpsecure-11 (work in progress), November 2008. 5468 Appendix A. Bit-Level Formats and Error Messages 5470 This appendix provides formats for the various component parts of the 5471 GIST messages defined abstractly in Section 5.2. The whole of this 5472 appendix is normative. 5474 Each GIST message consists of a header and a sequence of objects. 5475 The GIST header has a specific format, described in more detail in 5476 Appendix A.1 below. An NSLP message is one object within a GIST 5477 message. Note that GIST itself provides the NSLP message length 5478 information and signalling application identification. General 5479 object formatting guidelines are provided in Appendix A.2 below, 5480 followed in Appendix A.3 by the format for each object. Finally, 5481 Appendix A.4 provides the formats used for error reporting. 5483 In the following object diagrams, '//' is used to indicate a variable 5484 sized field and ':' is used to indicate a field that is optionally 5485 present. Any part of the object used for padding or defined as 5486 reserved (marked 'Reserved' or 'Rsv' or, in the case of individual 5487 bits, 'r' in the diagrams below) MUST be set to 0 on transmission and 5488 MUST be ignored on reception. 5490 The objects are encoded using big endian (network byte order). 5492 A.1. The GIST Common Header 5494 This header begins all GIST messages. It has a fixed format, as 5495 shown below. 5497 0 1 2 3 5498 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 5499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5500 | Version | GIST hops | Message Length | 5501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5502 | NSLPID |C| Type |S|R|E| Reserved| 5503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5505 Version (8 bits): The GIST protocol version number. This 5506 specification defines version number 1. 5508 GIST hops (8 bits): A hop count for the number of GIST-aware nodes 5509 this message can still be processed by (including the 5510 destination). 5512 Message Length (16 bits): The total number of 32-bit words in the 5513 message after the common header itself. 5515 NSLPID (16 bits): IANA assigned identifier of the signalling 5516 application the message refers to. 5518 C flag: C=1 if the message has to be able to be interpreted in the 5519 absence of routing state (Section 5.2.1). 5521 Type (7 bits): The GIST message type (Query, Response, etc.). 5523 S flag: S=1 if the IP source address is the same as the signalling 5524 source address, S=0 if it is different. 5526 R flag: R=1 if a reply to this message is explicitly requested. 5528 E flag: E=1 if the message was explicitly routed (Section 7.1.5). 5530 The rules governing the use of the R-flag depend on the GIST message 5531 type. It MUST always be set (R=1) in Query messages, since these 5532 always elicit a Response, and never in Confirm, Data or Error 5533 messages. It MAY be set in an MA-Hello; if set, another MA-Hello 5534 MUST be sent in reply. It MAY be set in a Response, but MUST be set 5535 if the Response contains a Responder cookie; if set, a Confirm MUST 5536 be sent in reply. The E flag MUST NOT be set unless the message type 5537 is a Data message. 5539 Parsing failures may be caused by unknown Version or Type values, 5540 inconsistent C, R or E flag setting, or a Message Length inconsistent 5541 with the set of objects carried. In all cases the receiver MUST if 5542 possible return a "Common Header Parse Error" message 5543 (Appendix A.4.4.1) with the appropriate subcode, and not process the 5544 message further. 5546 A.2. General Object Format 5548 Each object begins with a fixed header giving the object Type and 5549 object Length. This is followed by the object Value, which is a 5550 whole number of 32-bit words long. 5552 0 1 2 3 5553 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 5554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5555 |A|B|r|r| Type |r|r|r|r| Length | 5556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5557 // Value // 5558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5559 A/B flags: The bits marked 'A' and 'B' are extensibility flags which 5560 are defined in Appendix A.2.1 below; the remaining bits marked 'r' 5561 are reserved. 5563 Type (12 bits): An IANA-assigned identifier for the type of object. 5565 Length (12 bits): Length has the units of 32-bit words, and measures 5566 the length of Value. If there is no Value, Length=0. If the 5567 Length is not consistent with the contents of the object, an 5568 "Object Value Error" message (Appendix A.4.4.10) with subcode 0 5569 "Incorrect Length" MUST be returned and the message dropped. 5571 Value (variable): Value is (therefore) a whole number of 32 bit 5572 words. If there is any padding required, the length and location 5573 are be defined by the object-specific format information; objects 5574 which contain variable length (e.g. string) types may need to 5575 include additional length subfields to do so. 5577 A.2.1. Object Extensibility 5579 The leading two bits of the TLV header are used to signal the desired 5580 treatment for objects whose Type field is unknown at the receiver. 5581 The following three categories of object have been identified, and 5582 are described here. 5584 AB=00 ("Mandatory"): If the object is not understood, the entire 5585 message containing it MUST be rejected with an "Object Type Error" 5586 message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object"). 5588 AB=01 ("Ignore"): If the object is not understood, it MUST be 5589 deleted and the rest of the message processed as usual. 5591 AB=10 ("Forward"): If the object is not understood, it MUST be 5592 retained unchanged in any message forwarded as a result of message 5593 processing, but not stored locally. 5595 The combination AB=11 is reserved. If a message is received 5596 containing an object with AB=11, it MUST be rejected with an "Object 5597 Type Error" message (Appendix A.4.4.9) with subcode 5 ("Invalid 5598 Extensibility Flags"). 5600 These extensibility rules define only the processing within the GIST 5601 layer. There is no requirement on GIST implementations to support an 5602 extensible service interface to signalling applications, so 5603 unrecognised objects with AB=01 or AB=10 do not need to be indicated 5604 to NSLPs. 5606 A.3. GIST TLV Objects 5608 A.3.1. Message-Routing-Information 5610 Type: Message-Routing-Information 5612 Length: Variable (depends on MRM) 5614 0 1 2 3 5615 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 5616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5617 | MRM-ID |N| Reserved | | 5618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 5619 // Method-specific addressing information (variable) // 5620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5622 MRM-ID (8 bits): An IANA-assigned identifier for the message routing 5623 method. 5625 N flag: If set (N=1), this means that NATs do not need to translate 5626 this MRM; if clear (N=0) it means that the method-specific 5627 information contains network or transport layer information that a 5628 NAT must process. 5630 The remainder of the object contains method-specific addressing 5631 information, which is described below. 5633 A.3.1.1. Path-Coupled MRM 5635 In the case of basic path-coupled routing, the addressing information 5636 takes the following format. The N-flag N=0 for this MRM. 5638 0 1 2 3 5639 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 5640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5641 |IP-Ver |P|T|F|S|A|B|D|Reserved | 5642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5643 // Source Address // 5644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5645 // Destination Address // 5646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5647 | Source Prefix | Dest Prefix | Protocol | DS-field |Rsv| 5648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5649 : Reserved | Flow Label : 5650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5651 : SPI : 5652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5653 : Source Port : Destination Port : 5654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5656 IP-Ver (4 bits): The IP version number, 4 or 6. 5658 Source/Destination address (variable): The source and destination 5659 addresses are always present and of the same type; their length 5660 depends on the value in the IP-Ver field. 5662 Source/Dest Prefix (each 8 bits): The length of the mask to be 5663 applied to the source and destination addresses for address 5664 wildcarding. In the normal case where the MRI refers only to 5665 traffic between specific host addresses, the Source/Dest Prefix 5666 values would both be 32/128 for IPv4/6 respectively. 5668 P flag: P=1 means that the Protocol field is significant. 5670 Protocol (8 bits): The IP protocol number. This MUST be ignored if 5671 P=0. In the case of IPv6, the Protocol field refers to the true 5672 upper layer protocol carried by the packets, i.e. excluding any IP 5673 option headers. This is therefore not necessarily the same as the 5674 Next Header value from the base IPv6 header. 5676 T flag: T=1 means that the DiffServ field (DS-field) is significant. 5678 DS-field (6 bits): The DiffServ field. See [7] and [25]. 5680 F flag: F=1 means that flow label is present and is significant. F 5681 MUST NOT be set if IP-Ver is not 6. 5683 Flow Label (20 bits): The flow label; only present if F=1. If F=0, 5684 the entire 32 bit word containing the Flow Label is absent. 5686 S flag: S=1 means that the SPI field is present and is significant. 5687 The S flag MUST be 0 if the P flag is 0. 5689 SPI field (32 bits): The SPI field; see [37]. If S=0, the entire 32 5690 bit word containing the SPI is absent. 5692 A/B flags: These can only be set if P=1. If either is set, the port 5693 fields are also present. If P=0, the A/B flags MUST both be zero 5694 and the word containing the port numbers is absent. 5696 Source/Destination Port (each 16 bits): If either of A (source), B 5697 (destination) is set the word containing the port numbers is 5698 included in the object. However, the contents of each field is 5699 only significant if the corresponding flag is set; otherwise, the 5700 contents of the field is regarded as padding, and the MRI refers 5701 to all ports (i.e. acts as a wildcard). If the flag is set and 5702 Port=0x0000, the MRI will apply to a specific port, whose value is 5703 not yet known. If neither of A or B is set, the word is absent. 5705 D flag: The Direction flag has the following meaning: the value 0 5706 means 'in the same direction as the flow' (i.e. downstream), and 5707 the value 1 means 'in the opposite direction to the flow' (i.e. 5708 upstream). 5710 The MRI format defines a number of constraints on the allowed 5711 combinations of flags and fields in the object. If these constraints 5712 are violated this constitutes a parse error, and an "Object Value 5713 Error" message (Appendix A.4.4.10) with subcode 2 ("Invalid Flag- 5714 Field Combination") MUST be returned. 5716 A.3.1.2. Loose-End MRM 5718 In the case of the loose-end MRM, the addressing information takes 5719 the following format. The N-flag N=0 for this MRM. 5721 0 1 2 3 5722 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 5723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5724 |IP-Ver |D| Reserved | 5725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5726 // Source Address // 5727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5728 // Destination Address // 5729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5730 IP-Ver (4 bits): The IP version number, 4 or 6. 5732 Source/Destination address (variable): The source and destination 5733 addresses are always present and of the same type; their length 5734 depends on the value in the IP-Ver field. 5736 D flag: The Direction flag has the following meaning: the value 0 5737 means 'towards the edge of the network', and the value 1 means 5738 'from the edge of the network'. Note that for Q-mode messages, 5739 the only valid value is D=0 (see Section 5.8.2). 5741 A.3.2. Session Identification 5743 Type: Session-Identification 5745 Length: Fixed (4 32-bit words) 5747 0 1 2 3 5748 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 5749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5750 | | 5751 + + 5752 | | 5753 + Session ID + 5754 | | 5755 + + 5756 | | 5757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5759 A.3.3. Network-Layer-Information 5761 Type: Network-Layer-Information 5763 Length: Variable (depends on length of Peer-Identity and IP version) 5765 0 1 2 3 5766 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 5767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5768 | PI-Length | IP-TTL |IP-Ver | Reserved | 5769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5770 | Routing State Validity Time | 5771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5772 // Peer Identity // 5773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5774 // Interface Address // 5775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5776 PI-Length (8 bits): The byte length of the Peer Identity field. 5778 Peer Identity (variable): The Peer Identity field. Note that the 5779 Peer-Identity field itself is padded to a whole number of words. 5781 IP-TTL (8 bits): Initial or reported IP layer TTL. 5783 IP-Ver (4 bits): The IP version for the Interface Address field. 5785 Interface Address (variable): The IP address allocated to the 5786 interface, matching the IP-Ver field. 5788 Routing State Validity Time (32 bits): The time for which the 5789 routing state for this flow can be considered correct without a 5790 refresh. Given in milliseconds. The value 0 (zero) is reserved 5791 and MUST NOT be used. 5793 A.3.4. Stack Proposal 5795 Type: Stack-Proposal 5797 Length: Variable (depends on number of profiles and size of each 5798 profile) 5800 0 1 2 3 5801 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 5802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5803 | Prof-Count | Reserved | 5804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5805 // Profile 1 // 5806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5807 : : 5808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5809 // Profile N // 5810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5811 Prof-Count (8 bits): The number of profiles listed. MUST be > 0. 5813 Each profile is itself a sequence of protocol layers, and the profile 5814 is formatted as a list as follows: 5816 o The first byte is a count of the number of layers in the profile. 5817 MUST be > 0. 5819 o This is followed by a sequence of 1-byte MA-Protocol-IDs as 5820 described in Section 5.7. 5822 o The profile is padded to a word boundary with 0, 1, 2 or 3 zero 5823 bytes. These bytes MUST be ignored at the receiver. 5825 If there are no profiles (Prof-Count=0) then an "Object Value Error" 5826 message (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") 5827 MUST be returned; if a particular profile is empty (the leading byte 5828 of the profile is zero), then subcode 3 ("Empty List") MUST be used. 5829 In both cases, the message MUST be dropped. 5831 A.3.5. Stack-Configuration-Data 5833 Type: Stack-Configuration-Data 5835 Length: Variable (depends on number of protocols and size of each 5836 MA-protocol-options field) 5838 0 1 2 3 5839 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 5840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5841 | MPO-Count | Reserved | 5842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5843 | MA-Hold-Time | 5844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5845 // MA-protocol-options 1 // 5846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5847 : : 5848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5849 // MA-protocol-options N // 5850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5852 MPO-Count (8 bits): The number of MA-protocol-options fields present 5853 (these contain their own length information). The MPO-Count MAY 5854 be zero, but this will only be the case if none of the MA- 5855 protocols referred to in the Stack-Proposal require option data. 5857 MA-Hold-Time (32 bits): The time for which the messaging association 5858 will be held open without traffic or a hello message. Note that 5859 this value is given in milliseconds, so the default time of 30 5860 seconds (Section 4.4.5) corresponds to a value of 30000. The 5861 value 0 (zero) is reserved and MUST NOT be used. 5863 The MA-protocol-options fields are formatted as follows: 5865 0 1 2 3 5866 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 5867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5868 |MA-Protocol-ID | Profile | Length |D| Reserved | 5869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5870 // Options Data // 5871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5873 MA-Protocol-ID (8 bits): Protocol identifier as described in 5874 Section 5.7. 5876 Profile (8 bits): Tag indicating which profile from the accompanying 5877 Stack-Proposal object this applies to. Profiles are numbered from 5878 1 upwards; the special value 0 indicates 'applies to all 5879 profiles'. 5881 Length (8 bits): The byte length of MA-protocol-options field that 5882 follows. This will be zero-padded up to the next word boundary. 5884 D flag: If set (D=1), this protocol MUST NOT be used for a messaging 5885 association. 5887 Options Data (variable): Any options data for this protocol. Note 5888 that the format of the options data might differ depending on 5889 whether the field is in a Query or Response. 5891 A.3.6. Query Cookie 5893 Type: Query-Cookie 5895 Length: Variable (selected by querying node) 5897 0 1 2 3 5898 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 5899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5900 // Query Cookie // 5901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5903 The contents are implementation defined. See Section 8.5 for further 5904 discussion. 5906 A.3.7. Responder Cookie 5907 Type: Responder-Cookie 5909 Length: Variable (selected by responding node) 5911 0 1 2 3 5912 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 5913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5914 // Responder Cookie // 5915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5917 The contents are implementation defined. See Section 8.5 for further 5918 discussion. 5920 A.3.8. Hello-ID 5922 Type: Hello-ID 5924 Length: Fixed (1 32-bit word) 5926 0 1 2 3 5927 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 5928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5929 | Hello-ID | 5930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5932 The contents are implementation defined. See Section 5.2.2 for 5933 further discussion. 5935 A.3.9. NAT Traversal 5937 Type: NAT-Traversal 5939 Length: Variable (depends on length of contained fields) 5941 This object is used to support the NAT traversal mechanisms described 5942 in Section 7.2.2. 5944 0 1 2 3 5945 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 5946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5947 | MRI-Length | Type-Count | NAT-Count | Reserved | 5948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5949 // Original Message-Routing-Information // 5950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5951 // List of translated objects // 5952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5953 | Length of opaque information | | 5954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 5955 // Information replaced by NAT #1 | 5956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5957 : : 5958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5959 | Length of opaque information | | 5960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 5961 // Information replaced by NAT #N | 5962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5964 MRI-Length (8 bits): The length of the included MRI payload in 32- 5965 bit words. 5967 Original Message-Routing-Information (variable): The MRI data from 5968 when the message was first sent, not including the object header. 5970 Type-Count (8 bits): The number of objects in the 'List of 5971 translated objects' field. 5973 List of translated objects (variable): This field lists the types of 5974 the objects that were translated by every NAT through which the 5975 message has passed. Each element in the list is a 16-bit field 5976 containing the first 16 bits of the object TLV header, including 5977 the AB extensibility flags, two reserved bits, and 12 bit object 5978 type. The list is initialised by the first NAT on the path; 5979 subsequent NATs may delete elements in the list. Padded with 2 5980 null bytes if necessary. 5982 NAT-Count (8 bits): The number of NATs traversed by the message, and 5983 the number of opaque payloads at the end of the object. The 5984 length fields for each opaque payload are byte counts, not 5985 including the 2 bytes of the length field itself. Note that each 5986 opaque information field is zero-padded to the next 32-bit word 5987 boundary if necessary. 5989 A.3.10. NSLP Data 5991 Type: NSLP-Data 5993 Length: Variable (depends on NSLP) 5995 This object is used to deliver data between NSLPs. GIST regards the 5996 data as a number of complete 32-bit words, as given by the length 5997 field in the TLV; any padding to a word boundary must be carried out 5998 within the NSLP itself. 6000 0 1 2 3 6001 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 6002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6003 // NSLP Data // 6004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6006 A.4. Errors 6008 A.4.1. Error Object 6010 Type: Error 6012 Length: Variable (depends on error) 6013 0 1 2 3 6014 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 6015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6016 | Error Class | Error Code | Error Subcode | 6017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6018 |S|M|C|D|Q| Reserved | MRI Length | Info Count | 6019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6020 | | 6021 + Common Header + 6022 | (of original message) | 6023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6024 : Session Id : 6025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6026 : Message Routing Information : 6027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6028 : Additional Information Fields : 6029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6030 : Debugging Comment : 6031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6033 The flags are: 6034 S - S=1 means the Session ID object is present 6035 M - M=1 means MRI object is present 6036 C - C=1 means a debug Comment is present after header. 6037 D - D=1 means the original message was received in D-mode 6038 Q - Q=1 means the original message was received Q-mode encapsulated 6039 (can't be set if D=0). 6041 A GIST Error object contains an 8 bit error-class (see 6042 Appendix A.4.3), a 16 bit error-code, an 8 bit error-subcode, and as 6043 much information about the message which triggered the error as is 6044 available. This information MUST include the Common header of the 6045 original message and MUST also include the Session Id and MRI objects 6046 if these could be decoded correctly. These objects are included in 6047 their entirety, except for their TLV Headers. The MRI Length field 6048 gives the length of the MRI object in 32-bit words. 6050 The Info Count field contains the number of Additional Information 6051 fields in the object, and the possible formats for these fields are 6052 given in Appendix A.4.2. The precise set of fields to include 6053 depends on the error code/subcode. For every error description in 6054 the error catalogue Appendix A.4.4, the line "Additional Info:" 6055 states what fields MUST be included; further fields beyond these MAY 6056 be included by the sender, and the fields may be included in any 6057 order. The Debugging Comment is a null-terminated UTF-8 string, 6058 padded if necessary to a whole number of 32- bit words with more null 6059 characters. 6061 A.4.2. Additional Information Fields 6063 The Common Error Header may be followed by some Additional 6064 Information fields. Each Additional Information field has a simple 6065 TLV format as follows: 6066 0 1 2 3 6067 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 6068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6069 | AI-Type | AI-Length | 6070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6071 // AI-Value // 6072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6074 The AI-Type is a 16-bit IANA assigned value. The AI-Length gives the 6075 number of 32-bit words in AI-Value; if an AI-Value is not present, 6076 AI-Length=0. The AI-Types and AI-Lengths and AI-Value formats of the 6077 currently defined Additional Information fields are shown below. 6079 Message Length Info: 6080 0 1 2 3 6081 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 6082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6083 | Calculated Length | Reserved | 6084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6085 AI-Type: 1 6086 AI-Length: 1 6087 Calculated Length (16 bits): the length of the original message 6088 calculated by adding up all the objects in the message. Measured in 6089 32-bit words. 6091 MTU Info: 6092 0 1 2 3 6093 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 6094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6095 | Link MTU | Reserved | 6096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6097 AI-Type: 2 6098 AI-Length: 1 6099 Link MTU (16 bits): the IP MTU for a link along which a message 6100 could not be sent. Measured in bytes. 6102 Object Type Info: 6104 0 1 2 3 6105 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 6106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6107 | Object Type | Reserved | 6108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6109 AI-Type: 3 6110 AI-Length: 1 6111 Object type (16 bits): This provides information about the type 6112 of object which caused the error. 6114 Object Value Info: 6115 0 1 2 3 6116 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 6117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6118 | Rsv | Real Object Length | Offset | 6119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6120 // Object // 6121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6122 AI-Type: 4 6123 AI-Length: variable (depends on Object length) 6124 This object carries information about a TLV object which was found 6125 to be invalid in the original message. An error message MAY contain 6126 more than one Object Value Info object. 6128 Real Object Length (12 bits) Since the length in the original TLV 6129 header may be inaccurate, this field provides the actual length of 6130 the object (including the TLV Header) included in the error 6131 message. Measured in 32-bit words. 6133 Offset (16 bits): The byte in the object at which the GIST node 6134 found the error. The first byte in the object has offset=0. 6136 Object (variable): The invalid TLV object (including the TLV 6137 Header). 6139 A.4.3. Error Classes 6141 The first byte of the error object, "Error Class", indicates the 6142 severity level. The currently defined severity levels are: 6144 0 (Informational): reply data which should not be thought of as 6145 changing the condition of the protocol state machine. 6147 1 (Success): reply data which indicates that the message being 6148 responded to has been processed successfully in some sense. 6150 2 (Protocol-Error): the message has been rejected because of a 6151 protocol error (e.g. an error in message format). 6153 3 (Transient-Failure): the message has been rejected because of a 6154 particular local node status which may be transient (i.e. it may 6155 be worthwhile to retry after some delay). 6157 4 (Permanent-Failure): the message has been rejected because of 6158 local node status which will not change without additional out of 6159 band (e.g. management) operations. 6161 Additional error class values are reserved. 6163 The allocation of error classes to particular errors is not precise; 6164 the above descriptions are deliberately informal. Actual error 6165 processing SHOULD take into account the specific error in question; 6166 the error class may be useful supporting information (e.g. in network 6167 debugging). 6169 A.4.4. Error Catalogue 6171 This section lists all the possible GIST errors, including when they 6172 are raised and what additional information fields MUST be carried in 6173 the error object. 6175 A.4.4.1. Common Header Parse Error 6177 Class: Protocol-Error 6178 Code: 1 6179 Additional Info: For subcode 3 only, Message Length Info carries 6180 the calculated message length. 6182 This message is sent if a GIST node receives a message where the 6183 common header cannot be parsed correctly, or where an error in the 6184 overall message format is detected. Note that in this case the 6185 original MRI and Session ID MUST NOT be included in the Error Object. 6186 This error code is split into subcodes as follows: 6188 0: Unknown Version: The GIST version is unknown. The (highest) 6189 supported version supported by the node can be inferred from the 6190 Common Header of the Error message itself. 6192 1: Unknown Type: The GIST message type is unknown. 6194 2: Invalid R-flag: The R flag in the header is inconsistent with the 6195 message type. 6197 3: Incorrect Message Length: The overall message length is not 6198 consistent with the set of objects carried. 6200 4: Invalid E-flag: The E flag is set in the header but this is not a 6201 Data message. 6203 5: Invalid C-flag: The C flag was set on something other than a 6204 Query message or Q-mode Data message, or was clear on a Query 6205 message. 6207 A.4.4.2. Hop Limit Exceeded 6209 Class: Permanent-Failure 6210 Code: 2 6211 Additional Info: None 6213 This message is sent if a GIST node receives a message with a GIST 6214 hop count of zero, or a GIST node tries to forward a message after 6215 its GIST hop count has been decremented to zero on reception. This 6216 message indicates either a routing loop or too small an initial hop 6217 count value. 6219 A.4.4.3. Incorrect Encapsulation 6221 Class: Protocol-Error 6222 Code: 3 6223 Additional Info: None 6225 This message is sent if a GIST node receives a message which uses an 6226 incorrect encapsulation method (e.g. a Query arrives over an MA, or 6227 the Confirm for a handshake that sets up a messaging association 6228 arrives in D mode). 6230 A.4.4.4. Incorrectly Delivered Message 6232 Class: Protocol-Error 6233 Code: 4 6234 Additional Info: None 6236 This message is sent if a GIST node receives a message over an MA 6237 which is not associated with the MRI/NSLPID/SID combination in the 6238 message. 6240 A.4.4.5. No Routing State 6242 Class: Protocol-Error 6243 Code: 5 6244 Additional Info: None 6245 This message is sent if a node receives a message for which routing 6246 state should exist, but has not yet been created and thus there is no 6247 appropriate Querying-SM or Responding-SM. This can occur on 6248 receiving a Data or Confirm message at a node whose policy requires 6249 routing state to exist before such messages can be accepted. See 6250 also Section 6.1 and Section 6.3. 6252 A.4.4.6. Unknown NSLPID 6254 Class: Permanent-Failure 6255 Code: 6 6256 Additional Info: None 6258 This message is sent if a router receives a directly addressed 6259 message for an NSLP which it does not support. 6261 A.4.4.7. Endpoint Found 6263 Class: Permanent-Failure 6264 Code: 7 6265 Additional Info: None 6267 This message is sent if a GIST node at a flow endpoint receives a 6268 Query message for an NSLP which it does not support. 6270 A.4.4.8. Message Too Large 6272 Class: Permanent-Failure 6273 Code: 8 6274 Additional Info: MTU Info 6276 A router receives a message which it can't forward because it exceeds 6277 the IP MTU on the next or subsequent hops. 6279 A.4.4.9. Object Type Error 6281 Class: Protocol-Error 6282 Code: 9 6283 Additional Info: Object Type Info 6285 This message is sent if a GIST node receives a message containing a 6286 TLV object with an invalid type. The message indicates the object 6287 type at fault in the additional info field. This error code is split 6288 into subcodes as follows: 6290 0: Duplicate Object: This subcode is used if a GIST node receives a 6291 message containing multiple instances of an object which may only 6292 appear once in a message. In the current specification, this 6293 applies to all objects. 6295 1: Unrecognised Object: This subcode is used if a GIST node receives 6296 a message containing an object which it does not support, and the 6297 extensibility flags AB=00. 6299 2: Missing Object: This subcode is used if a GIST node receives a 6300 message which is missing one or more mandatory objects. This 6301 message is also sent if a Stack-Proposal is sent without a 6302 matching Stack-Configuration-Data object when one was necessary, 6303 or vice versa. 6305 3: Invalid Object Type: This subcode is used if the object type is 6306 known, but it is not valid for this particular GIST message type. 6308 4: Untranslated Object: This subcode is used if the object type is 6309 known and is mandatory to interpret, but it contains addressing 6310 data which has not been translated by an intervening NAT. 6312 5: Invalid Extensibility Flags: This subcode is used if an object is 6313 received with the extensibility flags AB=11. 6315 A.4.4.10. Object Value Error 6317 Class: Protocol-Error 6318 Code: 10 6319 Additional Info: 1 or 2 Object Value Info fields as given below 6321 This message is sent if a node receives a message containing an 6322 object which cannot be properly parsed. The error message contains a 6323 single Object Value Info object, except for subcode 5 as stated 6324 below. This error code is split into subcodes as follows: 6326 0: Incorrect Length: The overall length does not match the object 6327 length calculated from the object contents. 6329 1: Value Not Supported: The value of a field is not supported by the 6330 GIST node. 6332 2: Invalid Flag-Field Combination: An object contains an invalid 6333 combination of flags and/or fields. At the moment this only 6334 relates to the Path-Coupled MRI (Appendix A.3.1.1), but in future 6335 there may be more. 6337 3: Empty List: At the moment this only relates to Stack-Proposals. 6338 The error message is sent if a stack proposal with a length > 0 6339 contains only null bytes (a length of 0 is handled as "Value Not 6340 Supported"). 6342 4: Invalid Cookie: The message contains a cookie which could not be 6343 verified by the node. 6345 5: Stack-Proposal - Stack-Configuration-Data Mismatch: This subcode 6346 is used if a GIST node receives a message in which the data in the 6347 Stack-Proposal object is inconsistent with the information in the 6348 Stack Configuration Data object. In this case, both the Stack- 6349 Proposal object and Stack-Configuration-Data object MUST be 6350 included in separate Object Value Info fields in that order. 6352 A.4.4.11. Invalid IP layer TTL 6354 Class: Permanent-Failure 6355 Code: 11 6356 Additional Info: None 6358 This error indicates that a message was received with an IP layer TTL 6359 outside an acceptable range; for example, that an upstream Query was 6360 received with an IP layer TTL of less than 254 (i.e. more than one IP 6361 hop from the sender). The actual IP distance can be derived from the 6362 IP-TTL information in the NLI object carried in the same message. 6364 A.4.4.12. MRI Validation Failure 6366 Class: Permanent-Failure 6367 Code: 12 6368 Additional Info: Object Value Info 6370 This error indicates that a message was received with an MRI that 6371 could not be accepted, e.g. because of too much wildcarding or 6372 failing some validation check (cf. Section 5.8.1.2). The Object 6373 Value Info includes the MRI so the error originator can indicate the 6374 part of the MRI which caused the problem. The error code is divided 6375 into subcodes as follows: 6377 0: MRI Too Wild: The MRI contained too much wildcarding (e.g. too 6378 short a destination address prefix) to be forwarded correctly down 6379 a single path. 6381 1: IP Version Mismatch: The MRI in a path-coupled Query message 6382 refers to an IP version which is not implemented on the interface 6383 used, or is different from the IP version of the Query 6384 encapsulation (see Section 7.4). 6386 2: Ingress Filter Failure: The MRI in a path-coupled Query message 6387 describes a flow which would not pass ingress filtering on the 6388 interface used. 6390 Appendix B. API between GIST and Signalling Applications 6392 This appendix provides an abstract API between GIST and signalling 6393 applications. It should not constrain implementers, but rather help 6394 clarify the interface between the different layers of the NSIS 6395 protocol suite. In addition, although some of the data types carry 6396 the information from GIST information elements, this does not imply 6397 that the format of that data as sent over the API has to be the same. 6399 Conceptually the API has similarities to the sockets API, 6400 particularly that for unconnected UDP sockets. An extension for an 6401 API like that for UDP connected sockets could be considered. In this 6402 case, for example, the only information needed in a SendMessage 6403 primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle 6404 (which can be null). Other information which was persistent for a 6405 group of messages could be configured once for the socket. Such 6406 extensions may make a concrete implementation more efficient but do 6407 not change the API semantics, and so are not considered further here. 6409 B.1. SendMessage 6411 This primitive is passed from a signalling application to GIST. It 6412 is used whenever the signalling application wants to initiate sending 6413 a message. 6415 SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, 6416 NSLPID, Session-ID, MRI, SII-Handle, 6417 Transfer-Attributes, Timeout, IP-TTL, GIST-Hop-Count ) 6419 The following arguments are mandatory. 6421 NSLP-Data: The NSLP message itself. 6423 NSLP-Data-Size: The length of NSLP-Data. 6425 NSLP-Message-Handle: A handle for this message, that can be used by 6426 GIST as a reference in subsequent MessageStatus notifications 6427 (Appendix B.3). Notifications could be about error conditions or 6428 about the security attributes that will be used for the message. 6429 A NULL handle may be supplied if the NSLP is not interested in 6430 such notifications. 6432 NSLPID: An identifier indicating which NSLP this is. 6434 Session-ID: The NSIS session identifier. Note that it is assumed 6435 that the signalling application provides this to GIST rather than 6436 GIST providing a value itself. 6438 MRI: Message routing information for use by GIST in determining the 6439 correct next GIST hop for this message. The MRI implies the 6440 message routing method to be used and the message direction. 6442 The following arguments are optional: 6444 SII-Handle: A handle, previously supplied by GIST, to a data 6445 structure that should be used to route the message explicitly to a 6446 particular GIST next hop. 6448 Transfer-Attributes: Attributes defining how the message should be 6449 handled (see Section 4.1.2). The following attributes can be 6450 considered: 6452 Reliability: Values 'unreliable' or 'reliable'. 6454 Security: This attribute allows the NSLP to specify what level of 6455 security protection is requested for the message (such as 6456 'integrity' or 'confidentiality'), and can also be used to 6457 specify what authenticated signalling source and destination 6458 identities should be used to send the message. The 6459 possibilities can be learned by the signalling application from 6460 prior MessageStatus or RecvMessage notifications. If an NSLP- 6461 Message-Handle is provided, GIST will inform the signalling 6462 application of what values it has actually chosen for this 6463 attribute via a MessageStatus callback. This might take place 6464 either synchronously (where GIST is selecting from available 6465 messaging associations), or asynchronously (when a new 6466 messaging association needs to be created). 6468 Local Processing: This attribute contains hints from the 6469 signalling application about what local policy should be 6470 applied to the message; in particular, its transmission 6471 priority relative to other messages, or whether GIST should 6472 attempt to set up or maintain forward routing state. 6474 Timeout: Length of time GIST should attempt to send this message 6475 before indicating an error. 6477 IP-TTL: The value of the IP layer TTL that should be used when 6478 sending this message (may be overridden by GIST for particular 6479 messages). 6481 GIST-Hop-Count: The value for the hop count when sending the 6482 message. 6484 B.2. RecvMessage 6486 This primitive is passed from GIST to a signalling application. It 6487 is used whenever GIST receives a message from the network, including 6488 the case of null messages (zero length NSLP payload), typically 6489 initial Query messages. For Queries, the results of invoking this 6490 primitive are used by GIST to check whether message routing state 6491 should be created (see the discussion of the 'Routing-State-Check' 6492 argument below). 6494 RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLPID, Session-ID, MRI, 6495 Routing-State-Check, SII-Handle, Transfer-Attributes, 6496 IP-TTL, IP-Distance, GIST-Hop-Count, 6497 Inbound-Interface ) 6499 NSLP-Data: The NSLP message itself (may be empty). 6501 NSLP-Data-Size: The length of NSLP-Data (may be zero). 6503 NSLPID: An identifier indicating which NSLP this message is for. 6505 Session-ID: The NSIS session identifier. 6507 MRI: Message routing information that was used by GIST in forwarding 6508 this message. Implicitly defines the message routing method that 6509 was used and the direction of the message relative to the MRI. 6511 Routing-State-Check: This boolean is True if GIST is checking with 6512 the signalling application to see if routing state should be 6513 created with the peer or the message should be forwarded further 6514 (see Section 4.3.2). If True, the signalling application should 6515 return the following values via the RecvMessage call: 6517 A boolean indicating whether to set up the state. 6519 Optionally, an NSLP-Payload to carry in the generated Response 6520 or forwarded Query respectively. 6522 This mechanism could be extended to enable the signalling 6523 application to indicate to GIST whether state installation should 6524 be immediate or deferred (see Section 5.3.3 and Section 6.3 for 6525 further discussion). 6527 SII-Handle: A handle to a data structure, identifying a peer address 6528 and interface. Can be used to identify route changes and for 6529 explicit routing to a particular GIST next hop. 6531 Transfer-Attributes: The reliability and security attributes that 6532 were associated with the reception of this particular message. As 6533 well as the attributes associated with SendMessage, GIST may 6534 indicate the level of verification of the addresses in the MRI. 6535 Three attributes can be indicated: 6537 * Whether the signalling source address is one of the flow 6538 endpoints (i.e. whether this is the first or last GIST hop); 6540 * Whether the signalling source address has been validated by a 6541 return routability check. 6543 * Whether the message was explicitly routed (and so has not been 6544 validated by GIST as delivered consistently with local routing 6545 state). 6547 IP-TTL: The value of the IP layer TTL this message was received with 6548 (if available). 6550 IP-Distance: The number of IP hops from the peer signalling node 6551 which sent this message along the path, or 0 if this information 6552 is not available. 6554 GIST-Hop-Count: The value of the hop count the message was received 6555 with, after being decremented in the GIST receive-side processing. 6557 Inbound-Interface: Attributes of the interface on which the message 6558 was received, such as whether it lies on the internal or external 6559 side of a NAT. These attributes have only local significance and 6560 are implementation defined. 6562 B.3. MessageStatus 6564 This primitive is passed from GIST to a signalling application. It 6565 is used to notify the signalling application that a message that it 6566 requested to be sent could not be dispatched, or to inform the 6567 signalling application about the transfer attributes that have been 6568 selected for the message (specifically, security attributes). The 6569 signalling application can respond to this message with a return code 6570 to abort the sending of the message if the attributes are not 6571 acceptable. 6573 MessageStatus (NSLP-Message-Handle, Transfer-Attributes, Error-Type) 6574 NSLP-Message-Handle: A handle for the message provided by the 6575 signalling application in SendMessage. 6577 Transfer-Attributes: The reliability and security attributes that 6578 will be used to transmit this particular message. 6580 Error-Type: Indicates the type of error that occurred. For example, 6581 'no next node found'. 6583 B.4. NetworkNotification 6585 This primitive is passed from GIST to a signalling application. It 6586 indicates that a network event of possible interest to the signalling 6587 application occurred. 6589 NetworkNotification ( NSLPID, MRI, Network-Notification-Type ) 6591 NSLPID: An identifier indicating which NSLP this is message is for. 6593 MRI: Provides the message routing information to which the network 6594 notification applies. 6596 Network-Notification-Type: Indicates the type of event that caused 6597 the notification and associated additional data. Five events have 6598 been identified: 6600 Last Node: GIST has detected that this is the last NSLP-aware 6601 node in the path. See Section 4.3.4. 6603 Routing Status Change: GIST has installed new routing state, has 6604 detected that existing routing state may no longer be valid, or 6605 has re-established existing routing state. See Section 7.1.3. 6606 The new status is reported; if the status is Good, the SII- 6607 Handle of the peer is also reported, as for RecvMessage. 6609 Route Deletion: GIST has determined that an old route is now 6610 definitely invalid, e.g. that flows are definitely not using it 6611 (see Section 7.1.4). The SII-Handle of the peer is also 6612 reported. 6614 Node Authorisation Change: The authorisation status of a peer has 6615 changed, meaning that routing state is no longer valid or that 6616 a signalling peer is no longer reachable; see Section 4.4.2. 6618 Communication Failure: Communication with the peer has failed; 6619 messages may have been lost. 6621 B.5. SetStateLifetime 6623 This primitive is passed from a signalling application to GIST. It 6624 indicates the duration for which the signalling application would 6625 like GIST to retain its routing state. It can also give a hint that 6626 the signalling application is no longer interested in the state. 6628 SetStateLifetime ( NSLPID, MRI, SID, State-Lifetime ) 6630 NSLPID: Provides the NSLPID to which the routing state lifetime 6631 applies. 6633 MRI: Provides the message routing information to which the routing 6634 state lifetime applies; includes the direction (in the D flag). 6636 SID: The session ID which the signalling application will be using 6637 with this routing state. Can be wildcarded. 6639 State-Lifetime: Indicates the lifetime for which the signalling 6640 application wishes GIST to retain its routing state (may be zero, 6641 indicating that the signalling application has no further interest 6642 in the GIST state). 6644 B.6. InvalidateRoutingState 6646 This primitive is passed from a signalling application to GIST. It 6647 indicates that the signalling application has knowledge that the next 6648 signalling hop known to GIST may no longer be valid, either because 6649 of changes in the network routing or the processing capabilities of 6650 signalling application nodes. See Section 7.1. 6652 InvalidateRoutingState ( NSLPID, MRI, Status, NSLP-Data, 6653 NSLP-Data-Size, Urgent ) 6655 NSLPID: The NSLP originating the message. May be null (in which 6656 case the invalidation applies to all signalling applications). 6658 MRI: The flow for which routing state should be invalidated; 6659 includes the direction of the change (in the D flag). 6661 Status: The new status that should be assumed for the routing state, 6662 one of Bad or Tentative (see Section 7.1.3). 6664 NSLP-Data, NSLP-Data-Size Optional: a payload provided by the NSLP 6665 to be used the next GIST handshake. This can be used as part of a 6666 conditional peering process (see Section 4.3.2). The payload will 6667 be transmitted without security protection. 6669 Urgent: A hint as to whether rediscovery should take place 6670 immediately, or only with the next signalling message. 6672 Appendix C. Deployment Issues with Router Alert Options 6674 The GIST peer discovery handshake (Section 4.4.1) depends on the 6675 interception of Q-mode encapsulated IP packets (Section 4.3.1 and 6676 Section 5.3.2) by routers. There are two fundamental requirements on 6677 the process: 6679 1. Packets relevant to GIST must be intercepted. 6681 2. Packets not relevant to GIST must be forwarded transparently. 6683 This specification defines the GIST behaviour to ensure that both 6684 requirements are met for a GIST-capable node. However, GIST packets 6685 will also encounter non-GIST nodes, for which requirement (2) still 6686 applies. If non-GIST nodes block Q-mode packets, GIST will not 6687 function. It is always possible for middleboxes to block specific 6688 traffic types; by using a normal UDP encapsulation for Q-mode 6689 traffic, GIST allows NATs at least to pass these messages 6690 (Section 7.2.1), and firewalls can be configured with standard 6691 policies. However, where the Q-mode encapsulation uses a Router 6692 Alert Option (RAO) at the IP level this can lead to additional 6693 problems. The situation is different for IPv4 and IPv6. 6695 The IPv4 RAO is defined by see [14], which defines the RAO format 6696 with a 2-byte value field; however, only one value (zero) is defined 6697 and there is no IANA registry for further allocations. It states 6698 that unknown values should be ignored (i.e. the packets forwarded as 6699 normal IP traffic); however, it has also been reported that some 6700 existing implementations simply ignore the RAO value completely (i.e. 6701 process any packet with an RAO as though the option value was zero). 6702 Therefore, the use of non-zero RAO values cannot be relied on to make 6703 GIST traffic transparent to existing implementations. (Note that it 6704 may still be valuable to be able to allocate non-zero RAO values for 6705 IPv4: this makes the interception process more efficient for nodes 6706 which do examine the value field, and makes no difference to nodes 6707 which - incorrectly - ignore it. Whether or not non-zero RAO values 6708 are used does not change the GIST protocol operation, but needs to be 6709 decided when new NSLPs are registered.) 6711 The second stage of the analysis is therefore what happens when a 6712 non-GIST node which implements RAO handling sees a Q-mode packet. 6713 The RAO specification simply states that "Routers that recognize this 6714 option shall examine packets carrying it more closely (check the IP 6715 Protocol field, for example) to determine whether or not further 6716 processing is necessary." There are two possible basic behaviours 6717 for GIST traffic: 6719 1. The "closer examination" of the packet is sufficiently 6720 intelligent to realise that the node does not need to process it 6721 and should forward it. This could either be by virtue of the 6722 fact that the node has not been configured to match IP- 6723 Protocol=UDP for RAO packets at all, or that even if UDP traffic 6724 is intercepted the port numbers do not match anything locally 6725 configured. 6727 2. The "closer examination" of the packet identifies it as UDP, and 6728 delivers it to the UDP stack on the node. In this case, it can 6729 no longer be guaranteed to be processed appropriately. Most 6730 likely it will simply be dropped or rejected with an ICMP error 6731 (because there is no GIST process on the destination port to 6732 deliver it to). 6734 Analysis of open-source operating system source code shows the first 6735 type of behaviour, and this has also been seen in direct GIST 6736 experiments with commercial routers, including the case when they 6737 process other uses of the RAO (i.e. RSVP). However, it has also 6738 been reported that other RAO implementations will exhibit the second 6739 type of behaviour. The consequence of this would be that Q-mode 6740 packets are blocked in the network and GIST could not be used. Note 6741 that although this caused by some subtle details in the RAO 6742 processing rules, the end result is the same as if the packet was 6743 simply blocked for other reasons (for example, many IPv4 firewalls 6744 drop packets with options by default). 6746 The GIST specification allows two main options for circumventing 6747 nodes which block Q-mode traffic in IPv4. Whether to use these 6748 options is a matter of implementation and configuration choice. 6750 o A GIST node can be configured to send Q-mode packets without the 6751 RAO at all. This should avoid the above problems, but should only 6752 be done if it is known that nodes on the path to the receiver are 6753 able to intercept such packets. (See Section 5.3.2.1) 6755 o If a GIST node can identify exactly where the packets are being 6756 blocked (e.g. from ICMP messages), or can discover some point on 6757 the path beyond the blockage (e.g. by use of traceroute or by 6758 routing table analysis), it can send the Q-mode messages to that 6759 point using IP-in-IP tunelling without any RAO. This bypasses the 6760 input side processing on the blocking node, but picks up normal 6761 GIST behaviour beyond it. 6763 If in the light of deployment experience the problem of blocked 6764 Q-mode traffic turns out to be widespread and these techniques turn 6765 out to be insufficient, a further possibility is to define an 6766 alternative Q-mode encapsulation which does not use UDP. This would 6767 require a specification change. Such an option would be restricted 6768 to network-internal use, since operation through NATs and firewalls 6769 would be much harder with it. 6771 The situation with IPv6 is rather different, since in that case the 6772 use of non-zero RAO values is well established in the specification 6773 ([18]) and an IANA registry exists. The main problem is that several 6774 implementations are still immature: for example, some treat any RAO- 6775 marked packet as though it was for local processing without further 6776 analysis. Since this prevents any RAO usage at all (including the 6777 existing standardised ones) in such a network, it seems reasonable to 6778 assume that such implementations will be fixed as part of the general 6779 deployment of IPv6. 6781 Appendix D. Example Routing State Table and Handshake 6783 Figure 11 shows a signalling scenario for a single flow being managed 6784 by two signalling applications using the path-coupled message routing 6785 method. The flow sender and receiver and one router support both, 6786 two other routers support one each. The figure also shows the 6787 routing state table at node B. 6789 A B C D E 6790 +------+ +-----+ +-----+ +-----+ +--------+ 6791 | Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow | 6792 |Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver| 6793 | | +-+ +-+ |GIST | |GIST | |GIST | | | 6794 +------+ +-----+ +-----+ +-----+ +--------+ 6795 Flow Direction ------------------------------>> 6797 +------------------------------------+---------+--------+-----------+ 6798 | Message Routing Information | Session | NSLPID | Routing | 6799 | | ID | | State | 6800 +------------------------------------+---------+--------+-----------+ 6801 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | IP-A | 6802 | {IP-A, IP-E, proto/ports}; D=up | | | | 6803 | | | | | 6804 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | (null) | 6805 | {IP-A, IP-E, proto/ports}; D=down | | | | 6806 | | | | | 6807 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | IP-A | 6808 | {IP-A, IP-E, proto/ports}; D=up | | | | 6809 | | | | | 6810 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | Points to | 6811 | {IP-A, IP-E, proto/ports}; D=down | | | B-D MA | 6812 +------------------------------------+---------+--------+-----------+ 6814 Figure 11: A Signalling Scenario 6816 The upstream state is just the same address for each application. 6817 For the downstream direction, NSLP1 only requires D-mode messages and 6818 so no explicit routing state towards C is needed. NSLP2 requires a 6819 messaging association for its messages towards node D, and node C 6820 does not process NSLP2 at all, so the peer state for NSLP2 is a 6821 pointer to a messaging association that runs directly from B to D. 6822 Note that E is not visible in the state table (except implicitly in 6823 the address in the message routing information); routing state is 6824 stored only for adjacent peers. (In addition to the peer 6825 identification, IP hop counts are stored for each peer where the 6826 state itself if not null; this is not shown in the table.) 6828 Figure 12 shows a GIST handshake setting up a messaging association 6829 for B-D signalling, with the exchange of Stack Proposals and MA- 6830 protocol-options in each direction. The Querying node selects TLS/ 6831 TCP as the stack configuration and sets up the messaging association 6832 over which it sends the Confirm. 6834 -------------------------- Query ----------------------------> 6835 IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST) 6836 D-mode magic number (0x4e04 bda5) 6837 GIST(Header(Type=Query; NSLPID=NSLP2; C=1; R=1; S=0) 6838 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 6839 SessionID(0x1234) NLI(Peer='string1'; IA=IP#B) 6840 QueryCookie(0x139471239471923526) 6841 StackProposal(#Proposals=3;1=TLS/TCP; 2=TLS/SCTP; 3=TCP) 6842 StackConfigurationData(HoldTime=300; #MPO=2; 6843 TCP(Applicable: all; Data: null) 6844 SCTP(Applicable: all; Data: null))) 6846 <---------------------- Response ---------------------------- 6847 IP(Src=IP#D; Dst=IP#B); UDP(Src=GIST; Dst=6789) 6848 D-mode magic number (0x4e04 bda5) 6849 GIST(Header(Type=Response; NSLPID=NSLP2; C=0; R=1; S=1) 6850 MRI(MRM=Path-Coupled; Flow=F; Direction=up) 6851 SessionID(0x1234) NLI(Peer='stringr2', IA=IP#D) 6852 QueryCookie(0x139471239471923526) 6853 ResponderCookie(0xacdefedcdfaeeeded) 6854 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP) 6855 StackConfigurationData(HoldTime=200; #MPO=3; 6856 TCP(Applicable: 3; Data: port=6123) 6857 TCP(Applicable: 1; Data: port=5438) 6858 SCTP(Applicable: all; Data: port=3333))) 6860 -------------------------TCP SYN-----------------------> 6861 <----------------------TCP SYN/ACK---------------------- 6862 -------------------------TCP ACK-----------------------> 6863 TCP connect(IP Src=IP#B; IP Dst=IP#D; Src Port=9166; Dst Port=6123) 6864 <-----------------------TLS INIT-----------------------> 6866 ------------------------ Confirm ----------------------------> 6867 [Sent within messaging association] 6868 GIST(Header(Type=Confirm; NSLPID=NSLP2; C=0; R=0; S=1) 6869 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 6870 SessionID(0x1234) NLI(Peer='string1'; IA=IP#B) 6871 ResponderCookie(0xacdefedcdfaeeeded) 6872 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP) 6873 StackConfigurationData(HoldTime=300)) 6875 Figure 12: GIST Handshake Message Sequence 6877 Appendix E. Change History 6879 Note to the RFC Editor: this appendix to be removed before 6880 publication as an RFC. 6882 E.1. Changes in Version -17 6884 The following changes were made in version 17. 6886 1. Added the C-flag to allow GIST-aware NATs to identify messages to 6887 be processed. The initial definition is in Section 5.2.1, and 6888 the detailed description in Section 7.2.2. There are consequent 6889 changes in the header format (Appendix A.1), error messages 6890 (Appendix A.4.4.1) and IANA considerations (Section 9). 6892 2. Changed the recommended version of TLS from 1.1 to 1.2. 6894 3. Various other clarifications and editorial corrections. 6896 Authors' Addresses 6898 Henning Schulzrinne 6899 Columbia University 6900 Department of Computer Science 6901 450 Computer Science Building 6902 New York, NY 10027 6903 US 6905 Phone: +1 212 939 7042 6906 Email: hgs+nsis@cs.columbia.edu 6907 URI: http://www.cs.columbia.edu 6909 Robert Hancock 6910 Roke Manor Research 6911 Old Salisbury Lane 6912 Romsey, Hampshire SO51 0ZN 6913 UK 6915 Email: stiemerling@nw.neclab.eu 6916 URI: http://www.roke.co.uk