idnits 2.17.1 draft-ietf-nsis-ntlp-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 7903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 7914. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 7921. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 7927. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 32. Fixed rfc2119 capitalisation of MUST not in Appendix A.3.5 [AD review comment N8]. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2, 2007) is 6228 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Data' on line 238 -- Looks like a reference, but probably isn't: 'Flow' on line 253 -- Looks like a reference, but probably isn't: 'Adjacent' on line 263 -- Looks like a reference, but probably isn't: 'Message' on line 294 -- Looks like a reference, but probably isn't: 'Initialisation' on line 3619 == Unused Reference: '15' is defined on line 5130, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4307 (ref. '5') (Obsoleted by RFC 8247) ** Obsolete normative reference: RFC 2434 (ref. '6') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2765 (ref. '9') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 3280 (ref. '10') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4234 (ref. '12') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4346 (ref. '13') (Obsoleted by RFC 5246) -- Possible downref: Normative reference to a draft: ref. '14' -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '16') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '19') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '20') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. '22') (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '26') (Obsoleted by RFC 5389) == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-03 -- Obsolete informational reference (is this intentional?): RFC 3682 (ref. '28') (Obsoleted by RFC 5082) -- 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-14 == Outdated reference: A later version (-02) exists of draft-pashalidis-nsis-gist-legacynats-01 == Outdated reference: A later version (-05) exists of draft-pashalidis-nsis-gimps-nattraversal-04 == Outdated reference: A later version (-10) exists of draft-ietf-nsis-ntlp-statemachine-03 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-07 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Next Steps in Signaling H. Schulzrinne 3 Internet-Draft Columbia U. 4 Intended status: Standards Track R. Hancock 5 Expires: October 4, 2007 Siemens/RMR 6 April 2, 2007 8 GIST: General Internet Signalling Transport 9 draft-ietf-nsis-ntlp-13 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 4, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document specifies protocol stacks for the routing and transport 43 of per-flow signalling messages along the path taken by that flow 44 through the network. The design uses existing transport and security 45 protocols under a common messaging layer, the General Internet 46 Signalling Transport (GIST), which provides a common service for 47 diverse signalling applications. GIST does not handle signalling 48 application state itself, but manages its own internal state and the 49 configuration of the underlying transport and security protocols to 50 enable the transfer of messages in both directions along the flow 51 path. The combination of GIST and the lower layer transport and 52 security protocols provides a solution for the base protocol 53 component of the "Next Steps in Signalling" framework. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Requirements Notation and Terminology . . . . . . . . . . . . 6 59 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9 60 3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 9 61 3.2. Modes and Messaging Associations . . . . . . . . . . . . 10 62 3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 12 63 3.4. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 14 64 3.5. GIST Peering Relationships . . . . . . . . . . . . . . . 15 65 3.6. Effect on Internet Transparency . . . . . . . . . . . . . 15 66 3.7. Signalling Sessions . . . . . . . . . . . . . . . . . . . 16 67 3.8. Signalling Applications and NSLPIDs . . . . . . . . . . . 17 68 3.9. GIST Security Services . . . . . . . . . . . . . . . . . 17 69 3.10. Example of Operation . . . . . . . . . . . . . . . . . . 18 70 4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 22 71 4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 22 72 4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 24 73 4.3. Basic GIST Message Processing . . . . . . . . . . . . . . 26 74 4.4. Routing State and Messaging Association Maintenance . . . 34 75 5. Message Formats and Transport . . . . . . . . . . . . . . . . 47 76 5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 47 77 5.2. Information Elements . . . . . . . . . . . . . . . . . . 49 78 5.3. D-mode Transport . . . . . . . . . . . . . . . . . . . . 53 79 5.4. C-mode Transport . . . . . . . . . . . . . . . . . . . . 59 80 5.5. Message Type/Encapsulation Relationships . . . . . . . . 59 81 5.6. Error Message Processing . . . . . . . . . . . . . . . . 60 82 5.7. Messaging Association Setup . . . . . . . . . . . . . . . 61 83 5.8. Specific Message Routing Methods . . . . . . . . . . . . 65 84 6. Formal Protocol Specification . . . . . . . . . . . . . . . . 71 85 6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 73 86 6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 74 87 6.3. Responder Node Processing . . . . . . . . . . . . . . . . 77 88 6.4. Messaging Association Processing . . . . . . . . . . . . 80 89 7. Additional Protocol Features . . . . . . . . . . . . . . . . 84 90 7.1. Route Changes and Local Repair . . . . . . . . . . . . . 84 91 7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 91 92 7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 96 93 7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 97 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 99 95 8.1. Message Confidentiality and Integrity . . . . . . . . . . 99 96 8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 100 97 8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 100 98 8.4. Denial of Service Prevention and Overload Protection . . 102 99 8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 104 100 8.6. Security Protocol Selection Policy . . . . . . . . . . . 105 101 8.7. Residual Threats . . . . . . . . . . . . . . . . . . . . 106 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108 103 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 113 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 105 11.1. Normative References . . . . . . . . . . . . . . . . . . 114 106 11.2. Informative References . . . . . . . . . . . . . . . . . 115 107 Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 118 108 A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 118 109 A.2. General Object Format . . . . . . . . . . . . . . . . . . 119 110 A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 120 111 A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 129 112 Appendix B. API between GIST and Signalling Applications . . . . 138 113 B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 138 114 B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 140 115 B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 141 116 B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 142 117 B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 143 118 B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 143 119 Appendix C. Deployment Issues with Router Alert Options . . . . 145 120 Appendix D. Example Routing State Table and Handshake . . . . . 148 121 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 150 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 176 123 Intellectual Property and Copyright Statements . . . . . . . . . 177 125 1. Introduction 127 Signalling involves the manipulation of state held in network 128 elements. 'Manipulation' could mean setting up, modifying and 129 tearing down state; or it could simply mean the monitoring of state 130 which is managed by other mechanisms. 132 This specification concentrates mainly on path-coupled signalling, 133 controlling resources on network elements which are located on the 134 path taken by a particular data flow, possibly including but not 135 limited to the flow endpoints. Indeed, there are almost always more 136 than two participants in a path-coupled signalling session, although 137 there is no need for every node on the path to participate. Path- 138 coupled signalling thus excludes end-to-end higher-layer application 139 signalling. In the context of path-coupled signalling, examples of 140 state management include network resource reservation, firewall 141 configuration, and state used in active networking; examples of state 142 monitoring are the discovery of instantaneous path properties, such 143 as available bandwidth or cumulative queuing delay. Each of these 144 different uses of signalling is referred to as a signalling 145 application. GIST path-coupled signalling does not directly support 146 multicast flows but could be extended to do so, especially in 147 environments where the multicast replication points can be made GIST- 148 capable. GIST can also be extended to cover other types of 149 signalling pattern, not related to any end-to-end flow in the 150 network, in which case the distinction between GIST and end-to-end 151 higher-layer signalling will be drawn differently or not at all. 153 Every signalling application requires a set of state management 154 rules, as well as protocol support to exchange messages along the 155 data path. Several aspects of this protocol support are common to 156 all or a large number of signalling applications, and hence can be 157 developed as a common protocol. The NSIS framework given in [30] 158 provides a rationale for a function split between the common and 159 application specific protocols, and gives outline requirements for 160 the former, the 'NSIS Transport Layer Protocol' (NTLP). The 161 application specific protocols are referred to as 'NSIS Signalling 162 Layer Protocols' (NSLPs), and are defined in separate documents. The 163 NSIS framework [30], and the accompanying threats document [31], 164 provide important background information to this specification, 165 including information on how GIST is expected to be used in various 166 network types and what role it is expected to perform. 168 This specification provides a concrete solution for the NTLP. It is 169 based on the use of existing transport and security protocols under a 170 common messaging layer, the General Internet Signalling Transport 171 (GIST). GIST does not handle signalling application state itself; in 172 that crucial respect, it differs from application signalling 173 protocols such as SIP, RTSP, and the control component of FTP. 174 Instead, GIST manages its own internal state and the configuration of 175 the underlying transport and security protocols to ensure the 176 transfer of signalling messages on behalf of signalling applications 177 in both directions along the flow path. 179 The structure of this specification is as follows. Section 2 defines 180 terminology, and Section 3 gives an informal overview of the protocol 181 design principles and operation. The normative specification is 182 contained mainly in Section 4 to Section 8. Section 4 describes the 183 message sequences and Section 5 their format and contents. Note that 184 the detailed bit formats are given in Appendix A. The protocol 185 operation is captured in the form of state machine language in 186 Section 6. Section 7 describes some more advanced protocol features 187 and security considerations are contained in Section 8. In addition, 188 Appendix B describes an abstract API for the service which GIST 189 provides to signalling applications, and Appendix D provides an 190 example message flow. Parts of the GIST design depend on the use of 191 packets with IP options to probe the network, which leads to 192 migration issues in networks with non-GIST nodes, especially in the 193 case of IPv4, and these are discussed in Appendix C. 195 Because of the layered structure of the NSIS protocol suite, protocol 196 extensions to cover a new signalling requirement could be carried out 197 either within GIST, or within the signalling application layer, or 198 both. General guidelines on how to extend different layers of the 199 protocol suite, and in particular when and how it is appropriate to 200 extend GIST, are contained in a separate document, [14]. In this 201 document, Section 9 gives the formal IANA considerations for the 202 registries already defined by the GIST specification. 204 2. Requirements Notation and Terminology 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in RFC 2119 [4]. In 209 addition, the security specifications in Section 5.7.3 use the 210 terminology MUST- and SHOULD+ from [5]. 212 The terminology used in this specification is defined in this 213 section. The basic entities relevant at the GIST level are shown in 214 Figure 1. In particular, this diagram distinguishes the different 215 address types as being associated with a flow (end-to-end addresses) 216 or signalling (addresses of adjacent signalling peers). 218 Source GIST (adjacent) peer nodes Destination 220 IP address IP addresses = Signalling IP address 221 = Flow Source/Destination Addresses = Flow 222 Source (depending on signalling direction) Destination 223 Address | | Address 224 V V 225 +--------+ +------+ Data Flow +------+ +--------+ 226 | Flow |-----------|------|-------------|------|-------->| Flow | 227 | Sender | | | | | |Receiver| 228 +--------+ | GIST |============>| GIST | +--------+ 229 | Node |<============| Node | 230 +------+ Signalling +------+ 231 GN1 Flow GN2 233 >>>>>>>>>>>>>>>>> = Downstream direction 234 <<<<<<<<<<<<<<<<< = Upstream direction 236 Figure 1: Basic Terminology 238 [Data] Flow: A set of packets identified by some fixed combination 239 of header fields. Flows are unidirectional; a bidirectional 240 communication is considered a pair of unidirectional flows. 242 Session: A single application layer flow of information for which 243 some state information is to be manipulated or monitored. See 244 Section 3.7 for further detailed discussion. 246 Session Identifier (SID): An identifier for a session; the syntax is 247 a 128 bit opaque value. 249 [Flow] Sender: The node in the network which is the source of the 250 packets in a flow. A sender could be a host, or a router if for 251 example the flow is actually an aggregate. 253 [Flow] Receiver: The node in the network which is the sink for the 254 packets in a flow. 256 Downstream: In the same direction as the data flow. 258 Upstream: In the opposite direction to the data flow. 260 GIST Node: Any node along the data path supporting GIST, regardless 261 of what signalling applications it supports. 263 [Adjacent] Peer: The next node along the signalling path, in the 264 upstream or downstream direction, with which a GIST node 265 explicitly interacts. 267 Querying Node: The GIST node that initiates the handshake process to 268 discover the adjacent peer. 270 Responding Node: The GIST node that responds to the handshake, 271 becoming the adjacent peer to the Querying node. 273 Datagram Mode (D-mode): A mode of sending GIST messages between 274 nodes without using any transport layer state or security 275 protection. Datagram mode uses UDP encapsulation, with source and 276 destination IP addresses derived either from the flow definition 277 or previously discovered adjacency information. 279 Connection Mode (C-mode): A mode of sending GIST messages directly 280 between nodes using point-to-point messaging associations (see 281 below). Connection mode allows the re-use of existing transport 282 and security protocols where such functionality is required. 284 Messaging Association (MA): A single connection between two 285 explicitly identified GIST adjacent peers, i.e. between a given 286 signalling source and destination address. A messaging 287 association may use a specific transport protocol and known ports. 288 If security protection is required, it may use a specific network 289 layer security association, or use a transport layer security 290 association internally. A messaging association is bidirectional: 291 signalling messages can be sent over it in either direction, 292 referring to flows of either direction. 294 [Message] Routing: Message routing describes the process of 295 determining which is the next GIST peer along the signalling path. 296 For signalling along a flow path, the message routing carried out 297 by GIST is built on top of normal IP routing. In this document, 298 the term 'routing' generally refers to GIST message routing unless 299 otherwise qualified. 301 Message Routing Method (MRM): There can be different algorithms for 302 discovering the route that signalling messages should take. These 303 are referred to as message routing methods, and GIST supports 304 alternatives within a common protocol framework. See Section 3.3. 306 Message Routing Information (MRI): The set of data item values which 307 is used to route a signalling message according to a particular 308 MRM; for example, for routing along a flow path, the MRI includes 309 flow source and destination addresses, protocol and port numbers. 310 See Section 3.3. 312 Router Alert Option (RAO): An option that can be included in IP v4 313 and v6 headers to assist in the packet interception process; see 314 [3] and [8]. 316 Transfer Attributes: A description of the requirements which a 317 signalling application has for the delivery of a particular 318 message; for example, whether the message should be delivered 319 reliably. See Section 4.1.2. 321 3. Design Overview 323 3.1. Overall Design Approach 325 The generic requirements identified in the NSIS framework [30] for 326 transport of signalling messages are essentially two-fold: 328 Routing: Determine how to reach the adjacent signalling node along 329 each direction of the data path (the GIST peer), and if necessary 330 explicitly establish addressing and identity information about 331 that peer; 333 Transport: Deliver the signalling information to that peer. 335 To meet the routing requirement, one possibility is for the node to 336 use local routing state information to determine the identity of the 337 GIST peer explicitly. GIST defines a three-way handshake which 338 probes the network to set up the necessary routing state between 339 adjacent peers, during which signalling applications can also 340 exchange data. Once the routing decision has been made, the node has 341 to select a mechanism for transport of the message to the peer. GIST 342 divides the transport problems into two categories, the easy and the 343 difficult. It handles the easy cases internally, and uses well- 344 understood transport protocols for the harder cases. Here, with 345 details discussed later, "easy" messages are those that are sized 346 well below the lowest maximum transmission unit (MTU) along a path, 347 are infrequent enough not to cause concerns about congestion and flow 348 control, and do not need security protection or guaranteed delivery. 350 In [30] all of these routing and transport requirements are assigned 351 to a single notional protocol, the NSIS Transport Layer Protocol 352 (NTLP). The strategy of splitting the transport problem leads to a 353 layered structure for the NTLP, of a specialised GIST messaging layer 354 running over standard transport and security protocols. The basic 355 concept is shown in Figure 2. Note that not every combination of 356 transport and security protocols implied by the figure is actually 357 possible for use in GIST; the actual combinations allowed by this 358 specification are defined in Section 5.7. The figure also shows GIST 359 offering its services to upper layers at an abstract interface, the 360 GIST API, further discussed in Section 4.1. 362 ^^ +-------------+ 363 || | Signalling | 364 NSIS +------------|Application 2| 365 Signalling | Signalling +-------------+ 366 Application |Application 1| | 367 Level +-------------+ | 368 || | | 369 VV | | 370 ========|===================|===== <-- GIST API 371 | | 372 ^^ +------------------------------------------------+ 373 || |+-----------------------+ +--------------+ | 374 || || GIST | | GIST State | | 375 || || Encapsulation |<<<>>>| Maintenance | | 376 || |+-----------------------+ +--------------+ | 377 || | GIST: Messaging Layer | 378 || +------------------------------------------------+ 379 NSIS | | | | 380 Transport .......................................... 381 Level . Transport Layer Security (TLS or DTLS) . 382 (NTLP) .......................................... 383 || | | | | 384 || +----+ +----+ +----+ +----+ 385 || |UDP | |TCP | |SCTP| |DCCP| ... other 386 || +----+ +----+ +----+ +----+ protocols 387 || | | | | 388 || ............................. 389 || . IP Layer Security . 390 || ............................. 391 VV | | | | 392 ===========================|=======|=======|=======|============ 393 | | | | 394 +----------------------------------------------+ 395 | IP | 396 +----------------------------------------------+ 398 Figure 2: Protocol Stack Architecture for Signalling Transport 400 3.2. Modes and Messaging Associations 402 Internally, GIST has two modes of operation: 404 Datagram mode (D-mode): used for small, infrequent messages with 405 modest delay constraints and no security requirements. A special 406 case of D-mode called Query-mode (Q-mode) is used when no routing 407 state exists. 409 Connection mode (C-mode): used for larger messages or where fast 410 state setup in the face of packet loss is desirable, or where 411 channel security is required. 413 D-mode uses UDP, as a suitable NAT-friendly encapsulation which does 414 not require per-message shared state to be maintained between the 415 peers. Long-term evolution of GIST is assumed to preserve the 416 simplicity of the current D-mode design. Extensions to the security 417 or transport capabilities of D-mode can be provided equivalently by 418 selecting a different protocol stack under the GIST messaging layer, 419 which would then become another option within the overall C-mode 420 framework. This includes both the case of using existing protocols, 421 and specific development of a message exchange and payload 422 encapsulation to support GIST requirements. Alternatively, if any 423 necessary parameters (e.g. a shared secret for use in integrity or 424 confidentiality protection) can be negotiated out-of-band, then the 425 additional functions can be added directly to D-mode by adding an 426 optional object to the message (see Appendix A.2.1). Note that 427 downgrade attacks on such approach would need to be prevented by 428 policy at the destination node, similar to the situation discussed in 429 Section 8.6. 431 C-mode can in principle use any stream or message-oriented transport 432 protocol; this specification defines TCP as the initial choice. It 433 can in principle employ specific network layer security associations, 434 or an internal transport layer security association; this 435 specification defines TLS as the initial choice. When GIST messages 436 are carried in C-mode, they are treated just like any other traffic 437 by intermediate routers between the GIST peers. Indeed, it would be 438 impossible for intermediate routers to carry out any processing on 439 the messages without terminating the transport and security protocols 440 used. 442 It is possible to mix these two modes along a path. This allows, for 443 example, the use of D-mode at the edges of the network and C-mode in 444 the core of the network. Such combinations may make operation more 445 efficient for mobile endpoints, while allowing multiplexing of 446 signalling messages across shared security associations and transport 447 connections between core routers. The setup for these protocols 448 imposes an initialisation cost for the use of C-mode, but in the long 449 term this cost can be shared over all signalling sessions between 450 peers; once the transport layer state exists, retransmission 451 algorithms can operate much more aggressively than would be possible 452 in a pure D-mode design. 454 It must be understood that the routing and transport decisions made 455 by GIST are not independent. If the message transfer has 456 requirements that require C-mode, for example if the message is so 457 large that fragmentation is required, this can only be used between 458 explicitly identified nodes. In such cases, GIST carries out the 459 three-way handshake initially in D-mode to identify the peer and then 460 sets up the necessary connections if they do not already exist. It 461 must also be understood that the signalling application does not make 462 the D-mode/C-mode selection directly; rather, this decision is made 463 by GIST on the basis of the message characteristics and the transfer 464 attributes stated by the application. The distinction is not visible 465 at the GIST service interface. 467 In general, the state associated with C-mode messaging to a 468 particular peer (signalling destination address, protocol and port 469 numbers, internal protocol configuration and state information) is 470 referred to as a messaging association (MA). MAs are totally 471 internal to GIST (they are not visible to signalling applications). 472 Although GIST may be using an MA to deliver messages about a 473 particular flow, there is no direct correspondence between them: the 474 GIST message routing algorithms consider each message in turn and 475 select an appropriate MA to transport it. There may be any number of 476 MAs between two GIST peers although the usual case is zero or one, 477 and they are set up and torn down by management actions within GIST 478 itself. 480 3.3. Message Routing Methods 482 The baseline message routing functionality in GIST is that signalling 483 messages follow a route defined by an existing flow in the network, 484 visiting a subset of the nodes through which it passes. This is the 485 appropriate behaviour for application scenarios where the purpose of 486 the signalling is to manipulate resources for that flow. However, 487 there are scenarios for which other behaviours are applicable. Two 488 examples are: 490 Predictive Routing: Here, the intent is to signal along a path that 491 the data flow may follow in the future. Possible cases are pre- 492 installation of state on the backup path that would be used in the 493 event of a link failure, and predictive installation of state on 494 the path that will be used after a mobile node handover. 496 NAT Address Reservations: This applies to the case where a node 497 behind a NAT wishes to reserve an address at which it can be 498 reached by a sender on the other side. This requires a message to 499 be sent outbound from what will be the flow receiver although no 500 reverse routing state for the flow yet exists. 502 Most of the details of GIST operation are independent of which is 503 being used. Therefore, the GIST design encapsulates the routing- 504 dependent details as a message routing method (MRM), and allows 505 multiple MRMs to be defined. This specification defines the path- 506 coupled MRM, corresponding to the baseline functionality described 507 above, and a second MRM for the NAT Address Reservation case. The 508 detailed specifications are given in Section 5.8. 510 The content of a MRM definition is as follows, using the path-coupled 511 MRM as an example: 513 o The format of the information that describes the path that the 514 signalling should take, the Message Routing Information (MRI). 515 For the path-coupled MRM, this is just the Flow Identifier (see 516 Section 5.8.1.1) and some additional control information. 517 Specifically, the MRI always includes a flag to distinguish 518 between the two directions that signalling messages can take, 519 denoted 'upstream' and 'downstream'. 521 o A specification of the IP-level encapsulation of the messages 522 which probe the network to discover the adjacent peers. A 523 downstream encapsulation must be defined; an upstream 524 encapsulation is optional. For the path-coupled MRM, this 525 information is given in Section 5.8.1.2 and Section 5.8.1.3. 526 Current MRMs rely on the interception of probe messages in the 527 data plane, but other mechanisms are also possible within the 528 overall GIST design and would be appropriate for other types of 529 signalling pattern. 531 o A specification of what validation checks GIST should apply to the 532 probe messages, for example to protect against IP address spoofing 533 attacks. The checks may be dependent on the direction (upstream 534 or downstream) of the message. For the path-coupled MRM, the 535 downstream validity check is basically a form of ingress 536 filtering, also discussed in Section 5.8.1.2. 538 o The mechanism(s) available for route change detection, i.e. any 539 change in the neighbour relationships that the MRM discovers. The 540 default case for any MRM is soft-state refresh, but additional 541 supporting techniques may be possible; see Section 7.1.2. 543 In addition, it should be noted that NAT traversal may require 544 translation of fields in the MRI object carried in GIST messages (see 545 Section 7.2.2). The generic MRI format includes a flag that must be 546 given as part of the MRM definition, to indicate if some kind of 547 translation is necessary. Development of a new MRM therefore 548 includes updates to the GIST specification, and may include updates 549 to specifications of NAT behaviour. These updates may be done in 550 separate documents as is the case for NAT traversal for the MRMs of 551 the base GIST specification, as described in Section 7.2.3 and [42]. 553 The MRI is passed explicitly between signalling applications and 554 GIST; therefore, signalling application specifications must define 555 which MRMs they require. Signalling applications may use fields in 556 the MRI in their packet classifiers; if they use additional 557 information for packet classification, this would be carried at the 558 NSLP level and so would be invisible to GIST. Any node hosting a 559 particular signalling application needs to use a GIST implementation 560 that supports the corresponding MRMs. The GIST processing rules 561 allow nodes not hosting the signalling application to ignore messages 562 for it at the GIST level, so it does not matter if these nodes 563 support the MRM or not. 565 3.4. GIST Messages 567 GIST has six message types: Query, Response, Confirm, Data, Error, 568 and MA-Hello. Apart from the invocation of the messaging association 569 protocols used by C-mode, all GIST communication consists of these 570 messages. In addition, all signalling application data is carried as 571 additional payloads in these messages, alongside the GIST 572 information. 574 The Query, Response and Confirm messages implement the handshake that 575 GIST uses to set up routing state and messaging associations. The 576 handshake is initiated from the Querying node towards the Responding 577 node. The first message is the Query, which is encapsulated in a 578 special way depending on the message routing method, in order to 579 probe the network infrastructure so that the correct peer will 580 intercept it and become the Responding node. A Query always triggers 581 a Response in the reverse direction as the second message of the 582 handshake. As part of the defence against denial of service attacks, 583 the Responding node can delay state installation until a return 584 routability check, and require the Querying node to complete the 585 handshake with the Confirm message. All of these three messages can 586 optionally carry signalling application data. The handshake is fully 587 described in Section 4.4.1. 589 The Data message is used purely to encapsulate and deliver signalling 590 application data. Usually it is sent using pre-established routing 591 state. However, if there are no security or transport requirements 592 and no need for persistent reverse routing state, it can also be sent 593 in the same way as the Query. Finally, Error messages are used to 594 indicate error conditions at the GIST level, and the MA-Hello message 595 can be used as a diagnostic and keepalive for the messaging 596 association protocols. 598 3.5. GIST Peering Relationships 600 Peering is the process whereby two GIST nodes create message routing 601 state which point to each other. 603 A peering relationship can only be created by a GIST handshake. 604 Nodes become peers when one issues a Query and gets a Response from 605 another. Issuing the initial Query is a result of an NSLP request on 606 that node, and the Query itself is formatted according to the rules 607 of the message routing method. For current MRMs, the identity of the 608 Responding node is not known explicitly at the time the Query is 609 sent; instead, the message is examined by nodes along the path until 610 one decides to send a Response, thereby becoming the peer. If the 611 node hosts the NSLP, local GIST and signalling application policy 612 determine whether to peer; the details are given in Section 4.3.2. 613 Nodes not hosting the NSLP forward the Query transparently 614 (Section 4.3.4). 616 An exisiting peering relationship can only be changed by a new GIST 617 handshake; in other words, it can only change when routing state is 618 refreshed. On a refresh, if any of the factors in the original 619 peering process have changed, the peering relationship can also 620 change. As well as network level rerouting, changes could include 621 modifications in NSIS signalling functions deployed at a node, or 622 alterations to signalling application policy. A change could cause 623 an existing node to drop out of the signalling path, or a new node to 624 become part of it. All these possibilities are handled as rerouting 625 events by GIST; further details of the process are described in 626 Section 7.1. 628 3.6. Effect on Internet Transparency 630 GIST relies on routers inside the network to intercept and process 631 packets which would normally be transmitted end-to-end. This 632 processing may be non-transparent: messages may be forwarded with 633 modifications, or not forwarded at all. This interception applies 634 only to the encapsulation used for messages which initially probe the 635 network, for example along a flow path; all other GIST messages are 636 handled only by the nodes to which they are directly addressed, i.e. 637 as normal Internet traffic. 639 Because this interception potentially breaks Internet transparency 640 for packets which are nothing to do with GIST, the encapsulation used 641 by GIST in this case (called Query-mode or Q-mode) has several 642 features to avoid accidental collisions with other traffic: 644 o Q-mode messages are always sent as UDP traffic, and to a specific 645 well-known port allocated by IANA. 647 o All GIST messages sent as UDP have a magic number as the first 32- 648 bit word of the datagram payload. 650 Even if a node intercepts a packet as potentially a GIST message, 651 unless it passes both these checks it will be ignored at the GIST 652 level and forwarded transparently. Further discussion of the 653 reception process is in Section 4.3.1 and the encapsulation in 654 Section 5.3. 656 3.7. Signalling Sessions 658 GIST requires signalling applications to associate each of their 659 messages with a signalling session. Informally, given an application 660 layer exchange of information for which some network control state 661 information is to be manipulated or monitored, the corresponding 662 signalling messages should be associated with the same session. 663 Signalling applications provide the session identifier (SID) whenever 664 they wish to send a message, and GIST reports the SID when a message 665 is received; on messages forwarded at the GIST level, the SID is 666 preserved unchanged. Usually, NSLPs will preserve the SID value 667 along the entire signalling path, but this is not enforced by or even 668 visible to GIST, which only sees the scope of the SID as the single 669 hop between adjacent NSLP peers. 671 Most GIST processing and state information is related to the flow 672 (defined by the MRI, see above) and signalling application (given by 673 the NSLP identifier, see below). There are several possible 674 relationships between flows and sessions, for example: 676 o The simplest case is that all signalling messages for the same 677 flow have the same SID. 679 o Messages for more than one flow may use the same SID, for example 680 because one flow is replacing another in a mobility or multihoming 681 scenario. 683 o A single flow may have messages for different SIDs, for example 684 from independently operating signalling applications. 686 Because of this range of options, GIST does not perform any 687 validation on how signalling applications map between flows and 688 sessions, nor does it perform any direct validation on the properties 689 of the SID itself, such as any enforcement of uniqueness. GIST only 690 defines the syntax of the SID as an opaque 128-bit identifier. 692 The SID assignment has the following impact on GIST processing: 694 o Messages with the same SID that are to be delivered reliably 695 between the same GIST peers are delivered in order. 697 o All other messages are handled independently. 699 o GIST identifies routing state (upstream and downstream peer) by 700 the triplet (MRI, NSLP, SID). 702 Strictly speaking, the routing state should not depend on the SID. 703 However, if the routing state is keyed only by (MRI, NSLP), there is 704 a trivial denial of service attack (see Section 8.3) where a 705 malicious off-path node asserts that it is the peer for a particular 706 flow. Such an attack would not redirect the traffic but would 707 reroute the signalling. Instead, the routing state is also 708 segregated between different SIDs, which means that the attacking 709 node can only disrupt a signalling session if it can guess the 710 corresponding SID. Normative rules on the selection of SIDs are 711 given in Section 4.1.3. 713 3.8. Signalling Applications and NSLPIDs 715 The functionality for signalling applications is supported by NSIS 716 signalling layer protocols (NSLPs). Each NSLP is identified by a 16 717 bit NSLP identifier (NSLPID), assigned by IANA (Section 9). A single 718 signalling application, such as resource reservation, may define a 719 family of NSLPs to implement its functionality, for example to carry 720 out signalling operations at different levels in a hierarchy (cf. 721 [23]). However, the interactions between the different NSLPs (for 722 example, to relate aggregation levels or aggregation region 723 boundaries in the resource management case) are handled at the 724 signalling application level; the NSLPID is the only information 725 visible to GIST about the signalling application being used. 727 3.9. GIST Security Services 729 GIST has two distinct security goals: 731 o to protect GIST state from corruption, and to protect the nodes on 732 which it runs from resource exhaustion attacks; and 734 o to provide secure transport for NSLP messages to the signalling 735 applications. 737 The protocol mechanisms to achieve the first goal are mainly internal 738 to GIST. They include a cookie exchange and return routability check 739 to protect the handshake which sets up routing state, and a random 740 SID is also used to prevent off-path session hijacking by SID 741 guessing. Further details are given in Section 4.1.3 and 742 Section 4.4.1, and the overall security aspects are discussed in 743 Section 8. 745 A second level of protection is provided by the use of a channel 746 security protocol in messaging associations (i.e. within C-mode). 747 This mechanism serves two purposes: to protect against on-path 748 attacks on GIST, and to provide a secure channel for NSLP messages. 749 For the mechanism to be effective, it must be able to provide the 750 following functions: 752 o mutual authentication of the GIST peer nodes; 754 o ability to verify the authenticated identity against a database of 755 nodes authorised to take part in GIST signalling; 757 o confidentiality and integrity protection for NSLP data, and 758 provision of the authenticated identities used to the signalling 759 application. 761 The authorised peer database is described in more detail in 762 Section 4.4.2, including the types of entries that it can contain and 763 the authorisation checking algorithm that is used. The only channel 764 security protocol defined by this specification is a basic use of 765 TLS, and Section 5.7.3 defines the TLS-specific aspects of how these 766 functions (for example, authentication and identity comparison) are 767 integrated with the rest of GIST operation. At a high level, there 768 are several alternative protocols with similar functionality, and the 769 handshake (Section 4.4.1) provides a mechanism within GIST to select 770 between them. However, they differ in their identity schemes and 771 authentication methods and dependencies on infrastructure support for 772 the authentication process, and any GIST extension to incorporate 773 them would need to define the details of the corresponding 774 interactions with GIST operation. 776 3.10. Example of Operation 778 This section presents an example of GIST usage in a relatively simple 779 (in particular, NAT-free) signalling scenario, to illustrate its main 780 features. 782 Consider the case of an RSVP-like signalling application which makes 783 receiver-based resource reservations for a single unicast flow. In 784 general, signalling can take place along the entire end-to-end path 785 (between flow source and destination), but the role of GIST is only 786 to transfer signalling messages over a single segment of the path, 787 between neighbouring resource-capable nodes. Basic GIST operation is 788 the same, whether it involves the endpoints or only interior nodes: 789 in either case, GIST is triggered by a request from a local 790 signalling application. The example here describes how GIST 791 transfers messages between two adjacent peers along the path, GN1 and 792 GN2 (see Figure 1 in Section 2). We take up the story at the point 793 where a message is being processed above the GIST layer by the 794 signalling application in GN1. 796 1. The signalling application in GN1 determines that this message is 797 a simple description of resources that would be appropriate for 798 the flow. It determines that it has no special security or 799 transport requirements for the message, but simply that it should 800 be transferred to the next downstream signalling application peer 801 on the path that the flow will take. 803 2. The message payload is passed to the GIST layer in GN1, along 804 with a definition of the flow and description of the message 805 transfer attributes (in this case, requesting no reliable 806 transmission or channel security protection). GIST determines 807 that this particular message does not require fragmentation and 808 that it has no knowledge of the next peer for this flow and 809 signalling application; however, it also determines that this 810 application is likely to require secured upstream and downstream 811 transport of large messages in the future. This determination is 812 a function of node-local policy interactions between GIST and the 813 signalling application. 815 3. GN1 therefore constructs a GIST Query carrying the NSLP payload, 816 and additional payloads at the GIST level which will be used to 817 initiate a messaging association. The Query is encapsulated in a 818 UDP datagram and injected into the network. At the IP level, the 819 destination address is the flow receiver, and an IP Router Alert 820 Option (RAO) is also included. 822 4. The Query passes through the network towards the flow receiver, 823 and is seen by each router in turn. GIST-unaware routers will 824 not recognise the RAO value and will forward the message 825 unchanged; GIST-aware routers which do not support the NSLP in 826 question will also forward the message basically unchanged, 827 although they may need to process more of the message to decide 828 this. 830 5. The message is intercepted at GN2. The GIST layer identifies the 831 message as relevant to a local signalling application, and passes 832 the NSLP payload and flow description upwards to it. This 833 signalling application in GN2 indicates to GIST that it will peer 834 with GN1 and so GIST should proceed to set up any routing state. 835 In addition, the signalling application continues to process the 836 message as in GN1 (compare step 1), passing the message back down 837 to GIST so that it is sent further downstream, and this will 838 eventually result in the message reaching the flow receiver. 839 GIST itself operates hop-by-hop, and the signalling application 840 joins these hops together to manage the end-to-end signalling 841 operations. 843 6. In parallel, the GIST instance in GN2 now knows that it should 844 maintain routing state and a messaging association for future 845 signalling with GN1. This is recognised because the message is a 846 Query, and because the local signalling application has indicated 847 that it will peer with GN1. There are two possible cases for 848 sending back the necessary GIST Response: 850 6.A - Association Exists: GN1 and GN2 already have an 851 appropriate MA. GN2 simply records the identity of GN1 as its 852 upstream peer for that flow and NSLP, and sends a Response 853 back to GN1 over the MA identifying itself as the peer for 854 this flow. 856 6.B - No Association: GN2 sends the Response in D-mode directly 857 to GN1, identifying itself and agreeing to the messaging 858 association setup. The protocol exchanges needed to complete 859 this will proceed in parallel with the following stages. 861 In each case, the result is that GN1 and GN2 are now in a peering 862 relationship for the flow. 864 7. Eventually, another NSLP message works its way upstream from the 865 receiver to GN2. This message contains a description of the 866 actual resources requested, along with authorisation and other 867 security information. The signalling application in GN2 passes 868 this payload to the GIST level, along with the flow definition 869 and transfer attributes; in this case, it could request reliable 870 transmission and use of a secure channel for integrity 871 protection. (Other combinations of attributes are possible). 873 8. The GIST layer in GN2 identifies the upstream peer for this flow 874 and NSLP as GN1, and determines that it has an MA with the 875 appropriate properties. The message is queued on the MA for 876 transmission; this may incur some delay if the procedures begun 877 in step 6.B have not yet completed. 879 Further messages can be passed in each direction in the same way. 880 The GIST layer in each node can in parallel carry out maintenance 881 operations such as route change detection (see Section 7.1). 883 It should be understood that several of these details of GIST 884 operations can be varied, either by local policy or according to 885 signalling application requirements. The authoritative details are 886 contained in the remainder of this document. 888 4. GIST Processing Overview 890 This section defines the basic structure and operation of GIST. 891 Section 4.1 describes the way in which GIST interacts with local 892 signalling applications in the form of an abstract service interface. 893 Section 4.2 describes the per-flow and per-peer state that GIST 894 maintains for the purpose of transferring messages. Section 4.3 895 describes how messages are processed in the case where any necessary 896 messaging associations and routing state already exist; this includes 897 the simple scenario of pure D-mode operation, where no messaging 898 associations are necessary. Finally, Section 4.4 describes how 899 routing state and messaging associations are created and managed. 901 4.1. GIST Service Interface 903 This section describes the interaction between GIST and signalling 904 applications in terms of an abstract service interface, including a 905 definition of the attributes of the message transfer that GIST can 906 offer. The service interface presented here is non-normative and 907 does not constrain actual implementations of any interface between 908 GIST and signalling applications; the interface is provided to aid 909 understanding of how GIST can be used. However, requirements on SID 910 selection and internal GIST behaviour to support message transfer 911 semantics (such as in-order delivery) are stated normatively here. 913 The same service interface is presented at every GIST node; however, 914 applications may invoke it differently at different nodes, depending 915 for example on local policy. In addition, the service interface is 916 defined independently of any specific transport protocol, or even the 917 distinction between D-mode and C-mode. The initial version of this 918 specification defines how to support the service interface using a 919 C-mode based on TCP; if additional protocol support is added, this 920 will support the same interface and so the change will be invisible 921 to applications, except as a possible performance improvement. A 922 more detailed description of this service interface is given in 923 Appendix B. 925 4.1.1. Message Handling 927 Fundamentally, GIST provides a simple message-by-message transfer 928 service for use by signalling applications: individual messages are 929 sent, and individual messages are received. At the service 930 interface, the NSLP payload, which is opaque to GIST, is accompanied 931 by control information expressing the application's requirements 932 about how the message should be routed, and the application also 933 provides the session identifier (SID), see Section 4.1.3. Additional 934 message transfer attributes control the specific transport and 935 security properties that the signalling application desires. 937 The distinction between GIST D- and C-mode is not visible at the 938 service interface. In addition, the functionality to handle 939 fragmentation and reassembly, bundling together of small messages for 940 efficiency, and congestion control are not visible at the service 941 interface; GIST will take whatever action is necessary based on the 942 properties of the messages and local node state. 944 A signalling application is free to choose the rate at which it 945 processes inbound messages; an implementation MAY allow the 946 application to block accepting messages from GIST. In these 947 circumstances, GIST MAY discard unreliably delivered messages, but 948 for reliable messages MUST propagate flow-control condition back to 949 the sender. Therefore, applications must be aware that they may in 950 turn be blocked from sending outbound messages themselves. 952 4.1.2. Message Transfer Attributes 954 Message transfer attributes are used to define certain performance 955 and security-related aspects of message processing. The attributes 956 available are as follows: 958 Reliability: This attribute may be 'true' or 'false'. When 'true', 959 messages MUST be delivered to the signalling application in the 960 peer exactly once or not at all; for messages with the same SID, 961 the delivery MUST be in order. If there is a chance that the 962 message was not delivered, an error MUST be indicated to the local 963 signalling application identifying the routing information for the 964 message in question. GIST implements reliability by using an 965 appropriate transport protocol within a messaging association, so 966 mechanisms for the detection of message loss depend on the 967 protocol in question; for the current specification, the case of 968 TCP is considered in Section 5.7.2. When 'false', a message may 969 be delivered, once, several times or not at all, with no error 970 indications in any case. 972 Security: This attribute defines the set of security properties that 973 the signalling application requires for the message, including the 974 type of protection required, and what authenticated identities 975 should be used for the signalling source and destination. This 976 information maps onto the corresponding properties of the security 977 associations established between the peers in C-mode. Keying 978 material for the security associations is established by the 979 authentication mechanisms within the messaging association 980 protocols themselves; see Section 8.2. The attribute can be 981 specified explicitly by the signalling application, or reported by 982 GIST to the signalling application. The latter can take place 983 either on receiving a message, or just before sending a message 984 but after configuring or selecting the messaging association to be 985 used for it. 987 This attribute can also be used to convey information about any 988 address validation carried out by GIST, such as whether a return 989 routability check has been carried out. Further details are 990 discussed in Appendix B. 992 Local Processing: An NSLP may provide hints to GIST to enable more 993 efficient or appropriate processing. For example, the NSLP may 994 select a priority from a range of locally defined values to 995 influence the sequence in which messages leave a node. Any 996 priority mechanism MUST respect the ordering requirements for 997 reliable messages within a session, and priority values are not 998 carried in the protocol or available at the signalling peer or 999 intermediate nodes. An NSLP may also indicate that upstream path 1000 routing state will not be needed for this flow, to inhibit the 1001 node requesting its downstream peer to create it; conversely, even 1002 if routing state exists, the NSLP may request that it is not used, 1003 which will lead to data being sent Q-mode encapsulated instead. 1005 4.1.3. SID Selection 1007 The fact that SIDs index routing state (see Section 4.2.1 below) 1008 means that there are requirements for how they are selected. 1009 Specifically, signalling applications MUST choose SIDs so that they 1010 are cryptographically random, and SHOULD NOT use several SIDs for the 1011 same flow, to avoid additional load from routing state maintenance. 1012 Guidance on secure randomness generation can be found in [32]. 1014 4.2. GIST State 1016 4.2.1. Message Routing State 1018 For each flow, the GIST layer can maintain message routing state to 1019 manage the processing of outgoing messages. This state is 1020 conceptually organised into a table with the following structure. 1021 Each row in the table corresponds to a unique combination of the 1022 following three items: 1024 Message Routing Information (MRI): This defines the method to be 1025 used to route the message, the direction in which to send the 1026 message, and any associated addressing information; see 1027 Section 3.3. 1029 Session Identification (SID): The signalling session with which this 1030 message should be associated; see Section 3.7. 1032 NSLP Identification (NSLPID): This is an IANA-assigned identifier 1033 associated with the NSLP which is generating messages for this 1034 flow; see Section 3.8. The inclusion of this identifier allows 1035 the routing state to be different for different NSLPs. 1037 The information associated with a given {MRI,SID,NSLPID} triplet 1038 consists of the routing state to reach the peer in the direction 1039 given by the MRI. For any flow there will usually be two entries in 1040 the table, one each for the upstream and downstream MRI. The routing 1041 state includes information about the peer identity (see 1042 Section 4.4.3), and a UDP port number for D-mode, or a reference to 1043 one or more MAs for C-mode. Entries in the routing state table are 1044 created by the GIST handshake, which is described in more detail in 1045 Section 4.4. 1047 It is also possible for the state information for either direction to 1048 be empty. There are several possible cases: 1050 o The signalling application has indicated that no messages will 1051 actually be sent in that direction. 1053 o The node is the endpoint of the signalling path, for example 1054 because it is acting as a proxy, or because it has determined that 1055 there are no further signalling nodes in that direction. 1057 o The node is using other techniques to send the message. For 1058 example, it can send it in Q-mode and rely on the peer to 1059 intercept it. 1061 In addition, if the node is a flow endpoint, GIST will refuse to 1062 create routing state for the direction beyond the end of the flow 1063 (see Section 4.3.3). Each entry in the routing state table has an 1064 associated validity timer indicating for how long it can be 1065 considered accurate. When this timer expires, the entry MUST be 1066 purged if it has not been refreshed. Installation and maintenance of 1067 routing state is described in more detail in Section 4.4. 1069 4.2.2. Peer-Peer Messaging Association State 1071 The per-flow message routing state is not the only state stored by 1072 GIST. There is also the state required to manage the MAs. Since 1073 these are not per-flow, they are stored separately from the routing 1074 state, including the following per-MA information: 1076 o a queue of messages pending transmission while an MA is being 1077 established; 1079 o the time since the peer re-stated its desire to keep the MA open 1080 (see Section 4.4.5). 1082 In addition, per-MA state is held in the messaging association 1083 protocols themselves. However, the details of this state are not 1084 directly visible to GIST, and they do not affect the rest of the 1085 protocol description. 1087 4.3. Basic GIST Message Processing 1089 This section describes how signalling application messages are 1090 processed in the case where any necessary messaging associations and 1091 routing state are already in place. The description is divided into 1092 several parts. Firstly, message reception, local processing and 1093 message transmission are described for the case where the node hosts 1094 the NSLPID identified in the message. Secondly, the case where the 1095 message is handled directly in the IP or GIST layer (because there is 1096 no matching signalling application on the node) is given. An 1097 overview is given in Figure 3. This section concentrates on the GIST 1098 level processing, with full details of IP and transport layer 1099 encapsulation in Section 5.3 and Section 5.4. 1101 +---------------------------------------------------------+ 1102 | >> Signalling Application Processing >> | 1103 | | 1104 +--------^---------------------------------------V--------+ 1105 ^ V 1106 ^ NSLP Payloads V 1107 ^ V 1108 +--------^---------------------------------------V--------+ 1109 | >> GIST >> | 1110 | ^ ^ ^ Processing V V V | 1111 +--x-----------N--Q---------------------Q--N-----------x--+ 1112 x N Q Q N x 1113 x N Q>>>>>>>>>>>>>>>>>>>>>Q N x 1114 x N Q Bypass at Q N x 1115 +--x-----+ +--N--Q--+ GIST level +--Q--N--+ +-----x--+ 1116 | C-mode | | D-mode | | D-mode | | C-mode | 1117 |Handling| |Handling| |Handling| |Handling| 1118 +--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+ 1119 x N Q Q N x 1120 x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x 1121 x N Q Bypass at Q N x 1122 +--x--N--+ +-----Q--+ IP (router +--Q-----+ +--N--x--+ 1123 |IP Host | | RAO | alert) level | RAO | |IP Host | 1124 |Handling| |Handling| |Handling| |Handling| 1125 +--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+ 1126 x N Q Q N x 1127 +--x--N-----------Q--+ +--Q-----------N--x--+ 1128 | IP Layer | | IP Layer | 1129 | (Receive Side) | | (Transmit Side) | 1130 +--x--N-----------Q--+ +--Q-----------N--x--+ 1131 x N Q Q N x 1132 x N Q Q N x 1134 NNNNNNNNNNNNNN = Normal D-mode messages 1135 QQQQQQQQQQQQQQ = D-mode messages which are Q-mode encapsulated 1136 xxxxxxxxxxxxxx = C-mode messages 1137 RAO = Router Alert Option 1139 Figure 3: Message Paths through a GIST Node 1141 4.3.1. Message Reception 1143 Messages can be received in C-mode or D-mode. 1145 Reception in C-mode is simple: incoming packets undergo the security 1146 and transport treatment associated with the MA, and the MA provides 1147 complete messages to the GIST layer for further processing. 1149 Reception in D-mode depends on the message type. 1151 Normal encapsulation: Normal messages arrive UDP-encapsulated and 1152 addressed directly to the receiving signalling node, at an address 1153 and port learned previously. Each datagram contains a single 1154 message which is passed to the GIST layer for further processing, 1155 just as in the C-mode case. 1157 Q-mode encapsulation: Where GIST is sending messages to be 1158 intercepted by the appropriate peer rather than directly addressed 1159 to it (in particular, Query messages), these are UDP encapsulated, 1160 and MAY include an IP router alert option (RAO) if required by the 1161 MRM. Each signalling node can therefore see every such message, 1162 but unless the message exactly matches the Q-mode encapsulation 1163 rules (Section 5.3.2) it MUST be forwarded transparently at the IP 1164 level. If it does match, the GIST MUST check the NSLPID in the 1165 common header. The case where the NSLPID does not match a local 1166 signalling application at all is considered below in 1167 Section 4.3.4; otherwise, the message MUST be passed up to the 1168 GIST layer for further processing. 1170 Several different RAO values may be used by the NSIS protocol suite. 1171 GIST itself does not allocate any RAO values (for either IPv4 or 1172 IPv6); an assignment is made for each NSLP using MRMs that use the 1173 RAO in the Q-mode encapsulation. The assignment rationale is 1174 discussed in [14]. The RAO value assigned for an NSLPID may be 1175 different for IPv4 and IPv6. Note the different significance between 1176 the RAO and the NSLPID values: the meaning of a message (which 1177 signalling application it refers to, whether it should be processed 1178 at a node) is determined only from the NSLPID; the role of the RAO 1179 value is simply to allow nodes to pre-filter which IP datagrams are 1180 analysed to see if they might be Q-mode GIST messages. 1182 For all assignments associated with NSIS, the RAO specific processing 1183 is the same and is as defined by this specification, here and in 1184 Section 4.3.4 and Section 5.3.2. 1186 Immediately after reception, the GIST hop count is checked. Any 1187 message with a GIST hop count of zero MUST be rejected with a "Hop 1188 Limit Exceeded" error message (Appendix A.4.4.2). Otherwise, the 1189 GIST hop count MUST be decremented by one. 1191 4.3.2. Local Processing and Validation 1193 Once a message has been received, it is processed locally within the 1194 GIST layer. Further processing depends on the message type and 1195 payloads carried; most of the GIST payloads are associated with 1196 internal state maintenance, and details are covered in Section 4.4. 1198 This section concentrates on the interaction with the signalling 1199 application, in particular the decision to peer and how data is 1200 delivered to the NSLP. 1202 In the case of a Query, there is an interaction with the signalling 1203 application to determine which of two courses to follow. The first 1204 option (peering) MUST be chosen if the node is the final destination 1205 of the Query message, or if the GIST hop count has reached zero. 1207 1. The receiving signalling application wishes to become a 1208 signalling peer with the Querying node. GIST MUST continue with 1209 the handshake process to set up message routing state, as 1210 described in Section 4.4.1. The application MAY provide an NSLP 1211 payload for the same NSLPID, which GIST will transfer in the 1212 Response. 1214 2. The signalling application does not wish to set up state with the 1215 Querying node and become its peer. This includes the case where 1216 a node wishes to avoid taking part in the signalling for overload 1217 protection reasons. GIST MUST propagate the Query, similar to 1218 the case described in Section 4.3.4. No message is sent back to 1219 the Querying node. The application MAY provide an updated NSLP 1220 payload for the same NSLPID, which will be used in the Query 1221 forwarded by GIST. Note that if the node which finally processes 1222 the Query returns an Error message, this will be sent directly 1223 back to the originating node, bypassing any forwarders. For 1224 these diagnostics to be meaningful, any GIST node forwarding a 1225 Query MUST NOT modify it except in the NSLP payload; in 1226 particular, it MUST NOT modify any GIST payloads or their order. 1227 An implementation MAY choose to achieve this by retaining the 1228 original message, rather than reconstructing it from some parsed 1229 internal representation. 1231 This interaction with the signalling application, including the 1232 generation or update of an NSLP payload, SHOULD take place 1233 synchronously as part of the Query processing. In terms of the GIST 1234 service interface, this can be implemented by providing appropriate 1235 return values for the primitive that is triggered when such a message 1236 is received; see Appendix B.2 for further discussion. 1238 For all GIST message types other than Queries, if the message 1239 includes an NSLP payload, this MUST be delivered locally to the 1240 signalling application identified by the NSLPID. The format of the 1241 payload is not constrained by GIST, and the content is not 1242 interpreted. Delivery is subject to the following validation checks 1243 which MUST be applied in the sequence given: 1245 1. if the message was explicitly routed (see Section 7.1.5) or is a 1246 Data message delivered without routing state (see Section 5.3.2), 1247 the payload is delivered but flagged to the receiving NSLP to 1248 indicate that routing state was not validated; 1250 2. else, if the message arrived on an association which is not 1251 associated with the MRI/NSLPID/SID combination given in the 1252 message, the message MUST be rejected with an "Incorrectly 1253 Delivered Message" error message (Appendix A.4.4.4); 1255 3. else, if there is no routing state for this MRI/SID/NSLPID the 1256 message MUST either be dropped or be rejected with a error 1257 message (see Section 4.4.6 for further details); 1259 4. else, the payload is delivered as normal. 1261 4.3.3. Message Transmission 1263 Signalling applications can generate their messages for transmission, 1264 either asynchronously, or in reply to an input message, and GIST can 1265 also generate messages autonomously. GIST MUST verify that it is not 1266 the direct destination of an outgoing message, and MUST reject such 1267 messages with an error indication to the signalling application. 1269 Signalling applications may specify a value to be used for the GIST 1270 hop count; otherwise, GIST selects a value itself. GIST MUST reject 1271 messages for which the signalling application has specified a value 1272 of zero. Although the GIST hop count is only intended to control 1273 message looping at the GIST level, the GIST API (Appendix B) provides 1274 the incoming hop count to the NSLPs, which can preserve it on 1275 outgoing messages as they are forwarded further along the path. This 1276 provides a lightweight loop-control mechanism for NSLPs which do not 1277 define anything more sophisticated. Note that the count will be 1278 decremented on forwarding through every GIST-aware node. Initial 1279 values for the GIST hop count are an implementation matter; one 1280 suitable approach is to use the same algorithm as for IP TTL setting 1281 [1]. 1283 When a message is available for transmission, GIST uses internal 1284 policy and the stored routing state to determine how to handle it. 1285 The following processing applies equally to locally generated 1286 messages and messages forwarded from within the GIST or signalling 1287 application levels. However, see Section 5.6 for special rules 1288 applying to the transmission of error messages by GIST. 1290 The main decision is whether the message must be sent in C-mode or 1291 D-mode. Reasons for using C-mode are: 1293 o message transfer attributes: for example, the signalling 1294 application has requested channel-secured delivery, or reliable 1295 delivery. 1297 o message size: a message whose size (including the GIST header, 1298 GIST objects and any NSLP payload, and an allowance for the IP and 1299 transport layer encapsulation required by D-mode) exceeds a 1300 fragmentation-related threshold MUST be sent over C-mode, using a 1301 messaging association that supports fragmentation and reassembly 1302 internally. The allowance for IP and transport layer 1303 encapsulation is 64 bytes. The message size MUST NOT exceed the 1304 least of the following three quantities: the Path MTU to the next 1305 peer (if known), the first-hop MTU, and 576 bytes. The same limit 1306 applies to IPv4 and IPv6. 1308 o congestion control: D-mode SHOULD NOT be used for signalling where 1309 it is possible to set up routing state and use C-mode, unless the 1310 network can be engineered to guarantee capacity for D-mode traffic 1311 within the rate control limits imposed by GIST (see 1312 Section 5.3.3). 1314 In principle, as well as determining that some messaging association 1315 must be used, GIST MAY select between a set of alternatives, e.g. for 1316 load sharing or because different messaging associations provide 1317 different transport or security attributes. For the case of reliable 1318 delivery, GIST MUST NOT distribute messages for the same session over 1319 multiple messaging associations in parallel, but MUST use a single 1320 association at any given time. The case of moving over to a new 1321 association is covered in Section 4.4.5. 1323 If the use of a messaging association (i.e. C-mode) is selected, the 1324 message is queued on the association found from the routing state 1325 table, and further output processing is carried out according to the 1326 details of the protocol stacks used. If no appropriate association 1327 exists, the message is queued while one is created (see 1328 Section 4.4.1), which will trigger the exchange of additional GIST 1329 messages. If no association can be created, this is an error 1330 condition, and should be indicated back to the local signalling 1331 application. 1333 If a messaging association is not required, the message is sent in 1334 D-mode. The processing in this case depends on the message type and 1335 whether routing state exists or not. 1337 o If the message is not a Query, and routing state exists, it is 1338 sent with the normal D-mode encapsulation directly to the address 1339 from the routing state table. 1341 o If the message is a Query, then it is sent in Q-mode as defined in 1342 (Section 5.3.2); the details depend on the message routing method. 1344 o If no routing state exists, GIST can attempt to use Q-mode as in 1345 the Query case: either sending a Data message with the Q-mode 1346 encapsulation, or using the event as a trigger for routing state 1347 setup (see Section 4.4). If this is not possible, e.g. because 1348 the encapsulation for the MRM is only defined for one message 1349 direction, then this is an error condition which is reported back 1350 to the local signalling application. 1352 4.3.4. Nodes not Hosting the NSLP 1354 A node may receive messages where it has no signalling application 1355 corresponding to the message NSLPID. There are several possible 1356 cases depending mainly on the encapsulation: 1358 1. A message contains an RAO value which is relevant to NSIS, but it 1359 does not exactly match the Q-mode encapsulation rules of 1360 Section 5.3.2. The message MUST be transparently forwarded at 1361 the IP layer. 1363 2. A Q-mode encapsulated message contains an RAO value which is 1364 relevant to NSIS but not to the specific node, but the IP layer 1365 is unable to recognise whether it needs to be passed to GIST for 1366 further processing or whether the packet should be forwarded just 1367 like a normal IP datagram. 1369 3. A Q-mode encapsulated message contains an RAO value which is 1370 relevant to the node, but the specific signalling application for 1371 the NSLPID in the message is not processed there. 1373 4. A directly addressed message (in D-mode or C-mode) is delivered 1374 to a node for which there is no corresponding signalling 1375 application. With the current specification, this should not 1376 happen in normal operation. While future versions might find a 1377 use for such a feature, currently this MUST cause an "Unknown 1378 NSLPID" error message, Appendix A.4.4.6. 1380 5. A Q-mode encapsulated message arrives at the end-system which 1381 does not handle the signalling application. This is possible in 1382 normal operation, and MUST be indicated to the sender with an 1383 "Endpoint Found" informational message (Appendix A.4.4.7). The 1384 end-system includes the MRI and SID from the original message in 1385 the error message without interpreting them. 1387 6. The node is GIST-aware NAT. See Section 7.2. 1389 In cases (2) and (3), the role of GIST is to forward the message 1390 essentially as though it were a normal IP datagram, and it will not 1391 become a peer to the node sending the message. Forwarding with 1392 modified NSLP payloads is covered above in Section 4.3.2. However, a 1393 GIST implementation MUST ensure that the IP-layer TTL field and GIST 1394 hop count are managed correctly to prevent message looping, and this 1395 should be done consistently independently of whether the processing 1396 takes place on the fast path or in GIST-specific code. The rules are 1397 that in cases (2) and (3), the IP-layer TTL MUST be decremented just 1398 as if the message was a normal IP forwarded packet; in case (3) the 1399 GIST hop count MUST be decremented as in the case of normal input 1400 processing, which also applies to cases (4) and (5). 1402 A GIST node processing Q-mode encapsulated messages in this way 1403 SHOULD make the routing decision based on the full contents of the 1404 MRI and not only the IP destination address. It MAY also apply a 1405 restricted set of sanity checks and under certain conditions return 1406 an error message rather than forward the message. These conditions 1407 are: 1409 1. The message is so large that it would be fragmented on downstream 1410 links, for example because the downstream MTU is abnormally small 1411 (less than 512 bytes). The error "Message Too Large" 1412 (Appendix A.4.4.8) SHOULD be returned to the sender, which SHOULD 1413 begin messaging association setup. 1415 2. The GIST hop count has reached zero. The error "Hop Limit 1416 Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender, 1417 which MAY retry with a larger initial hop count. 1419 3. The MRI represents a flow definition which is too general to be 1420 forwarded along a unique path (e.g. the destination address 1421 prefix is too short). The error "MRI Validation Failure" 1422 (Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be 1423 returned to the sender, which MAY retry with restricted MRIs, 1424 possibly starting additional signalling sessions to do so. If 1425 the GIST node does not understand the MRM in question it MUST NOT 1426 apply this check, instead forwarding the message transparently. 1428 In the first two cases, only the common header of the GIST message is 1429 examined; in the third case, the MRI is also examined. The rest of 1430 the message MUST NOT be inspected in any case. Similar to the case 1431 of Section 4.3.2, the GIST payloads MUST NOT be modified or re- 1432 ordered; an implementation MAY choose to achieve this by retaining 1433 the original message, rather than reconstructing it from some parsed 1434 internal representation. 1436 4.4. Routing State and Messaging Association Maintenance 1438 The main responsibility of GIST is to manage the routing state and 1439 messaging associations which are used in the message processing 1440 described above. Routing state is installed and refreshed by GIST 1441 handshake messages. Messaging associations are set up by the normal 1442 procedures of the transport and security protocols that comprise 1443 them, using peer IP addresses from the routing state. Once a 1444 messaging association has been created, its refresh and expiration 1445 can be managed independently from the routing state. 1447 There are two different cases for state installation and refresh: 1449 1. Where routing state is being discovered or a new association is 1450 to be established; and 1452 2. Where a suitable association already exists, including the case 1453 where routing state for the flow is being refreshed. 1455 These cases are now considered in turn, followed by the case of 1456 background general management procedures. 1458 4.4.1. Routing State and Messaging Association Creation 1460 The complete sequence of possible messages for GIST state setup 1461 between adjacent peers is shown in Figure 4 and described in detail 1462 in the following text. The figure informally summarises the contents 1463 of each message, including optional elements in square brackets. An 1464 example is given in Appendix D. 1466 The initial message in any routing state maintenance operation is a 1467 Query, sent from the querying node and intercepted at the responding 1468 node. This message has addressing and other identifiers appropriate 1469 for the flow and signalling application that state maintenance is 1470 being done for, addressing information about the node that generated 1471 the Query itself, and it MAY contain an NSLP payload. It also 1472 includes a Query Cookie, and optionally capability information about 1473 messaging association protocol stacks. The role of the cookies in 1474 this and subsequent messages is to protect against certain denial of 1475 service attacks and to correlate the various events in the message 1476 sequence (see Section 8.5 for further details). 1478 Provided that the signalling application has indicated that message 1479 routing state should be set up (see Section 4.3.2), reception of a 1480 Query MUST elicit a Response. This is a normally encapsulated D-mode 1481 message with additional payloads. It contains network layer 1482 information about the responding node, echoes the Query Cookie, and 1483 MAY contain an NSLP payload, possibly a reply to the NSLP payload in 1484 the initial message. In case a messaging association was requested, 1485 it MUST also contain a Responder Cookie and its own capability 1486 information about messaging association protocol stacks. Even if a 1487 messaging association is not requested, the Response MAY still 1488 include a Responder Cookie if the node's routing state setup policy 1489 requires it (see below). 1491 +----------+ +----------+ 1492 | Querying | |Responding| 1493 | Node(Q-N)| | Node(R-N)| 1494 +----------+ +----------+ 1495 Query 1496 ----------------------> ............. 1497 Router Alert Option . Routing . 1498 MRI/SID/NSLPID . state . 1499 Q-N Network Layer Info . installed . 1500 Query Cookie . at . 1501 [Q-N Stack-Proposal . Responding. 1502 Q-N Stack-Config-Data] . node . 1503 [NSLP Payload] . (case 1) . 1504 ............. 1505 ...................................... 1506 . The responder can use an existing . 1507 . messaging association if available . 1508 . from here onwards to short-circuit . 1509 . messaging association setup . 1510 ...................................... 1512 Response 1513 ............. <---------------------- 1514 . Routing . MRI/SID/NSLPID 1515 . state . R-N Network Layer Info 1516 . installed . Query cookie 1517 . at . [Responder Cookie 1518 . Querying . [R-N Stack-Proposal 1519 . node . R-N Stack-Config-Data]] 1520 ............. [NSLP Payload] 1522 .................................... 1523 . If a messaging association needs . 1524 . to be created, it is set up here . 1525 . and the Confirm uses it . 1526 .................................... 1528 Confirm ............. 1529 ----------------------> . Routing . 1530 MRI/SID/NSLPID . state . 1531 Q-N Network Layer Info . installed . 1532 [Responder Cookie . at . 1533 [R-N Stack-Proposal . Responding. 1534 [Q-N Stack-Config-Data]]] . node . 1535 [NSLP Payload] . (case 2) . 1536 ............. 1538 Figure 4: Message Sequence at State Setup 1540 Setup of a new messaging association begins when peer addressing 1541 information is available and a new messaging association is actually 1542 needed. Any setup MUST take place immediately after the specific 1543 Query/Response exchange, because the addressing information used may 1544 have a limited lifetime, either because it depends on limited 1545 lifetime NAT bindings or because it refers to agile destination ports 1546 for the transport protocols. The Stack-Proposal and Stack- 1547 Configuration-Data objects carried in the exchange carry capability 1548 information about what messaging association protocols can be used, 1549 and the processing of these objects is described in more detail in 1550 Section 5.7. With the protocol options currently defined, setup of 1551 the messaging association always starts from the Querying node, 1552 although more flexible configurations are possible within the overall 1553 GIST design. If the messaging association includes a channel 1554 security protocol, each GIST node MUST verify the authenticated 1555 identity of the peer against its authorised peer database, and if 1556 there is no match the messaging association MUST be torn down. The 1557 database and authorisation check are described in more detail in 1558 Section 4.4.2 below. Note that the verification can depend on what 1559 the MA is to be used for (e.g. for which flow), so this step may not 1560 be possible immediately after authentication has completed but some 1561 time later. 1563 Finally, after any necessary messaging association setup has 1564 completed, a Confirm MUST be sent if the Response requested it. Once 1565 the Confirm has been sent, the Querying node assumes that routing 1566 state has been installed at the responder, and can send normal Data 1567 messages for the flow in question; recovery from a lost Confirm is 1568 discussed in Section 5.3.3. If a messaging association is being 1569 used, the Confirm MUST be sent over it before any other messages for 1570 the same flow, and it echoes the Responder Cookie and Stack-Proposal 1571 from the Response. The former is used to allow the receiver to 1572 validate the contents of the message (see Section 8.5), and the 1573 latter is to prevent certain bidding-down attacks on messaging 1574 association security (see Section 8.6). This first Confirm on a new 1575 association MUST also contain a Stack-Configuration-Data object 1576 carrying an MA-Hold-Time value, which supersedes the value given in 1577 the original Query. The association can be used in the upstream 1578 direction for the MRI and NSLPID carried in the Confirm, after the 1579 Confirm has been received. 1581 The querying node MUST install the responder address, derived from 1582 the R-Node Network Layer info, as routing state information after 1583 verifying the Query Cookie in the Response. The responding node MAY 1584 install the querying address as peer state information at two points 1585 in time: 1587 Case 1: after the receipt of the initial Query, or 1589 Case 2: after a Confirm containing the Responder Cookie. 1591 The responding node SHOULD derive the peer address from the Q-Node 1592 Network Layer Info if this was decoded successfully. Otherwise, it 1593 MAY be derived from the IP source address of the message if the 1594 common header flags this as being the signalling source address. The 1595 precise constraints on when state information is installed are a 1596 matter of security policy considerations on prevention of denial-of- 1597 service attacks and state poisoning attacks, which are discussed 1598 further in Section 8. Because the responding node MAY choose to 1599 delay state installation as in case (2), the Confirm must contain 1600 sufficient information to allow it to be processed in the same way as 1601 the original Query. This places some special requirements on NAT 1602 traversal and cookie functionality, which are discussed in 1603 Section 7.2 and Section 8 respectively. 1605 4.4.2. GIST Peer Authorisation 1607 When two GIST nodes authenticate using a messaging association, both 1608 ends have to decide whether to accept the creation of the MA and 1609 whether to trust the information sent over it. This can be seen as 1610 an authorisation decision: 1612 o Authorised peers are trusted to install correct routing state 1613 about themselves and not, for example, to claim that they are on- 1614 path for a flow when they are not. 1616 o Authorised peers are trusted to obey transport and application 1617 level flow control rules, and not to attempt to create overload 1618 situations. 1620 o Authorised peers are trusted not to send erroneous or malicious 1621 error messages, for example asserting that routing state has been 1622 lost when it has not. 1624 This specification models the decision as verification by the 1625 authorising node of the peer's identity against a local list of 1626 peers, the authorised peer database (APD). The APD is a abstract 1627 construct, similar to the security policy database of IPsec [37]. 1628 Implementations MAY provide the associated functionality in any way 1629 they choose. This section defines only the requirements for APD 1630 administration and the consequences of successfully validating a 1631 peer's identity against it. 1633 The APD consists of a list of entries. Each entry includes an 1634 identity, the namespace from which the identity comes (e.g. DNS 1635 domains), the scope within which the entry is applicable, and whether 1636 authorisation is allowed or denied. The following are example 1637 scopes: 1639 Peer Address Ownership: The scope is the IP address at which the 1640 peer for this MRI should be; the APD entry denotes the identity as 1641 the owner of address. If the authorising node can determine this 1642 address from local information (such as its own routing tables), 1643 matching this entry shows that the peer is the correct on-path 1644 node and so should be authorised. The determination is simple if 1645 the peer is one IP hop downstream, since the IP address can be 1646 derived from the router's forwarding tables. If the peer is more 1647 than one hop away or is upstream, the determination is harder but 1648 may still be possible in some circumstances. The authorising node 1649 may be able to determine a (small) set of possible peer addresses, 1650 and accept that any of these could be the correct peer. 1652 End-System Subnet: The scope is an address range within which the 1653 MRI source or destination lie; the APD entry denotes the identity 1654 as potentially being on-path between the authorising node and that 1655 address range. There may be different source and destination 1656 scopes, to account for asymmetric routing. 1658 The same identity may appear in multiple entries, and the order of 1659 entries in the APD is significant. When a messaging association is 1660 authenticated and associated with an MRI, the authorising node scans 1661 the APD to find the first entry where the identity matches that 1662 presented by the peer, and where the scope information matches the 1663 circumstances for which the MA is being set up. The identity 1664 matching process itself depends on the messaging association protocol 1665 that carries out the authentication, and details for TLS are given in 1666 Section 5.7.3. Whenever the full set of possible peers for a 1667 specific scope is known, deny entries SHOULD be added for the 1668 wildcard identity to reject signalling associations from unknown 1669 nodes. The ability of the authorising node to reject inappropriate 1670 MAs depends directly on the granularity of the APD and the precision 1671 of the scope matching process. 1673 If authorisation is allowed, the MA can be used as normal; otherwise 1674 it MUST be torn down without further GIST exchanges, and any routing 1675 state associated with the MA MUST also be deleted. An error 1676 condition MAY be logged locally. When an APD entry is modified or 1677 deleted, the node MUST re-validate existing MAs and the routing state 1678 table against the revised contents of the APD. This may result in 1679 MAs being torn down or routing state entries being deleted. These 1680 changes SHOULD be indicated to local signalling applications via the 1681 NetworkNotification API call (Appendix B.4). 1683 This specification does not define how the APD is populated. As a 1684 minimum, an implementation MUST provide an administrative interface 1685 through which entries can be added, modified, or deleted. More 1686 sophisticated mechanisms are possible in some scenarios. For 1687 example, the fact that a node is legitimately associated with a 1688 specific IP address could be established by direct embedding of the 1689 IP address as a particular identity type in a certificate, or by a 1690 mapping that address to another identifier type via an additional 1691 database lookup (such as relating IP addresses in in-addr.arpa to 1692 domain names). An enterprise network operator could generate a list 1693 of all the identities of its border nodes as authorised to be on the 1694 signalling path to external destinations, and this could be 1695 distributed to all hosts inside the network. Regardless of the 1696 technique, it MUST be ensured that the source data justify the 1697 authorisation decisions listed at the start of this section, and that 1698 the security of the chain of operations on which the APD entry 1699 depends cannot be compromised. 1701 4.4.3. Messaging Association Multiplexing 1703 It is a design goal of GIST that, as far as possible, a single 1704 messaging association should be used for multiple flows and sessions 1705 between two peers, rather than setting up a new MA for each. This 1706 re-use of existing MAs is referred to as messaging association 1707 multiplexing. Multiplexing ensures that the MA cost scales only with 1708 the number of peers, and avoids the latency of new MA setup where 1709 possible. 1711 However, multiplexing requires the identification of an existing MA 1712 which matches the same routing state and desired properties that 1713 would be the result of a full handshake in D-mode, and this 1714 identification must be done as reliably and securely as continuing 1715 with the full procedure. Note that this requirement is complicated 1716 by the fact that NATs may remap the node addresses in D-mode 1717 messages, and also interacts with the fact that some nodes may peer 1718 over multiple interfaces (and thus with different addresses). 1720 MA multiplexing is controlled by the Network-Layer-Information (NLI) 1721 object, which is carried in Query, Response and Confirm messages. 1722 The NLI object includes: 1724 Peer-Identity: For a given node, this is an interface independent 1725 value with opaque syntax. It MUST be chosen so as to have a high 1726 probability of uniqueness across the set of all potential peers, 1727 and SHOULD be stable at least until the next node restart. Note 1728 that there is no cryptographic protection of this identity; 1729 attempting to provide this would essentially duplicate the 1730 functionality in the messaging association security protocols. 1732 For routers, the Router-ID [2], which is one of the router's IP 1733 addresses, MAY be used as one possible value for the Peer- 1734 Identity. In scenarios with nested NATs, the Router-ID alone may 1735 not satisfy the uniqueness requirements, in which case it MAY be 1736 extended with additional tokens, either chosen randomly or 1737 administratively coordinated. 1739 Interface-Address: This is an IP address through which the 1740 signalling node can be reached. There may be several choices 1741 available for the Interface-Address, and further discussion of 1742 this is contained in Section 5.2.2. 1744 A messaging association is associated with the NLI object that was 1745 provided by the peer in the Query/Response/Confirm at the time the 1746 association was first set up. There may be more than one MA for a 1747 given NLI object, for example with different security or transport 1748 properties. 1750 MA multiplexing is achieved by matching the NLI provided in a new 1751 GIST message with one associated with an existing MA. The message 1752 can be either a Query or Response, although the former is more 1753 likely: 1755 o If there is a perfect match to the NLI of an existing association, 1756 that association SHOULD be re-used, provided it meets the criteria 1757 on security and transport properties given at the end of 1758 Section 5.7.1. This is indicated by sending the remaining 1759 messages in the handshake over that association. This will lead 1760 to multiplexing on an association to the wrong node if signalling 1761 nodes have colliding Peer-Identities and one is reachable at the 1762 same Interface-Address as another. This could be caused by an on- 1763 path attacker; on-path attacks are discussed further in 1764 Section 8.7. When multiplexing is done, and the original MA 1765 authorisation was MRI-dependent, the verification steps of 1766 Section 4.4.2 MUST be repeated for the new flow. 1768 o In all other cases, the full handshake MUST be executed in D-mode 1769 as usual. There are in fact four possibilities: 1771 1. Nothing matches: this is clearly a new peer. 1773 2. Only the Peer-Identity matches: this may be either a new 1774 interface on an existing peer, or a changed address mapping 1775 behind a NAT. These should be rare events, so the expense of 1776 a new association setup is acceptable. Another possibility is 1777 one node using another node's Peer-Identity, for example as 1778 some kind of attack. Because the Peer-Identity is used only 1779 for this multiplexing process, the only consequence this has 1780 is to require a new association setup, and this is considered 1781 in Section 8.4. 1783 3. Only the Interface-Address matches: this is probably a new 1784 peer behind the same NAT as an existing one. A new 1785 association setup is required. 1787 4. The full NLI object matches: this is a degenerate case, where 1788 one node recognises an existing peer, but wishes to allow the 1789 option to set up a new association in any case, for example to 1790 create an association with different properties. 1792 4.4.4. Routing State Maintenance 1794 Each item of routing state expires after a lifetime which is 1795 negotiated during the Query/Response/Confirm handshake. The Network 1796 Layer Info (NLI) object in the Query contains a proposal for the 1797 lifetime value, and the NLI in the Response contains the value the 1798 Responding node requires. A default timer value of 30 seconds is 1799 RECOMMENDED. Nodes which can exploit alternative, more powerful, 1800 route change detection methods such as those described in 1801 Section 7.1.2 MAY choose to use much longer times. Nodes MAY use 1802 shorter times to provide more rapid change detection. If the number 1803 of active routing state items corresponds to a rate of Queries that 1804 will stress the rate limits applied to D-mode traffic 1805 (Section 5.3.3), nodes MUST increase the timer for new items and on 1806 the refresh of existing ones. A suitable value is twice the number 1807 of items divided by the rate limit in messages per second, which 1808 leaves a factor of two headroom for new routing state creation and 1809 Query retransmissions. 1811 The Querying node MUST ensure that a Query is received before this 1812 timer expires, if it believes that the signalling session is still 1813 active; otherwise, the Responding node MAY delete the state. Receipt 1814 of the message at the Responding node will refresh peer addressing 1815 state for one direction, and receipt of a Response at the querying 1816 node will refresh it for the other. There is no mechanism at the 1817 GIST level for explicit teardown of routing state. However, GIST 1818 MUST NOT refresh routing state if a signalling session is known to be 1819 inactive, either because upstream state has expired, or because the 1820 signalling application has indicated via the GIST API (Appendix B.5) 1821 that the state is no longer required, because this would prevent 1822 correct state repair in the case of network rerouting at the IP 1823 layer. 1825 This specification defines precisely only the time at which routing 1826 state expires; it does not define when refresh handshakes should be 1827 initiated. Implementations MUST select timer settings which take at 1828 least the following into account: 1830 o The transmission latency between source and destination; 1832 o The need for retransmissions of Query messages; 1834 o The need to avoid network synchronisation of control traffic (cf. 1835 [40]). 1837 In most cases, a reasonable policy is to initiate the routing state 1838 refresh when between 1/2 and 3/4 of the validity time has elapsed 1839 since the last successful refresh. The actual moment MUST be chosen 1840 randomly within this interval to avoid synchronisation effects. 1842 4.4.5. Messaging Association Maintenance 1844 Unneeded MAs are torn down by GIST, using the teardown mechanisms of 1845 the underlying transport or security protocols if available, for 1846 example by simply closing a TCP connection. The teardown can be 1847 initiated by either end. Whether an MA is needed is a combination of 1848 two factors: 1850 o local policy, which could take into account the cost of keeping 1851 the messaging association open, the level of past activity on the 1852 association, and the likelihood of future activity, e.g. if there 1853 is routing state still in place which might generate messages to 1854 use it. 1856 o whether the peer still wants the MA to remain in place. During MA 1857 setup, as part of the Stack-Configuration-Data, each node 1858 advertises its own MA-Hold-Time, which is the time for which it 1859 will retain an MA which is not carrying signalling traffic. A 1860 node MUST NOT tear down an MA if it has received traffic from its 1861 peer over that period. A peer which has generated no traffic but 1862 still wants the MA retained can use a special null message (MA- 1863 Hello) to indicate the fact. A default value for MA-Hold-Time of 1864 30 seconds is RECOMMENDED. Nodes MAY use shorter times to achieve 1865 more rapid peer failure detection, but need to take into account 1866 the load on the network created by the MA-Hello messages. Nodes 1867 MAY use longer times, but need to take into account the cost of 1868 retaining idle MAs for extended periods. Nodes MAY take 1869 signalling application behaviour (e.g. NSLP refresh times) into 1870 account in choosing an appropriate value. 1872 Because the Responding node can choose not to create state until a 1873 Confirm, an abbreviated Stack-Configuration-Data object containing 1874 just this information MUST be repeated by the Querying node in the 1875 first Confirm sent on a new MA. If the object is missing in the 1876 Confirm, an "Object Type Error" message (Appendix A.4.4.9) with 1877 subcode 2 ("Missing Object") MUST be returned. 1879 Messaging associations can always be set up on demand, and messaging 1880 association status is not made directly visible outside the GIST 1881 layer. Therefore, even if GIST tears down and later re-establishes a 1882 messaging association, signalling applications cannot distinguish 1883 this from the case where the MA is kept permanently open. To 1884 maintain the transport semantics described in Section 4.1, GIST MUST 1885 close transport connections carrying reliable messages gracefully or 1886 report an error condition, and MUST NOT open a new association to be 1887 used for given session and peer while messages on a previous 1888 association could still be outstanding. GIST MAY use an MA-Hello 1889 request/reply exchange on an existing association to verify that 1890 messages sent on it have reached the peer. GIST MAY use the same 1891 technique to test the liveness of the underlying MA protocols 1892 themselves at arbitrary times. 1894 This specification defines precisely only the time at which messaging 1895 associations expires; it does not define when keepalives should be 1896 initiated. Implementations MUST select timer settings which take at 1897 least the following into account: 1899 o The transmission latency between source and destination; 1901 o The need for retransmissions within the messaging association 1902 protocols; 1904 o The need to avoid network synchronisation of control traffic (cf. 1905 [40]). 1907 In most cases, a reasonable policy is to initiate the MA refresh when 1908 between 1/2 and 3/4 of the validity time has elapsed since the last 1909 successful refresh. The actual moment MUST be chosen randomly within 1910 this interval to avoid synchronisation effects. 1912 4.4.6. Routing State Failures 1914 A GIST node can receive a message from a GIST peer, which can only be 1915 correctly processed in the context of some routing state, but where 1916 no corresponding routing state exists. Cases where this can arise 1917 include: 1919 o Where the message is random traffic from an attacker, or 1920 backscatter (replies to such traffic). 1922 o Where routing state has been correctly installed but the peer has 1923 since lost it, for example because of aggressive timeout settings 1924 at the peer, or because the node has crashed and restarted. 1926 o Where the routing state has never been correctly installed in the 1927 first place, but the sending node does not know this. This can 1928 happen if the Confirm message of the handshake is lost. 1930 It is important for GIST to recover from such situations promptly 1931 where they represent genuine errors (node restarts, or lost messages 1932 which would not otherwise be retransmitted). Note that only 1933 Response, Confirm, Error and Data messages ever require routing state 1934 to exist, and these are considered in turn: 1936 Response: A Response can be received at a node which never sent (or 1937 has forgotten) the corresponding Query. If the node wants routing 1938 state to exist, it will initiate it itself; a diagnostic error 1939 would not allow the sender of the Response to take any corrective 1940 action, and the diagnostic could itself be a form of backscatter. 1941 Therefore, an error message MUST NOT be generated, but the 1942 condition MAY be logged locally. 1944 Confirm: For a Responding node which implements delayed state 1945 installation, this is normal behaviour, and routing state will be 1946 created provided the Confirm is validated. Otherwise, this is a 1947 case of a non-existent or forgotten Response, and the node may not 1948 have sufficient information in the Confirm to create the correct 1949 state. The requirement is to notify the Querying node so that it 1950 can recover the routing state. 1952 Data: This arises when a node receives Data where routing state is 1953 required, but either it does not exist at all, or it has not been 1954 finalised (no Confirm message). To avoid Data being black-holed, 1955 a notification must be sent to the peer. 1957 Error: Some error messages can only be interpreted in the context of 1958 routing state. However, the only error messages which require a 1959 reply within the protocol are routing state error messages 1960 themselves. Therefore, this case should be treated the same as a 1961 Response: an error message MUST NOT be generated, but the 1962 condition MAY be logged locally. 1964 For the case of Confirm or Data messages, if the state is required 1965 but does not exist, the node MUST reject the incoming message with a 1966 "No Routing State" error message (Appendix A.4.4.5). There are then 1967 three cases at the receiver of the error message: 1969 No routing state: The condition MAY be logged but a reply MUST NOT 1970 be sent (see above). 1972 Querying node: The node MUST restart the GIST handshake from the 1973 beginning, with a new Query. 1975 Responding node: The node MUST delete its own routing state and 1976 SHOULD report an error condition to the local signalling 1977 application. 1979 The rules at the Querying or Responding node make GIST open to 1980 disruption by randomly injected error messages, similar to blind 1981 reset attacks on TCP (cf. [44]), although because routing state 1982 matching includes the SID this is mainly limited to on-path 1983 attackers. If a GIST node detects a significant rate of such 1984 attacks, it MAY adopt a policy of using secured messaging 1985 associations to communicate for the affected MRIs, and only accepting 1986 "No Routing State" error messages over such associations. 1988 5. Message Formats and Transport 1990 5.1. GIST Messages 1992 All GIST messages begin with a common header, followed by a sequence 1993 of type-length-value (TLV) objects. This subsection describes the 1994 various GIST messages and their contents at a high level in ABNF 1995 [12]; a more detailed description of the header and each object is 1996 given in Section 5.2. Note that the NAT traversal mechanism for GIST 1997 involves the insertion of an additional NAT-Traversal-Object in 1998 Query, Response, and some Data and Error messages; the rules for this 1999 are given in Section 7.2. 2001 GIST-Message: The primary messages are either one of the stages in 2002 the three-way handshake, or a simple message carrying NSLP data. 2003 Additional types are defined for errors and keeping messaging 2004 associations alive. 2005 GIST-Message = Query / Response / Confirm / 2006 Data / Error / MA-Hello 2008 The common header includes a version number, message type and size, 2009 and NSLPID. It also carries a hop count to prevent infinite message 2010 looping and various control flags, including one (the R flag) to 2011 indicate if a reply of some sort is requested. The objects following 2012 the common header MUST be carried in a fixed order, depending on 2013 message type. Messages with missing, duplicate or invalid objects 2014 for the message type MUST be rejected with an "Object Type Error" 2015 message with the appropriate subcode (Appendix A.4.4.9). 2017 Query: A Query MUST be sent in D-mode using the special Q-mode 2018 encapsulation. In addition to the common header, it contains certain 2019 mandatory control objects, and MAY contain a signalling application 2020 payload. A stack proposal and configuration data MUST be included if 2021 the message exchange relates to setup of a messaging association. 2022 The R flag MUST always be set (R=1) in a Query, since this message 2023 always elicits a Response. 2024 Query = Common-Header 2025 [ NAT-Traversal-Object ] 2026 Message-Routing-Information 2027 Session-Identification 2028 Network-Layer-Information 2029 Query-Cookie 2030 [ Stack-Proposal Stack-Configuration-Data ] 2031 [ NSLP-Data ] 2033 Response: A Response MAY be sent in D-mode, or MAY be sent in C-mode 2034 if an existing messaging association is being re-used. It MUST echo 2035 the MRI SID and Query-Cookie of the Query, and carries its own 2036 Network-Layer-Information. If the message exchange relates to setup 2037 of a new messaging association, which MUST be carried out in D-mode, 2038 a Responder cookie MUST be included, as well as the Responder's own 2039 stack proposal and configuration data. The R flag MUST be set (R=1) 2040 if a Responder cookie is present but otherwise is optional; if the R 2041 flag is set, a Confirm MUST be sent as a reply. Note that the 2042 direction of this MRI will be inverted compared to that in the Query, 2043 that is, an upstream MRI becomes downstream and vice versa (see 2044 Section 3.3). 2045 Response = Common-Header 2046 [ NAT-Traversal-Object ] 2047 Message-Routing-Information 2048 Session-Identification 2049 Network-Layer-Information 2050 Query-Cookie 2051 [ Responder-Cookie 2052 [ Stack-Proposal Stack-Configuration-Data ] ] 2053 [ NSLP-Data ] 2055 Confirm: A Confirm MUST be sent in C-mode if a messaging association 2056 is being used for this routing state, and MUST be sent before other 2057 messages for this routing state. If no messaging association is 2058 being used, the Confirm MUST be sent in D-mode. The Confirm MUST 2059 echo the MRI (with inverted direction), SID, and Responder-Cookie if 2060 the Response carried one. In C-mode, the Confirm MUST also echo the 2061 Stack-Proposal from the Response so it can be verified that this has 2062 not been tampered with. The first Confirm on a new association MUST 2063 also repeat the Stack-Configuration-Data from the original Query in 2064 an abbreviated form, just containing the MA-Hold-Time. 2065 Confirm = Common-Header 2066 Message-Routing-Information 2067 Session-Identification 2068 Network-Layer-Information 2069 [ Responder-Cookie 2070 [ Stack-Proposal 2071 [ Stack-Configuration-Data ] ] ] 2072 [ NSLP-Data ] 2074 Data: The Data message is used to transport NSLP data without 2075 modifying GIST state. It contains no control objects, but only the 2076 MRI and SID associated with the NSLP data being transferred. 2077 Network-Layer-Information (NLI) MUST be carried in the D-mode case, 2078 but MUST NOT be included otherwise. 2080 Data = Common-Header 2081 [ NAT-Traversal-Object ] 2082 Message-Routing-Information 2083 Session-Identification 2084 [ Network-Layer-Information ] 2085 NSLP-Data 2087 Error: An Error message reports a problem determined at the GIST 2088 level. (Errors generated by signalling applications are reported in 2089 NSLP-Data payloads and are not treated specially by GIST.) The 2090 message includes a Network-Layer-Information object for the 2091 originator of the error message if it is being sent in D-mode; all 2092 other information related to the error is carried in a GIST-Error- 2093 Data object. 2094 Error = Common-Header 2095 [ NAT-Traversal-Object ] 2096 [ Network-Layer-Information ] 2097 GIST-Error-Data 2099 MA-Hello: This message MUST be sent only in C-mode. It contains the 2100 common header, with a NSLPID of zero, and a message identifier, the 2101 Hello-ID. It always indicates that a node wishes to keep a messaging 2102 association open, and if sent with R=0 and null Hello-ID this is its 2103 only function. A node MAY also invoke a diagnostic request/reply 2104 exchange by setting R=1 and providing a non-zero Hello-ID; if this 2105 case, the peer MUST send another MA-Hello back along the messaging 2106 association echoing the same Hello-ID and with R=0. Use of this 2107 diagnostic is entirely at the discretion of the initiating node. 2108 MA-Hello = Common-Header 2109 Hello-ID 2111 5.2. Information Elements 2113 This section describes the content of the various objects that can be 2114 present in each GIST message, both the common header, and the 2115 individual TLVs. The bit formats are provided in Appendix A. 2117 5.2.1. The Common Header 2119 Each message begins with a fixed format common header, which contains 2120 the following information: 2122 Version: The version number of the GIST protocol. This 2123 specification defines GIST version 1. 2125 GIST hop count: A hop count to prevent a message from looping 2126 indefinitely. 2128 Length: The number of 32 bit words in the message following the 2129 common header. 2131 Upper layer identifier (NSLPID): This gives the specific NSLP that 2132 this message is used for. 2134 Message type: The message type (Query, Response, etc.) 2136 Source addressing mode: If set (S=1), this indicates that the IP 2137 source address of the message is the same as the IP address of the 2138 signalling peer, so replies to this message can be sent safely to 2139 this address. S is always set in C-mode. It is cleared (S=0) if 2140 the IP source address was derived from the message routing 2141 information in the payload and this is different from the 2142 signalling source address. 2144 Response requested: A flag which if set (R=1) indicates that a GIST 2145 message should be sent in reply to this message. The appropriate 2146 message type for the reply depends on the type of the initial 2147 message. 2149 Explicit routing: A flag which if set (E=1) indicates that the 2150 message was explicitly routed (see Section 7.1.5). 2152 Note that in D-mode Section 5.3, there is a 32-bit magic number 2153 before the header. However, this is regarded as part of the 2154 encapsulation rather than part of the message itself. 2156 5.2.2. TLV Objects 2158 All data following the common header is encoded as a sequence of 2159 type-length-value objects. Currently, each object can occur at most 2160 once; the set of required and permitted objects is determined by the 2161 message type and encapsulation (D-mode or C-mode). 2163 Message-Routing-Information (MRI): Information sufficient to define 2164 how the signalling message should be routed through the network. 2166 Message-Routing-Information = message-routing-method 2167 method-specific-information 2169 The format of the method-specific-information depends on the 2170 message-routing-method requested by the signalling application. 2171 Note that it always includes a flag defining the direction as 2172 either 'upstream' or 'downstream' (see Section 3.3). It is 2173 provided by the NSLP in the message sender and used by GIST to 2174 select the message routing. 2176 Session-Identification (SID): The GIST session identifier is a 128 2177 bit, cryptographically random identifier chosen by the node which 2178 originates the signalling exchange. See Section 3.7. 2180 Network-Layer-Information (NLI): This object carries information 2181 about the network layer attributes of the node sending the 2182 message, including data related to the management of routing 2183 state. This includes a peer identity and IP address for the 2184 sending node. It also includes IP-TTL information to allow the IP 2185 hop count between GIST peers to be measured and reported, and a 2186 validity time (RS-validity-time) for the routing state. 2188 Network-Layer-Information = peer-identity 2189 interface-address 2190 RS-validity-time 2191 IP-TTL 2193 The use of the RS-validity-time field is described in 2194 Section 4.4.4. The peer-identity and interface-address are used 2195 for matching existing associations, as discussed in Section 4.4.3. 2197 The interface-address must be routable, i.e. it MUST be usable as 2198 a destination IP address for packets to be sent back to the node 2199 generating the signalling message, whether in D-mode or C-mode. 2200 If this object is carried in a message with the source addressing 2201 mode flag S=1, the interface-address MUST match the source address 2202 used in the IP encapsulation, to assist in legacy NAT detection 2203 (Section 7.2.1). If this object is carried in a Query or Confirm, 2204 the interface-address MUST specifically be set to an address bound 2205 to the interface associated with the MRI, to allow its use in 2206 route change handling as discussed in Section 7.1. A suitable 2207 choice is the interface that is carrying the outbound flow. A 2208 node may have several choices for which of its addresses to use as 2209 the interface-address. For example, there may be a choice of IP 2210 versions, or addresses of limited scope (e.g. link-local), or 2211 addresses bound to different interfaces in the case of a router or 2212 multi-homed host. However, some of these interface addresses may 2213 not be usable by the peer. A node MUST follow a policy of using a 2214 global address of the same IP version as in the MRI, unless it can 2215 establish that an alternative address would also be usable. 2217 The setting and interpretation of the IP-TTL field depends on the 2218 message direction (upstream/downstream as determined from the MRI 2219 as described above) and encapsulation. 2221 * If the message is sent downstream, if the TTL that will be set 2222 in the IP header for the message can be determined, the IP-TTL 2223 value MUST be set to this value, or else set to 0. 2225 * On receiving a downstream message in D-mode, a non-zero IP-TTL 2226 is compared to the TTL in the IP header, and the difference is 2227 stored as the IP-hop-count-to-peer for the upstream peer in the 2228 routing state table for that flow. Otherwise, the field is 2229 ignored. 2231 * If the message is sent upstream, the IP-TTL MUST be set to the 2232 value of the IP-hop-count-to-peer stored in the routing state 2233 table, or 0 if there is no value yet stored. 2235 * On receiving an upstream message, the IP-TTL is stored as the 2236 IP-hop-count-to-peer for the downstream peer. 2238 In all cases, the IP-TTL value reported to signalling applications 2239 is the one stored with the routing state for that flow, after it 2240 has been updated if necessary from processing the message in 2241 question. 2243 Stack-Proposal: This field contains information about which 2244 combinations of transport and security protocols are available for 2245 use in messaging associations, and is also discussed further in 2246 Section 5.7. 2248 Stack-Proposal = 1*stack-profile 2250 stack-profile = 1*protocol-layer 2252 Each protocol-layer field identifies a protocol with a unique tag; 2253 any additional data, such as higher-layer addressing or other 2254 options data associated with the protocol, will be carried in a 2255 MA-protocol-options field in the Stack-Configuration-Data TLV (see 2256 below). 2258 Stack-Configuration-Data (SCD): This object carries information 2259 about the overall configuration of a messaging association. 2261 Stack-Configuration-Data = MA-Hold-Time 2262 0*MA-protocol-options 2264 The MA-Hold-Time field indicates how long a node will hold open an 2265 inactive association; see Section 4.4.5 for more discussion. The 2266 MA-protocol-options fields give the configuration of the protocols 2267 (e.g. TCP, TLS) to be used for new messaging associations, and 2268 they are described in more detail in Section 5.7. 2270 Query-Cookie/Responder-Cookie: A Query-Cookie is contained in a 2271 Query and MUST be echoed in a Response; a Responder-Cookie MAY be 2272 sent in a Response, and if present MUST be echoed in the following 2273 Confirm. Cookies are variable length bit strings, chosen by the 2274 cookie generator. See Section 8.5 for further details on 2275 requirements and mechanisms for cookie generation. 2277 Hello-ID: The Hello-ID is a 32-bit quantity that is used to 2278 correlate messages in an MA-Hello request/reply exchange. A non- 2279 zero value MUST be used in a request (messages sent with R=1) and 2280 the same value must be returned in the reply (which has R=0). The 2281 value zero MUST be used for all other messages; if a message is 2282 received with R=1 and Hello-ID=0, an "Object Value Error" message 2283 (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") MUST be 2284 returned and the message dropped. Nodes MAY use any algorithm to 2285 generate the Hello-ID; a suitable approach is a local sequence 2286 number with a random starting point. 2288 NSLP-Data: The NSLP payload to be delivered to the signalling 2289 application. GIST does not interpret the payload content. 2291 GIST-Error-Data: This contains all the information to report the 2292 cause and context of an error. 2294 GIST-Error-Data = error-class error-code error-subcode 2295 common-error-header 2296 [ Message-Routing-Information-content ] 2297 [ Session-Identification-content ] 2298 0*additional-information 2299 [ comment ] 2301 The error-class indicates the severity level, and the error-code 2302 and error-subcode identify the specific error itself. A full list 2303 of GIST errors and their severity levels is given in Appendix A.4. 2304 The common-error-header carries the Common-Header from the 2305 original message, and contents of the Message-Routing-Information 2306 (MRI) and Session-Identification (SID) objects are also included 2307 if they were successfully decoded. For some errors, additional 2308 information fields can be included, and these fields themselves 2309 have a simple TLV format. Finally, an optional free-text comment 2310 may be added. 2312 5.3. D-mode Transport 2314 This section describes the various encapsulation options for D-mode 2315 messages. Although there are several possibilities, depending on 2316 message type, MRM, and local policy, the general design principle is 2317 that the sole purpose of the encapsulation is to ensure that the 2318 message is delivered to or intercepted at the correct peer. Beyond 2319 that, minimal significance is attached to the type of encapsulation 2320 or the values of addresses or ports used for it. This allows new 2321 options to be developed in the future to handle particular deployment 2322 requirements without modifying the overall protocol specification. 2324 5.3.1. Normal Encapsulation 2326 Normal encapsulation MUST be used for all D-mode messages where the 2327 signalling peer is already known from previous signalling. This 2328 includes Response and Confirm messages, and Data messages except if 2329 these are being sent without using local routing state. Normal 2330 encapsulation is simple: the message is carried in a single UDP 2331 datagram. UDP checksums MUST be enabled. The payload MUST always 2332 begin with a 32 bit magic number with value 0x4e04 bda5 in network 2333 byte order; this is followed by the GIST common header and the 2334 complete set of payloads. If the magic number is not present, the 2335 message MUST be rejected with a "Common Header Parse Error" message 2336 (Appendix A.4.4.1) with subcode 5 ("Missing Magic Number"). 2338 The message is IP addressed directly to the adjacent peer as given by 2339 the routing state table. Where the message is a direct reply to a 2340 Query and no routing state exists, the destination address is derived 2341 from the input message using the same rules as in Section 4.4.1. The 2342 UDP port numbering MUST be compatible with that used on Query 2343 messages (see below), that is, the same for messages in the same 2344 direction and with source and destination port numbers swapped for 2345 messages in the opposite direction. Normally encapsulated messages 2346 MUST be sent with source addressing mode flag S=1 unless the message 2347 is a reply to a message which is known to have passed through a NAT, 2348 and the receiver MUST check the IP source address with the interface- 2349 address given in the NLI as part of legacy NAT detection. Both these 2350 aspects of message processing are discussed further in Section 7.2.1. 2352 5.3.2. Q-mode Encapsulation 2354 Q-mode encapsulation MUST be used for messages where no routing state 2355 is available or where the routing state is being refreshed, in 2356 particular for Query messages. Q-mode encapsulation is similar to 2357 normal encapsulation, with changes in IP address selection, IP 2358 options, and a defined method for selecting UDP ports. 2360 5.3.2.1. Encapsulation and Interception in IPv4 2362 In general, the IP addresses are derived from information in the MRI; 2363 the exact rules depend on the MRM. For the case of messages with 2364 source addressing mode flag S=1, the receiver MUST check the IP 2365 source address with the interface-address given in the NLI as part of 2366 legacy NAT detection, see Section 7.2.1. 2368 Current MRMs define the use of a Router Alert Option [3] to assist 2369 the peer in intercepting the message depending on the NSLPID. If the 2370 MRM defines the use of RAO, the sender MUST include it by default. 2371 However, a node MAY make the initial interception decision based 2372 purely on IP-Protocol number transport header analysis (see below). 2373 Implementations MAY provide an option to disable the setting of RAO 2374 on Q-mode packets on a per-destination prefix basis; however, the 2375 option MUST be disabled by default and MUST only be enabled when it 2376 has been separately verified that the the next GIST node along the 2377 path to the destination is capable of intercepting packets without 2378 RAO. The purpose of this option is to allow operation across 2379 networks which do not properly support RAO; further details are 2380 discussed in Appendix C. 2382 It is possible that fragmented datagrams including an RAO will not be 2383 correctly handled in the network; furthermore, some of the checks 2384 that a datagram is a Q-mode packet depend on data beyond the IP 2385 header. Therefore the sender MUST set the Don't Fragment (DF) bit in 2386 the IPv4 header. Note that all MRMs require S=1 for at least some 2387 retransmissions, so ICMP errors related to fragmentation will be seen 2388 at the Querying node. 2390 The upper layer protocol, identified by the IP-Protocol field in the 2391 IP header, MUST be UDP. 2393 5.3.2.2. Encapsulation and Interception in IPv6 2395 As for IPv4, the IP addresses are derived from information in the 2396 MRI; the exact rules depend on the MRM. For the case of messages 2397 with source addressing mode flag S=1, the receiver MUST check the IP 2398 source address with the interface-address given in the NLI as part of 2399 legacy NAT detection, see Section 7.2.1. 2401 For all current MRMs, the IP header is given a Router Alert Option 2402 [8] to assist the peer in intercepting the message depending on the 2403 NSLPID. If the MRM defines the use of RAO, the sender MUST include 2404 it without exception. It is RECOMMENDED that a node bases its 2405 initial interception decision purely on the presence of a hop-by-hop 2406 option header containing the RAO, which will be at the start of the 2407 header chain. 2409 The upper layer protocol MUST be UDP without intervening 2410 encapsulation layers. Following the hop-by-hop option header, the IP 2411 header MUST NOT include any extension headers other than routing 2412 options or destination options, and for the last extension header 2413 MUST have a next-header field of UDP. 2415 5.3.2.3. Upper Layer Encapsulation and Overall Interception 2416 Requirements 2418 For both IP versions, the above rules require that the upper layer 2419 protocol identified by the IP header MUST be UDP. Other packets MUST 2420 NOT be identified as GIST Q-mode packets; this includes IP-in-IP 2421 tunnelled packets, other tunnelled packets (tunnel mode AH/ESP), or 2422 packets which have undergone some additional transport layer 2423 processing (transport mode AH/ESP). If IP output processing at the 2424 originating node or an intermediate router causes such additional 2425 encapsulations to be added to a GIST Q-mode packet, this packet will 2426 not be identified as GIST until the encapsulation is terminated. If 2427 the node wishes to signal for data over the network region where the 2428 encapsulation applies, it MUST generate additional signalling with an 2429 MRI matching the encapsulated traffic, and the outbound GIST Q-mode 2430 messages for it MUST bypass the encapsulation processing. 2432 Therefore, the final stage of the interception process and the final 2433 part of encapsulation is at the UDP level. The source UDP port is 2434 selected by the message sender as the port at which it is prepared to 2435 receive UDP messages in reply, and the sender MUST use the 2436 destination UDP port allocated for GIST by IANA (see Section 9). 2437 Note that for some MRMs, GIST nodes anywhere along the path can 2438 generate GIST packets with source addresses that spoof the source 2439 address of the data flow. Therefore, destinations cannot distinguish 2440 these packets from genuine end-to-end data purely on address 2441 analysis. Instead, it must be possible to distinguish such GIST 2442 packets by port analysis; furthermore, the mechanism to do so must 2443 remain valid even if the destination is GIST-unaware. GIST solves 2444 this problem by using a fixed destination UDP port from the "well 2445 known" space for the Q-mode encapsulation. This port should never be 2446 allocated on a GIST-unaware host, and therefore Q-mode encapsulated 2447 messages should always be rejected with an ICMP error. 2449 Within the network, there may be packets using the GIST UDP port but 2450 which are not in fact GIST traffic. Q-mode packets carry the same 2451 magic number as other D-mode packets (see Section 5.3.1). A Q-mode 2452 packets intercepted within the networ which does not match both the 2453 UDP destination port and the magic number MUST be forwarded 2454 transparently at the IP layer, regardless of any RAO value they 2455 contain. Regardless of the IP level encapsulation, if either the 2456 destination port is not the GIST port, or the payload start does not 2457 match the magic number, the packet MUST NOT be identified as a GIST 2458 Q-mode packet and MUST be processed as a normal IP datagram. If a 2459 Q-mode packet is received at an end system (i.e. the at the 2460 destination address of the IP datagram), if it does not start with 2461 the correct magic number it MUST be rejected as in the D-mode case. 2463 5.3.2.4. IP Option Processing 2465 For both IPv4 and IPv6, for Q-mode packets with IP options allowed by 2466 the above requirements, IP options processing is intended to be 2467 carried out independently of GIST processing. Note that for the 2468 options allowed by the above rules, the options semantics are 2469 independent of the payload: UDP payload modifications are not 2470 prevented by the options and do not affect the options content, and 2471 conversely the presence of the options does not affect the UDP 2472 payload. 2474 On packets originated by GIST, IP options MAY be added according to 2475 node-local policies on outgoing IP data. On packets forwarded by 2476 GIST without NSLP processing, IP options MUST be processed as for a 2477 normally forwarded IP packet. On packets locally delivered to the 2478 NSLP, the IP options MAY be passed to the NSLP and equivalent options 2479 used on subsequently generated outgoing Q-mode packets. In this 2480 case, routing related options on SHOULD be processed identically as 2481 they would be for a normally forwarded IP packet. 2483 5.3.3. Retransmission and Rate Control 2485 D-mode uses UDP, and hence has no automatic reliability or congestion 2486 control capabilities. Signalling applications requiring reliability 2487 should be serviced using C-mode, which should also carry the bulk of 2488 signalling traffic. However, some form of messaging reliability is 2489 required for the GIST control messages themselves, as is rate control 2490 to handle retransmissions and also bursts of unreliable signalling or 2491 state setup requests from the signalling applications. 2493 Query messages which do not receive Responses MAY be retransmitted; 2494 retransmissions MUST use a binary exponential backoff. The initial 2495 timer value is T1, which the backoff process can increase up to a 2496 maximum value of T2 seconds. The default value for T1 is 500 ms. T1 2497 is an estimate of the round-trip time between the querying and 2498 responding nodes. Nodes MAY use smaller values of T1 if it is known 2499 that the Query should be answered within the local network. T1 MAY 2500 be chosen larger, and this is RECOMMENDED if it is known in advance 2501 (such as on high latency access links) that the round-trip time is 2502 larger. The default value of T2 is 64*T1. Note that Queries may go 2503 unanswered either because of message loss (in either direction), or 2504 because there is no reachable GIST peer. Therefore, implementations 2505 MAY trade off reliability (large T2) against promptness of error 2506 feedback to applications (small T2). If the NSLP has indicated a 2507 timeout on the validity of this payload (see Appendix B.1), T2 MUST 2508 be chosen so that the process terminates within this timeout. 2509 Retransmitted Queries MUST use different Query-Cookie values. If the 2510 Query carries NSLP data, it may be delivered multiple times to the 2511 signalling application. These rules apply equally to the message 2512 that first creates routing state, and those that refresh it. In all 2513 cases, Responses MUST be sent promptly to avoid spurious 2514 retransmissions. Nodes generating any type of retransmission MUST be 2515 prepared to receive and match a reply to any of them, not just the 2516 one most recently sent. Although a node SHOULD terminate its 2517 retransmission process when any reply is received, it MUST continue 2518 to process further replies as normal. 2520 This algorithm is sufficient to handle lost Queries and Responses. 2521 The case of a lost Confirm is more subtle. The Responding node MAY 2522 run a retransmission timer to resend the Response until a Confirm is 2523 received. The problem of an amplification attack stimulated by a 2524 malicious Query is handled by requiring the cookie mechanism to 2525 enable the node receiving the Response to discard it efficiently if 2526 it does not match a previously sent Query. This approach is only 2527 appropriate if the Responding node is prepared to store per-flow 2528 state after receiving a single (Query) message, which includes the 2529 case where the node has queued NSLP data. If the Responding node has 2530 delayed state installation, the error condition will only be detected 2531 when a Data message arrives. This is handled as a routing state 2532 error (see Section 4.4.6) which causes the Querying node to restart 2533 the handshake. 2535 The basic rate-control requirements for D-mode traffic are 2536 deliberately minimal. A single rate limiter applies to all traffic, 2537 for all interfaces and message types. It applies to retransmissions 2538 as well as new messages, although an implementation MAY choose to 2539 prioritise one over the other. Rate-control applies only to locally 2540 generated D-mode messages, not to messages which are being forwarded. 2541 When the rate limiter is in effect, D-mode messages MUST be queued 2542 until transmission is re-enabled, or they MAY be dropped with an 2543 error condition indicated back to local signalling applications. In 2544 either case, the effect of this will be to reduce the rate at which 2545 new transactions can be initiated by signalling applications, thereby 2546 reducing the load on the network. 2548 The rate limiting mechanism is implementation-defined, but it is 2549 RECOMMENDED that a token bucket limiter as described in [34] be used. 2550 The token bucket MUST be sized to ensure that a node cannot saturate 2551 the network with D-mode traffic, for example when re-probing the 2552 network for multiple flows after a route change. A suitable approach 2553 is to restrict the token bucket parameters so that the mean output 2554 rate is a small fraction, such as 5%, of the node's lowest-speed 2555 interface. Note that, according to the rules of Section 4.3.3, in 2556 general D-mode SHOULD only be used for Queries and Responses rather 2557 than normal signalling traffic. 2559 5.4. C-mode Transport 2561 It is a requirement of the NTLP defined in [30] that it should be 2562 able to support bundling of small messages, fragmentation of large 2563 messages, and message boundary delineation. TCP provides both 2564 bundling and fragmentation, but not message boundaries. However, the 2565 length information in the GIST common header allows the message 2566 boundary to be discovered during parsing. The bundling together of 2567 small messages can either be done within the transport protocol or 2568 can be carried out by GIST during message construction. Either way, 2569 two approaches can be distinguished: 2571 1. As messages arrive for transmission they are gathered into a 2572 bundle until a size limit is reached or a timeout expires (cf. 2573 the Nagle algorithm of TCP). This provides maximal efficiency at 2574 the cost of some latency. 2576 2. Messages awaiting transmission are gathered together while the 2577 node is not allowed to send them, for example because it is 2578 congestion controlled. 2580 The second type of bundling is always appropriate. For GIST, the 2581 first type MUST NOT be used for trigger messages (i.e. messages that 2582 update GIST or signalling application state), but may be appropriate 2583 for refresh messages (i.e. messages that just extend timers). These 2584 distinctions are known only to the signalling applications, but MAY 2585 be indicated (as an implementation issue) by setting the priority 2586 transfer attribute (Section 4.1.2). 2588 It can be seen that all of these transport protocol options can be 2589 supported by the basic GIST message format already presented. The 2590 GIST message, consisting of common header and TLVs, is carried 2591 directly in the transport protocol, possibly incorporating transport 2592 layer security protection. Further messages can be carried in a 2593 continuous stream. This specification defines only the use of TCP, 2594 but other possibilities could be included without additional work on 2595 message formatting. 2597 5.5. Message Type/Encapsulation Relationships 2599 GIST has four primary message types (Query, Response, Confirm, and 2600 Data) and three possible encapsulation methods (normal D-mode, 2601 Q-mode, and C-mode). The possible combinations of message type and 2602 encapsulation are given in the table below. In some cases there are 2603 several possible choices, depending on the existence of routing state 2604 or messaging associations. The rules governing GIST policy, 2605 including whether or not to create such state to handle a message, 2606 are described normatively in the other sections of this 2607 specification. If a message arrives with an invalid encapsulation 2608 (e.g. a Query arrives over a messaging association), this MUST be 2609 rejected with an "Incorrect Encapsulation" error message 2610 (Appendix A.4.4.3). However, it should be noted that the processing 2611 of the message at the receiver is not otherwise affected by the 2612 encapsulation method used, except that that the decapsulation process 2613 may provide additional information, such as translated addresses or 2614 IP hop count to be used in the subsequent message processing. 2616 +----------+-----------------+---------------------+----------------+ 2617 | Message | Normal D-mode | Query D-mode | C-mode | 2618 | | | (Q-mode) | | 2619 +----------+-----------------+---------------------+----------------+ 2620 | Query | Never | Always | Never | 2621 | | | | | 2622 | Response | Unless a | Never | If a messaging | 2623 | | messaging | | association is | 2624 | | association is | | being re-used | 2625 | | being re-used | | | 2626 | | | | | 2627 | Confirm | Only if no | Never | If a messaging | 2628 | | messaging | | association | 2629 | | association has | | has been set | 2630 | | been set up or | | up or is being | 2631 | | is being | | re-used | 2632 | | re-used | | | 2633 | | | | | 2634 | Data | If routing | If no routing state | If a messaging | 2635 | | state exists | exists and the MRI | association | 2636 | | for the flow | can be used to | exists | 2637 | | but no | derive the Q-mode | | 2638 | | messaging | encapsulation | | 2639 | | association | | | 2640 +----------+-----------------+---------------------+----------------+ 2642 5.6. Error Message Processing 2644 Special rules apply to the encapsulation and transmission of error 2645 messages. 2647 GIST only generates error messages in reaction to incoming messages. 2648 Error messages MUST NOT be generated in reaction to incoming error 2649 messages. The routing and encapsulation of the error message is 2650 derived from that of the message that caused the error; in 2651 particular, local routing state is not consulted. Routing state and 2652 messaging association state MUST NOT be created to handle the error, 2653 and error messages MUST NOT be retransmitted explicitly by GIST, 2654 although they are subject to the same rate control as other messages. 2656 o If the incoming message was received in D-mode, the error MUST be 2657 sent in D-mode using the normal encapsulation, using the 2658 addressing information from the NLI object in the incoming 2659 message. If the NLI could not be determined, the error MUST be 2660 sent to the IP source of the incoming message if the S flag was 2661 set in it. The NLI object in the Error message reports 2662 information about the originator of the error. 2664 o If the incoming message was received over a messaging association, 2665 the error MUST be sent back over the same messaging association. 2667 The NSLPID in the common header of the Error message has the value 2668 zero. If for any reason the message cannot be sent, for example, 2669 because it is too large to send in D-mode, an error SHOULD be logged 2670 locally. 2672 5.7. Messaging Association Setup 2674 5.7.1. Overview 2676 A key attribute of GIST is that it is flexible in its ability to use 2677 existing transport and security protocols. Different transport 2678 protocols may have performance attributes appropriate to different 2679 environments; different security protocols may fit appropriately with 2680 different authentication infrastructures. Even given an initial 2681 default mandatory protocol set for GIST, the need to support new 2682 protocols in the future cannot be ruled out, and secure feature 2683 negotiation cannot be added to an existing protocol in a backwards- 2684 compatible way. Therefore, some sort of capability discovery is 2685 required. 2687 Capability discovery is carried out in Query and Response messages, 2688 using Stack-Proposal and Stack-Configuration-Data objects. If a new 2689 messaging association is required it is then set up, followed by a 2690 Confirm. Messaging association multiplexing is achieved by short- 2691 circuiting this exchange by sending the Response or Confirm messages 2692 on an existing association (Section 4.4.3); whether to do this is a 2693 matter of local policy. The end result of this process is a 2694 messaging association which is a stack of protocols. If multiple 2695 associations exist, it is a matter of local policy how to distribute 2696 messages over them, subject to respecting the transfer attributes 2697 requested for each message. 2699 Every possible protocol for a messaging association has the following 2700 attributes: 2702 o MA-Protocol-ID, a 1-byte IANA assigned value (see Section 9). 2704 o A specification of the (non-negotiable) policies about how the 2705 protocol should be used; for example, in which direction a 2706 connection should be opened. 2708 o [Depending on the specific protocol:] Formats for an MA-protocol- 2709 options field to carry the protocol addressing and other 2710 configuration information in the Stack-Configuration-Data object. 2711 The format may differ depending on whether the field is present in 2712 the Query or Response. Some protocols do not require the 2713 definition of such additional data, in which case no corresponding 2714 MA-protocol-options field will occur in the SCD object. 2716 A Stack-Proposal object is simply a list of profiles; each profile is 2717 a sequence of MA-Protocol-IDs. A profile lists the protocols in 'top 2718 to bottom' order (e.g. TLS over TCP). A Stack-Proposal is generally 2719 accompanied by a Stack-Configuration-Data object which carries an MA- 2720 protocol-options field for any protocol listed in the Stack-Proposal 2721 which needs it. An MA-protocol-options field may apply globally, to 2722 all instances of the protocol in the Stack-Proposal; or it can be 2723 tagged as applying to a specific instance. The latter approach can 2724 be used to carry different port numbers for TCP depending on whether 2725 it is to be used with or without TLS. An MA-protocol-options field 2726 may also be flagged as not usable; for example, a NAT which could not 2727 handle SCTP would set this in an MA-protocol-options field about 2728 SCTP. A protocol flagged this way MUST NOT be used for a messaging 2729 association. If the Stack-Proposal and Stack-Configuration-Data are 2730 both present but not consistent, for example, if they refer to 2731 different protocols, or an MA-protocol-options field refers to a non- 2732 existent profile, an "Object Value Error" message (Appendix A.4.4.10) 2733 with subcode 5 ("Stack-Proposal - Stack-Configuration-Data Mismatch") 2734 MUST be returned and the message dropped. 2736 A node generating a Stack-Configuration-Data object MUST honour the 2737 implied protocol configurations for the period during which a 2738 messaging association might be set up; in particular, it MUST be 2739 immediately prepared to accept incoming datagrams or connections at 2740 the protocol/port combinations advertised. This MAY require the 2741 creation of listening endpoints for the transport and security 2742 protocols in question, or a node MAY keep a pool of such endpoints 2743 open for extended periods. However, the received object contents 2744 MUST be retained only for the duration of the Query/Response exchange 2745 and to allow any necessary association setup to complete. They may 2746 become invalid because of expired bindings at intermediate NATs, or 2747 because the advertising node is using agile ports. Once the setup is 2748 complete, or if it is not necessary, or fails for some reason, the 2749 object contents MUST be discarded. A default time of 30 seconds to 2750 keep the contents is RECOMMENDED. 2752 A Query requesting association setup always contains a Stack-Proposal 2753 and Stack-Configuration-Data object. The Stack-Proposal MUST only 2754 include protocol configurations that are suitable for the transfer 2755 attributes of the messages that the Querying node wishes use the 2756 messaging association for. For example, it should not simply include 2757 all configurations that the Querying node is capable of supporting. 2759 The Response always contains a Stack-Proposal and Stack- 2760 Configuration-Data object, unless multiplexing (where the Responder 2761 decides to use an existing association) occurs. For such a Response, 2762 the security protocols listed in the Stack-Proposal MUST NOT depend 2763 on the Query. A node MAY make different proposals depending on the 2764 combination of interface and NSLPID. If multiplexing does occur, 2765 which is indicated by sending the Response over an existing messaging 2766 association, the following rules apply: 2768 o The re-used messaging association MUST NOT have weaker security 2769 properties than all of the options that would have been offered in 2770 the full Response that would have been sent without re-use. 2772 o The re-used messaging association MUST have equivalent or better 2773 transport and security characteristics as at least one of the 2774 protocol configurations that was offered in the Query. 2776 Once the messaging association is set up, the Querying node repeats 2777 the responder's Stack-Proposal over it in the Confirm. The 2778 responding node MUST verify that this has not been changed as part of 2779 bidding-down attack prevention. If a difference is detected, the 2780 responding node MUST terminate the messaging association and SHOULD 2781 log an error condition locally. See Section 8.6 for further 2782 discussion. 2784 5.7.2. Protocol Definition: Forwards-TCP 2786 This MA-Protocol-ID denotes a basic use of TCP between peers. 2787 Support for this protocol is REQUIRED. If this protocol is offered, 2788 MA-protocol-options data MUST also be carried in the SCD object. The 2789 MA-protocol-options field formats are: 2791 o in a Query: no information apart from the field header. 2793 o in a Response: 2 byte port number at which the connection will be 2794 accepted, followed by 2 pad bytes. 2796 The connection is opened in the forwards direction, from the Querying 2797 node towards the responder. The Querying node MAY use any source 2798 address and source port. The destination information MUST be derived 2799 from information in the Response: the address from the interface- 2800 address from the Network-Layer-Information object and the port from 2801 the SCD object as described above. 2803 Associations using Forwards-TCP can carry messages with the transfer 2804 attribute Reliable=True. If an error occurs on the TCP connection 2805 such as a reset, as can be detected for example by a socket exception 2806 condition, GIST MUST report this to NSLPs as discussed in 2807 Section 4.1.2. 2809 5.7.3. Protocol Definition: Transport Layer Security 2811 This MA-Protocol-ID denotes a basic use of transport layer channel 2812 security, initially in conjunction with TCP. Support for this 2813 protocol in conjunction with TCP is REQUIRED; associations using it 2814 can carry messages with transfer attributes requesting 2815 confidentiality or integrity protection. The specific TLS version 2816 will be negotiated within the TLS layer itself, but implementations 2817 MUST NOT negotiate to protocol versions prior to TLS1.0 [16] and MUST 2818 use the highest protocol version supported by both peers. 2819 Implementation of TLS1.1 [13] is RECOMMENDED. GIST nodes supporting 2820 TLS1.0 or TLS1.1 MUST- be able to negotiate the TLS ciphersuite 2821 TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD+ be able to negotiate the 2822 TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. They MAY negotiate any 2823 mutually acceptable ciphersuite that provides authentication, 2824 integrity, and confidentiality. 2826 The default mode of TLS authentication, which applies in particular 2827 to the above ciphersuites, uses a client/server X.509 certificate 2828 exchange. The Querying node acts as a TLS client, and the Responding 2829 node acts as a TLS server. Where one of the above ciphersuites is 2830 negotiated, the GIST node acting as a server MUST provide a 2831 certificate, and MUST request one from the GIST node acting as a TLS 2832 client. This allows either server-only or mutual authentication, 2833 depending on the certificates available to the client and the policy 2834 applied at the server. 2836 GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the 2837 negotiation of alternative ciphersuites is used to trigger 2838 alternative authentication procedures, such as the use of pre-shared 2839 keys [33]. The use of other authentication procedures may require 2840 additional specification work to define how they can be used as part 2841 of TLS within the GIST framework, and may or may not require the 2842 definition of additional MA-Protocol-IDs. 2844 No MA-protocol-options field is required for this TLS protocol 2845 definition. The configuration information for the transport protocol 2846 over which TLS is running (e.g. TCP port number) is provided by the 2847 MA-protocol-options for that protocol. 2849 5.7.3.1. Identity Checking in TLS 2851 After TLS authentication, a node MUST check the identity presented by 2852 the peer in order to avoid man-in-the-middle attacks, and verify that 2853 the peer is authorised to take part in signalling at the GIST layer. 2854 The authorisation check is carried out by comparing the presented 2855 identity with each APD entry in turn, as discussed in Section 4.4.2. 2856 This section defines the identity comparison algorithm for a single 2857 APD entry. 2859 For TLS authentication with X.509 certificates, an identity from the 2860 DNS namespace MUST be checked against each subjectAltName extension 2861 of type dNSName present in the certificate. If no such extension is 2862 present, then the identity MUST be compared to the (most specific) 2863 Common Name in the Subject field of the certificate. When matching 2864 DNS names against dNSName or Common Name fields, matching is case- 2865 insensitive. Also, a "*" wildcard character MAY be used as the left- 2866 most name component in the certificate or identity in the APD. For 2867 example, *.example.com in the APD would match certificates for 2868 a.example.com, foo.example.com, *.example.com, etc., but would not 2869 match example.com. Similarly, a certificate for *.example.com would 2870 be valid for APD identities of a.example.com, foo.example.com, 2871 *.example.com, etc., but not example.com. 2873 Additionally, a node MUST verify the binding between the identity of 2874 the peer to which it connects and the public key presented by that 2875 peer. Nodes SHOULD implement the algorithm in Section 6 of [10] for 2876 general certificate validation, but MAY supplement that algorithm 2877 with other validation methods that achieve equivalent levels of 2878 verification (such as comparing the server certificate against a 2879 local store of already-verified certificates and identity bindings). 2881 For TLS authentication with pre-shared keys, the identity in the 2882 psk_identity_hint (for the server identity, i.e. the Responding node) 2883 or psk_identity (for the client identity, i.e. the Querying node) 2884 MUST be compared to the identities in the APD. 2886 5.8. Specific Message Routing Methods 2888 Each message routing method (see Section 3.3) requires the definition 2889 of the format of the message routing information (MRI) and Q-mode 2890 encapsulation rules. These are given in the following subsections 2891 for the MRMs currently defined. A GIST implementation on a node MUST 2892 support whatever MRMs are required by the NSLPs on that node; GIST 2893 implementations SHOULD provide support for both the MRMs defined 2894 bere, in order to minimise deployment barriers for new signalling 2895 applications that need them. 2897 5.8.1. The Path-Coupled MRM 2899 5.8.1.1. Message Routing Information 2901 For the path-coupled MRM, this is conceptually the Flow Identifier as 2902 in the NSIS Framework [30]. Minimally, this could just be the flow 2903 destination address; however, to account for policy based forwarding 2904 and other issues a more complete set of header fields SHOULD be 2905 specified if possible (see Section 4.3.4 and Section 7.2 for further 2906 discussion). 2908 MRI = network-layer-version 2909 source-address prefix-length 2910 destination-address prefix-length 2911 IP-protocol 2912 diffserv-codepoint 2913 [ flow-label ] 2914 [ ipsec-SPI / L4-ports] 2916 Additional control information defines whether the flow-label, IPsec 2917 Security Parameters Index (SPI), and port information are present, 2918 and whether the IP-protocol and diffserv-codepoint fields should be 2919 interpreted as significant. The source and destination addresses 2920 MUST be real node addresses, but prefix lengths other than 32/128 2921 (for IPv4/6) MAY be used to implement address wildcarding, allowing 2922 the MRI to refer to traffic to or from a wider address range. 2924 The MRI format allows a potentially very large number of different 2925 flag and field combinations. A GIST implementation that cannot 2926 interpret the MRI in a message MUST return an "Object Value Error" 2927 message (Appendix A.4.4.10) with subcodes 1 ("Value Not Supported") 2928 or 2 ("Invalid Flag-Field Combination") and drop the message. 2930 5.8.1.2. Downstream Q-mode Encapsulation 2932 Where the signalling message is travelling in the same ('downstream') 2933 direction as the flow defined by the MRI, the IP addressing for 2934 Q-mode encapsulated messages is as follows. Support for this 2935 encapsulation is REQUIRED. 2937 o The destination IP address MUST be the flow destination address as 2938 given in the MRI of the message payload. 2940 o By default, the source address is the flow source address, again 2941 from the MRI; therefore, the source addressing mode flag in the 2942 common header S=0. This provides the best likelihood that the 2943 message will be correctly routed through any region performing 2944 per-packet policy-based forwarding or load balancing which takes 2945 the source address into account. However, there may be 2946 circumstances where the use of the signalling source address (S=1) 2947 is preferable, such as: 2949 * In order to receive ICMP error messages about the signalling 2950 message, such as unreachable port or address. If these are 2951 delivered to the flow source rather than the signalling source, 2952 it will be very difficult for the querying node to detect that 2953 it is the last GIST node on the path. Another case is where 2954 there is an abnormally low MTU along the path, in which case 2955 the querying node needs to see the ICMP error (recall that 2956 Q-mode packets are sent with DF set). 2958 * In order to receive GIST Error messages where the error message 2959 sender could not interpret the NLI in the original message. 2961 * In order to attempt to run GIST through an unmodified NAT, 2962 which will only process and translate IP addresses in the IP 2963 header (see Section 7.2.1). 2965 Because of these considerations, use of the signalling source 2966 address is allowed as an option, with use based on local policy. 2967 A node SHOULD use the flow source address for initial Query 2968 messages, but SHOULD transition to the signalling source address 2969 for some retransmissions or as a matter of static configuration, 2970 for example if a NAT is known to be in the path out of a certain 2971 interface. The S-flag in the common header tells the message 2972 receiver which option was used. 2974 A router alert option is also included in the IP header. The option 2975 value depends on the NSLP being signalled for. In addition, it is 2976 essential that the Query mimics the actual data flow as closely as 2977 possible, since this is the basis of how the signalling message is 2978 attached to the data path. To this end, GIST SHOULD set the DiffServ 2979 codepoint and (for IPv6) flow label to match the values in the MRI. 2981 A GIST implementation SHOULD apply validation checks to the MRI, to 2982 reject Query messages that are being injected by nodes with no 2983 legitimate interest in the flow being signalled for. In general, if 2984 the GIST node can detect that no flow could arrive over the same 2985 interface as the Query, it MUST be rejected with an appropriate error 2986 message. Such checks apply only to messages with the Q-mode 2987 encapsulation, since only those messages are required to track the 2988 flow path. The main checks are that the IP version should match the 2989 version(s) used on that interface, and that the full range of source 2990 addresses (the source-address masked with its prefix-length) would 2991 pass ingress filtering checks. For these cases, the error message is 2992 "MRI Validation Failure" (Appendix A.4.4.12) with subcodes 1 or 2 2993 ("IP Version Mismatch" or "Ingress Filter Failure") respectively. 2995 5.8.1.3. Upstream Q-mode Encapsulation 2997 In some deployment scenarios it is desirable to set up routing state 2998 in the upstream direction, (i.e. from flow receiver towards the 2999 sender). This could be used to support firewall signalling to 3000 control traffic from an un-cooperative sender, or signalling in 3001 general where the flow sender was not NSIS-capable. This capability 3002 is incorporated into GIST by defining an encapsulation and processing 3003 rules for sending Query messages upstream. 3005 In general, it is not possible to determine the hop-by-hop route 3006 upstream because of asymmetric IP routing. However, in particular 3007 cases, the upstream peer can be discovered with a high degree of 3008 confidence, for example: 3010 o The upstream GIST peer is 1 IP hop away, and can be reached by 3011 tracing back through the interface on which the flow arrives. 3013 o The upstream peer is a border router of a single-homed (stub) 3014 network. 3016 This section defines an upstream Q-mode encapsulation and validation 3017 checks for when it can be used. The functionality to generate 3018 upstream Queries is OPTIONAL, but if received they MUST be processed 3019 in the normal way. No special functionality is needed for this. 3021 It is possible for routing state at a given node, for a specific MRI 3022 and NSLPID, to be created by both an upstream Query exchange 3023 (initiated by the node itself), and a downstream Query exchange 3024 (where the node is the responder). If the SIDs are different, these 3025 items of routing state MUST be considered as independent; if the SIDs 3026 match, the routing state installed by the downstream exchange MUST 3027 take precedence, provided that the downstream Query passed ingress 3028 filtering checks. The rationale for this is that the downstream 3029 Query is in general a more reliable way to install state, since it 3030 directly probes the IP routing infrastructure along the flow path, 3031 whereas use of the upstream Query depends on the correctness of the 3032 Querying node's understanding of the topology. 3034 The details of the encapsulation are as follows: 3036 o The destination address SHOULD be the flow source address as given 3037 in the MRI of the message payload. An implementation with more 3038 detailed knowledge of local IP routing MAY use an alternative 3039 destination address (e.g. the address of its default router). 3041 o The source address SHOULD be the signalling node address, so in 3042 the common header S=1. 3044 o A router alert option is included as in the downstream case. 3046 o The DiffServ codepoint and (for IPv6) flow label MAY be set to 3047 match the values from the MRI as in the downstream case, and the 3048 UDP port selection is also the same. 3050 o The IP layer TTL of the message MUST be set to 255. 3052 The sending GIST implementation SHOULD attempt to send the Query via 3053 the same interface and to the same link layer neighbour from which 3054 the data packets of the flow are arriving. 3056 The receiving GIST node MAY apply validation checks to the message 3057 and MRI, to reject Query messages which have reached a node at which 3058 they can no longer be trusted. In particular, a node SHOULD reject a 3059 message which has been propagated more than one IP hop, with an 3060 "Invalid IP layer TTL" error message (Appendix A.4.4.11). This can 3061 be determined by examining the received IP layer TTL, similar to the 3062 generalised IP TTL security mechanism described in [28]. 3063 Alternatively, receipt of an upstream Query at the flow source MAY be 3064 used to trigger setup of GIST state in the downstream direction. 3065 These restrictions may be relaxed in a future version. 3067 5.8.2. The Loose-End MRM 3069 The Loose-End MRM is used to discover GIST nodes with particular 3070 properties in the direction of a given address, for example to 3071 discover a NAT along the upstream data path as in [35]. 3073 5.8.2.1. Message Routing Information 3075 For the loose-end MRM, only a simplified version of the Flow 3076 Identifier is needed. 3078 MRI = network-layer-version 3079 source-address 3080 destination-address 3082 The source address is the address of the node initiating the 3083 discovery process, for example the node that will be the data 3084 receiver in the NAT discovery case. The destination address is the 3085 address of a node which is expected to be the other side of the node 3086 to be discovered. Additional control information defines the 3087 direction of the message relative to this flow as in the path-coupled 3088 case. 3090 5.8.2.2. Downstream Q-mode Encapsulation 3092 Only one encapsulation is defined for the loose-end MRM; by 3093 convention, this is referred to as the downstream encapsulation, and 3094 is defined as follows: 3096 o The IP destination address MUST be the destination address as 3097 given in the MRI of the message payload. 3099 o By default, the IP source address is the source address, again 3100 from the MRI (S=0). However, the use of the signalling source 3101 address (S=1) is allowed as in the case of the path-coupled MRM. 3103 A router alert option is included in the IP header. The option value 3104 depends on the NSLP being signalled for. There are no special 3105 requirements on the setting of the DiffServ codepoint, IP layer TTL, 3106 or (for IPv6) the flow label. Nor are any special validation checks 3107 applied. 3109 6. Formal Protocol Specification 3111 This section provides a more formal specification of the operation of 3112 GIST processing, in terms of rules for transitions between states of 3113 a set of communicating state machines within a node. The following 3114 description captures only the basic protocol specification; 3115 additional mechanisms can be used by an implementation to accelerate 3116 route change processing, and these are captured in Section 7.1. A 3117 more detailed description of the GIST protocol operation in state 3118 machine syntax can be found in [43]. 3120 Conceptually, GIST processing at a node may be seen in terms of four 3121 types of cooperating state machine: 3123 1. There is a top-level state machine which represents the node 3124 itself (Node-SM). It is responsible for the processing of events 3125 which cannot be directed towards a more specific state machine, 3126 for example, inbound messages for which no routing state 3127 currently exists. This machine exists permanently, and is 3128 responsible for creating per-MRI state machines to manage the 3129 GIST handshake and routing state maintenance procedures. 3131 2. For each flow and signalling direction where the node is 3132 responsible for the creation of routing state, there is an 3133 instance of a Query-Node state machine (Querying-SM). This 3134 machine sends Query and Confirm messages and waits for Responses, 3135 according to the requirements from local API commands or timer 3136 processing, such as message repetition or routing state refresh. 3138 3. For each flow and signalling direction where the node has 3139 accepted the creation of routing state by a peer, there is an 3140 instance of a Responding-Node state machine (Responding-SM). 3141 This machine is responsible for managing the status of the 3142 routing state for that flow. Depending on policy, it MAY be 3143 responsible for [re]transmission of Response messages, or this 3144 MAY be handled by the Node-SM, and a Responding-SM is not even 3145 created for a flow until a properly formatted Confirm has been 3146 accepted. 3148 4. Messaging associations have their own lifecycle, represented by 3149 MA-SM, from when they are first created (in an incomplete state, 3150 listening for an inbound connection or waiting for outbound 3151 connections to complete), to when they are active and available 3152 for use. 3154 Apart from the fact that the various machines can be created and 3155 destroyed by each other, there is almost no interaction between them. 3156 The machines for different flows do not interact; the Querying-SM and 3157 Responding-SM for a single flow and signalling direction do not 3158 interact. That is, the Responding-SM which accepts the creation of 3159 routing state for a flow on one interface has no direct interaction 3160 with the Querying-SM which sets up routing state on the next 3161 interface along the path. This interaction is mediated instead 3162 through the NSLP. 3164 The state machine descriptions use the terminology rx_MMMM, tg_TTTT 3165 and er_EEEE for incoming messages, API/lower layer triggers and error 3166 conditions respectively. The possible events of these types are 3167 given in the table below. In addition, timeout events denoted 3168 to_TTTT may also occur; the various timers are listed independently 3169 for each type of state machine in the following subsections. 3171 +---------------------+---------------------------------------------+ 3172 | Name | Meaning | 3173 +---------------------+---------------------------------------------+ 3174 | rx_Query | A Query has been received. | 3175 | | | 3176 | rx_Response | A Response has been received. | 3177 | | | 3178 | rx_Confirm | A Confirm has been received. | 3179 | | | 3180 | rx_Data | A Data message has been received. | 3181 | | | 3182 | rx_Message | rx_Query||rx_Response||rx_Confirm||rx_Data. | 3183 | | | 3184 | rx_MA-Hello | A MA-Hello message has been received. | 3185 | | | 3186 | tg_NSLPData | A signalling application has requested data | 3187 | | transfer (via API SendMessage). | 3188 | | | 3189 | tg_Connected | The protocol stack for a messaging | 3190 | | association has completed connecting. | 3191 | | | 3192 | tg_RawData | GIST wishes to transfer data over a | 3193 | | particular messaging association. | 3194 | | | 3195 | tg_MAIdle | GIST decides that it is no longer necessary | 3196 | | to keep an MA open for itself. | 3197 | | | 3198 | er_NoRSM | A "No Routing State" error was received. | 3199 | | | 3200 | er_MAConnect | A messaging association protocol failed to | 3201 | | complete a connection. | 3202 | | | 3203 | er_MAFailure | A messaging association failed. | 3204 +---------------------+---------------------------------------------+ 3205 Incoming Events 3207 6.1. Node Processing 3209 The Node level state machine is responsible for processing events for 3210 which no more appropriate messaging association state or routing 3211 state exists. Its structure is trivial: there is a single state 3212 ('Idle'); all events cause a transition back to Idle. Some events 3213 cause the creation of other state machines. The only events that are 3214 processed by this state machine are incoming GIST messages (Query/ 3215 Response/Confirm/Data) and API requests to send data; no other events 3216 are possible. In addition to this event processing, the Node level 3217 machine is responsible for managing listening endpoints for messaging 3218 associations. Although these relate to Responding node operation, 3219 they cannot be handled by the Responder state machine since they are 3220 not created per flow. The processing rules for each event are as 3221 follows: 3223 Rule 1 (rx_Query): 3224 use the GIST service interface to determine the signalling 3225 application policy relating to this peer 3226 // note that this interaction delivers any NSLP-Data to 3227 // the NSLP as a side effect 3228 if (the signalling application indicates that routing state should 3229 be created) then 3230 if (routing state can be created without a 3-way handshake) then 3231 create Responding-SM and transfer control to it 3232 else 3233 send Response with R=1 3234 else 3235 propagate the Query with any updated NSLP payload provided 3237 Rule 2 (rx_Response): 3238 // a routing state error 3239 discard message 3241 Rule 3 (rx_Confirm): 3242 if (routing state can be created before receiving a Confirm) then 3243 // we should already have Responding-SM for it, 3244 // which would handle this message 3245 discard message 3246 send "No Routing State" error message 3247 else 3248 create Responding-SM and pass message to it 3250 Rule 4 (rx_Data): 3251 if (node policy will only process Data messages with matching 3252 routing state) then 3253 send "No Routing State" error message 3254 else 3255 pass directly to NSLP 3257 Rule 4 (er_NoRSM): 3258 discard the message 3260 Rle 5 (tg_NSLPData): 3261 if Q-mode encapsulation is not possible for this MRI 3262 reject message with an error 3263 else 3264 if (local policy & transfer attributes say routing 3265 state is not needed) then 3266 send message statelessly 3267 else 3268 create Querying-SM and pass message to it 3270 6.2. Query Node Processing 3272 The Querying-Node state machine (Querying-SM) has three states: 3274 o Awaiting Response 3276 o Established 3278 o Awaiting Refresh 3280 The Querying-SM is created by the Node-SM machine as a result of a 3281 request to send a message for a flow in a signalling direction where 3282 the appropriate state does not exist. The Query is generated 3283 immediately and the No_Response timer is started. The NSLP data MAY 3284 be carried in the Query if local policy and the transfer attributes 3285 allow it, otherwise it MUST be queued locally pending MA 3286 establishment. Then the machine transitions to the Awaiting Response 3287 state, in which timeout-based retransmissions are handled. Data 3288 messages (rx_Data events) should not occur in this state; if they do, 3289 this may indicate a lost Response and a node MAY also retransmit a 3290 Query for this reason. 3292 Once a Response has been successfully received and routing state 3293 created, the machine transitions to Established, during which NSLP 3294 data can be sent and received normally. Further Responses received 3295 in this state (which may be the result of a lost Confirm) MUST be 3296 treated the same way. The Awaiting Refresh state can be considered 3297 as a substate of Established, where a new Query has been generated to 3298 refresh the routing state (as in Awaiting Response) but NSLP data can 3299 be handled normally. 3301 The timers relevant to this state machine are as follows: 3303 Refresh_QNode: Indicates when the routing state stored by this state 3304 machine must be refreshed. It is reset whenever a Response is 3305 received indicating that the routing state is still valid. 3306 Implementations MUST set the period of this timer based on the 3307 value in the RS-validity-time field of a Response to ensure that a 3308 Query is generated before the peer's routing state expires. 3310 No_Response: Indicates that a Response has not been received in 3311 answer to a Query. This is started whenever a Query is sent and 3312 stopped when a Response is received. 3314 Inactive_QNode: Indicates that no traffic is currently being handled 3315 by this state machine. This is reset whenever the state machine 3316 handles NSLP data, in either direction. When it expires, the 3317 state machine MAY be deleted. The period of the timer can be set 3318 at any time via the API (SetStateLifetime), and if the period is 3319 reset in this way the timer itself MUST be restarted. 3321 The main events (including all those that cause state transitions) 3322 are shown in the figure below, tagged with the number of the 3323 processing rule that is used to handle the event. These rules are 3324 listed after the diagram. All events not shown or described in the 3325 text above are assumed to be impossible in a correct implementation 3326 and MUST be ignored. 3328 [Initialisation] +-----+ 3329 -------------------------|Birth| 3330 | +-----+ 3331 | er_NoRSM[3](from all states) rx_Response[4] 3332 | || tg_NSLPData[5] 3333 | tg_NSLPData[1] || rx_Data[7] 3334 | -------- ------- 3335 | | V | V 3336 | | V | V 3337 | +----------+ +-----------+ 3338 ---->>| Awaiting | |Established| 3339 ------| Response |---------------------------->> | | 3340 | +----------+ rx_Response[4] +-----------+ 3341 | ^ | ^ | 3342 | ^ | ^ | 3343 | -------- | | 3344 | to_No_Response[2] | | 3345 | [!nResp_reached] tg_NSLPData[5] | | 3346 | || rx_Data[7] | | 3347 | -------- | | 3348 | | V | | 3349 | to_No_Response[2] | V | | 3350 | [nResp_reached] +-----------+ rx_Response[4] | | 3351 ---------- -----------| Awaiting |----------------- | 3352 | | | Refresh |<<------------------- 3353 | | +-----------+ to_Refresh_QNode[8] 3354 | | ^ | 3355 V V ^ | to_No_Response[2] 3356 V V -------- [!nResp_reached] 3357 +-----+ 3358 |Death|<<--------------- 3359 +-----+ to_Inactive_QNode[6] 3360 (from all states) 3362 Figure 5: Query Node State Machine 3364 The processing rules are as follows: 3366 Rule 1: Store the message for later transmission 3368 Rule 2: 3369 if number of Queries sent has reached the threshold 3370 // nQuery_isMax is true 3371 indicate No Response error to NSLP 3372 destroy self 3373 else 3374 send Query 3375 start No_Response timer with new value 3377 Rule 3: 3378 // Assume the Confirm was lost in transit or the peer has reset; 3379 // restart the handshake 3380 send Query 3381 start No_Response timer 3383 Rule 4: 3384 if a new MA-SM is needed create one 3385 if the R flag was set send a Confirm 3386 pass any NSLP-Data object to the NSLP 3387 send any stored Data messages 3388 stop No_Response timer 3389 start Refresh_QNode and (re)start Inactive_QNode timers 3391 Rule 5: 3392 send Data message 3393 restart Inactive_QNode timer 3395 Rule 6: Terminate 3397 Rule 7: 3398 pass any data to the NSLP 3399 restart Inactive_QNode timer 3401 Rule 8: 3402 send Query 3403 start No_Response timer 3404 stop Refresh_QNode timer 3406 6.3. Responder Node Processing 3408 The Responding-Node state machine (Responding-SM) has three states: 3410 o Awaiting Confirm 3412 o Established 3414 o Awaiting Refresh 3416 The policy governing the handling of Query messages and the creation 3417 of the Responding-SM has three cases: 3419 1. No Confirm is required for a Query, and the state machine can be 3420 created immediately. 3422 2. A Confirm is required for a Query, but the state machine can 3423 still be created immediately. A timer is used to retransmit 3424 Response messages and the Responding-SM is destroyed if no valid 3425 Confirm is received. 3427 3. A Confirm is required for a Query, and the state machine can only 3428 be created when it is received; the initial Query will have been 3429 handled by the Node level machine. 3431 In case 2 the Responding-SM is created in the Awaiting Confirm state, 3432 and remains there until a Confirm is received, at which point it 3433 transitions to Established. In cases 1 and 3 the Responding-SM is 3434 created directly in the Established state. Note that if the machine 3435 is created on receiving a Query, some of the message processing will 3436 already have been performed in the Node state machine. In principle, 3437 an implementation MAY change its policy on handling a Query message 3438 at any time; however, the state machine descriptions here cover only 3439 the case where the policy is fixed while waiting for a Confirm 3440 message. 3442 In the Established state the NSLP can send and receive data normally, 3443 and any additional rx_Confirm events MUST be silently ignored. The 3444 Awaiting Refresh state can be considered a substate of Established, 3445 where a Query has been received to begin the routing state refresh. 3446 In the Awaiting Refresh state the Responding-SM behaves as in the 3447 Awaiting Confirm state, except that the NSLP can still send and 3448 receive data. In particular, in both states there is timer-based 3449 retransmission of Response messages until a Confirm is received; 3450 additional rx_Query events in these states MUST also generate a reply 3451 and restart the no_Confirm timer. 3453 The timers relevant to the operation of this state machine are as 3454 follows: 3456 Expire_RNode: Indicates when the routing state stored by this state 3457 machine needs to be expired. It is reset whenever a Query or 3458 Confirm (depending on local policy) is received indicating that 3459 the routing state is still valid. Note that state cannot be 3460 refreshed from the R-Node. 3462 No_Confirm: Indicates that a Confirm has not been received in answer 3463 to a Response. This is started/reset whenever a Response is sent 3464 and stopped when a Confirm is received. 3466 The detailed state transitions and processing rules are described 3467 below as in the Query node case. 3469 rx_Query[1] rx_Query[5] 3470 [confirmRequired] +-----+ [!confirmRequired] 3471 -------------------------|Birth|---------------------------- 3472 | +-----+ | 3473 | | rx_Confirm[2] | 3474 | ---------------------------- | 3475 | | | 3476 | rx_Query[5] | | 3477 | tg_NSLPData[7] || rx_Confirm[10] | | 3478 | || rx_Query[1] || rx_Data[4] | | 3479 | || rx_Data[6] || tg_NSLPData[3] | | 3480 | -------- -------------- | | 3481 | | V | V V V 3482 | | V | V V V 3483 | +----------+ | +-----------+ 3484 ---->>| Awaiting | rx_Confirm[8] -----------|Established| 3485 ------| Confirm |------------------------------>> | | 3486 | +----------+ +-----------+ 3487 | ^ | ^ | 3488 | ^ | tg_NSLPData[3] ^ | 3489 | -------- || rx_Query[1] | | 3490 | to_No_Confirm[9] || rx_Data[4] | | 3491 | [!nConf_reached] -------- | | 3492 | | V | | 3493 | to_No_Confirm[9] | V | | 3494 | [nConf_reached] +-----------+ rx_Confirm[8] | | 3495 ---------- ------------| Awaiting |----------------- | 3496 | | | Refresh |<<------------------- 3497 | | +-----------+ rx_Query[1] 3498 | | ^ | [confirmRequired] 3499 | | ^ | 3500 | | -------- 3501 V V to_No_Confirm[9] 3502 V V [!nConf_reached] 3503 +-----+ 3504 |Death|<<--------------------- 3505 +-----+ er_NoRSM[11] 3506 to_Expire_RNode[11] 3507 (from Established/Awaiting Refresh) 3509 Figure 6: Responder Node State Machine 3511 The processing rules are as follows: 3513 Rule 1: 3514 // a Confirm is required 3515 send Response with R=1 3516 (re)start No_Confirm timer 3517 Rule 2: 3518 pass any NSLP-Data object to the NSLP 3519 start Expire_RNode timer 3521 Rule 3: send the Data message 3523 Rule 4: pass data to NSLP 3525 Rule 5: 3526 // no Confirm is required 3527 send Response with R=0 3528 start Expire_RNode timer 3530 Rule 6: send "No Routing State" error message 3532 Rule 7: store Data message 3534 Rule 8: 3535 pass any NSLP-Data object to the NSLP 3536 send any stored Data messages 3537 stop No_Confirm timer 3538 start Expire_RNode timer 3540 Rule 9: 3541 if number of Responses sent has reached threshold 3542 // nResp_isMax is true 3543 destroy self 3544 else 3545 send Response 3546 start No_Response timer 3548 Rule 10: 3549 // can happen e.g. a retransmitted Response causes a duplicate Confirm 3550 silently ignore 3552 Rule 11: destroy self 3554 6.4. Messaging Association Processing 3556 Messaging associations (MAs) are modelled for use within GIST with a 3557 simple three-state process. The Awaiting Connection state indicates 3558 that the MA is waiting for the connection process(es) for every 3559 protocol in the messaging association to complete; this might involve 3560 creating listening endpoints or attempting active connects. Timers 3561 may also be necessary to detect connection failure (e.g. no incoming 3562 connection within a certain period), but these are not modelled 3563 explicitly. 3565 The Connected state indicates that the MA is open and ready to use, 3566 and that the node wishes it to remain open. In this state, the node 3567 operates a timer (SendHello) to ensure that messages are regularly 3568 sent to the peer, to ensure that the peer does not tear the MA down. 3569 The node transitions from Connected to Idle (indicating that it no 3570 longer needs the association) as a matter of local policy; one way to 3571 manage the policy is to use an activity timer but this is not 3572 specified explicitly by the state machine (see also Section 4.4.5). 3574 In the Idle state, the node no longer requires the messaging 3575 association but the peer still requires it and is indicating this by 3576 sending periodic MA-Hello messages. A different timer (NoHello) 3577 operates to purge the MA when these messages stop arriving. If real 3578 data is transferred over the MA, the state machine transitions back 3579 to Connected. 3581 At any time in the Connected or Idle states, a node MAY test the 3582 connectivity to its peer and the liveness of the GIST instance at 3583 that peer by sending a MA-Hello request with R=1. Failure to receive 3584 a reply with a matching Hello-ID within a timeout MAY be taken as a 3585 reason to trigger er_MAFailure. Initiation of such a test and the 3586 timeout setting are left to the discretion of the implementaion. 3587 Note that er_MAFailure may also be signalled by indications from the 3588 underlying messaging association protocols. If a messaging 3589 association fails, this MUST be indicated back to the routing state 3590 machines which use it, and these MAY generate indications to 3591 signalling applications. In particular, if the messaging association 3592 was being used to deliver messages reliably, this MUST be reported as 3593 a NetworkNotification error (Appendix B.4). 3595 Clearly, many internal details of the messaging association protocols 3596 are hidden in this model, especially where the messaging association 3597 uses multiple protocol layers. Note also that although the existence 3598 of messaging associations is not directly visible to signalling 3599 applications, there is some interaction between the two because 3600 security-related information becomes available during the open 3601 process, and this may be indicated to signalling applications if they 3602 have requested it. 3604 The timers relevant to the operation of this state machine are as 3605 follows: 3607 SendHello: Indicates that an MA-Hello message should be sent to the 3608 remote node. The period of this timer is determined by the MA- 3609 Hold-Time sent by the remote node during the Query/Response/ 3610 Confirm exchange. 3612 NoHello: Indicates that no MA-Hello has been received from the 3613 remote node for a period of time. The period of this timer is 3614 sent to the remote node as the MA-Hold-Time during the Query/ 3615 Response exchange. 3617 The detailed state transitions and processing rules are described 3618 below as in the Query node case. 3619 [Initialisation] +-----+ 3620 ----------------------------|Birth| 3621 | +-----+ tg_RawData[1] 3622 | || rx_Message[2] 3623 | || rx_MA-Hello[3] 3624 | tg_RawData[5] || to_SendHello[4] 3625 | -------- -------- 3626 | | V | V 3627 | | V | V 3628 | +----------+ +-----------+ 3629 ---->>| Awaiting | tg_Connected[6] | Connected | 3630 ------|Connection|----------------------->>| | 3631 | +----------+ +-----------+ 3632 | ^ | 3633 | tg_RawData[1] ^ | 3634 | || rx_Message[2] | | tg_MAIdle[7] 3635 | | V 3636 | | V 3637 | er_MAConnect[8] +-----+ to_NoHello[8] +-----------+ 3638 ---------------->>|Death|<<----------------| Idle | 3639 +-----+ +-----------+ 3640 ^ ^ | 3641 ^ ^ | 3642 --------------- -------- 3643 er_MAFailure[8] rx_MA-Hello[9] 3644 (from Connected/Idle) 3646 Figure 7: Messaging Association State Machine 3648 The processing rules are as follows: 3650 Rule 1: 3651 pass message to transport layer 3652 if the NoHello timer was running, stop it 3653 (re)start SendHello 3655 Rule 2: 3656 pass message to Node-SM 3657 if the NoHello timer was running, stop it 3658 Rule 3: 3659 if reply requested 3660 send MA-Hello 3661 restart SendHello timer 3663 Rule 4: 3664 send MA-Hello message 3665 restart SendHello timer 3667 Rule 5: queue message for later transmission 3669 Rule 6: 3670 pass outstanding queued messages to transport layer 3671 stop any timers controlling connection establishment 3672 start SendHello timer 3674 Rule 7: 3675 stop SendHello timer 3676 start NoHello timer 3678 Rule 8: 3679 report failure to routing state machines and signalling applications 3680 destroy self 3682 Rule 9: 3683 if reply requested 3684 send MA-Hello 3685 restart NoHello timer 3687 7. Additional Protocol Features 3689 7.1. Route Changes and Local Repair 3691 7.1.1. Introduction 3693 When IP layer re-routing takes place in the network, GIST and 3694 signalling application state need to be updated for all flows whose 3695 paths have changed. The updates to signalling application state 3696 depend mainly on the signalling application: for example, if the path 3697 characteristics have actually changed, simply moving state from the 3698 old to the new path is not sufficient. Therefore, GIST cannot carry 3699 out the complete path update processing. Its responsibilities are to 3700 detect the route change, update its local routing state consistently, 3701 and inform interested signalling applications at affected nodes. 3703 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 3704 x +--+ +--+ +--+ x Initial 3705 x .|C1|_.....|D1|_.....|E1| x Configuration 3706 x . +--+. .+--+. .+--+\. x 3707 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 3708 +-+ +-+ . .. .. . +-+ 3709 ...|A|_......|B|/ .. .. .|F|_.... 3710 +-+ +-+ . . . . . . +-+ 3711 . . . . . . 3712 . +--+ +--+ +--+ . 3713 .|C2|_.....|D2|_.....|E2|/ 3714 +--+ +--+ +--+ 3716 +--+ +--+ +--+ Configuration 3717 .|C1|......|D1|......|E1| after failure 3718 . +--+ .+--+ +--+ of E1-F link 3719 . \. . \. ./ 3720 +-+ +-+ . .. .. +-+ 3721 ...|A|_......|B|. .. .. .|F|_.... 3722 +-+ +-+\ . . . . . +-+ 3723 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 3724 x . +--+ +--+ +--+ . x 3725 x .|C2|_.....|D2|_.....|E2|/ x 3726 x +--+ +--+ +--+ x 3727 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 3729 ........... = physical link topology 3730 >>xxxxxxx>> = flow direction 3731 _.......... = outgoing link for flow xxxxxx given 3732 by local forwarding table 3734 Figure 8: A Re-Routing Event 3736 Route change management is complicated by the distributed nature of 3737 the problem. Consider the re-routing event shown in Figure 8. An 3738 external observer can tell that the main responsibility for 3739 controlling the updates will probably lie with nodes B and F; 3740 however, E1 is best placed to detect the event quickly at the GIST 3741 level, and C1 and D1 could also attempt to initiate the repair. 3743 The NSIS framework [30] makes the assumption that signalling 3744 applications are soft-state based and operate end to end. In this 3745 case, because GIST also periodically updates its picture of routing 3746 state, route changes will eventually be repaired automatically. The 3747 specification as already given includes this functionality. However, 3748 especially if upper layer refresh times are extended to reduce 3749 signalling load, the duration of inconsistent state may be very long 3750 indeed. Therefore, GIST includes logic to exchange prompt 3751 notifications with signalling applications, to allow local repair if 3752 possible. The additional mechanisms to achieve this are described in 3753 the following subsections. To a large extent, these additions can be 3754 seen as implementation issues; the protocol messages and their 3755 significance are not changed, but there are extra interactions 3756 through the API between GIST and signalling applications, and 3757 additional triggers for transitions between the various GIST states. 3759 7.1.2. Route Change Detection Mechanisms 3761 There are two aspects to detecting a route change at a single node: 3763 o Detecting that the outgoing path, in the direction of the Query, 3764 has or may have changed. 3766 o Detecting that the incoming path, in the direction of the 3767 Response, has (or may have) changed, in which case the node may no 3768 longer be on the path at all. 3770 At a single node, these processes are largely independent, although 3771 clearly a change in one direction at a node corresponds to a change 3772 the opposite direction at its peer. Note that there are two possible 3773 forms for a route change: the interface through which a flow leaves 3774 or enters a node may change, and the adjacent peer may change. In 3775 general, a route change can include one or the other or both (or 3776 indeed neither, although such changes are very hard to detect). 3778 The route change detection mechanisms available to a node depend on 3779 the MRM in use and the role the node played in setting up the routing 3780 state in the first place (i.e. as Querying or Responding node). The 3781 following discussion is specific to the case of the path-coupled MRM 3782 using downstream Queries only; other scenarios may require other 3783 methods. However, the repair logic described in the subsequent 3784 subsections is intended to be universal. 3786 There are five mechanisms for a node to detect that a route change 3787 has occurred, which are listed below. They apply differently 3788 depending on whether the change is in the Query or Response 3789 direction, and these differences are summarised in the following 3790 table. 3792 Local Trigger: In local trigger mode, GIST finds out from the local 3793 forwarding table that the next hop has changed. This only works 3794 if the routing change is local, not if it happens a few IP routing 3795 hops away, including the case that it happens at a GIST-unaware 3796 node. 3798 Extended Trigger: Here, GIST checks a link-state topology database 3799 to discover that the path has changed. This makes certain 3800 assumptions on consistency of IP route computation and only works 3801 within a single area for OSPF [17] and similar link-state 3802 protocols. Where available, this offers the most accurate and 3803 rapid indication of route changes, but requires more access to the 3804 routing internals than a typical operating system may provide. 3806 GIST C-mode Monitoring: GIST may find that C-mode packets are 3807 arriving (from either peer) with a different IP layer TTL or on a 3808 different interface. This provides no direct information about 3809 the new flow path, but indicates that routing has changed and that 3810 rediscovery may be required. 3812 Data Plane Monitoring: The signalling application on a node may 3813 detect a change in behaviour of the flow, such as IP layer TTL 3814 change, arrival on a different interface, or loss of the flow 3815 altogether. The signalling application on the node is allowed to 3816 notify this information locally to GIST (Appendix B.6). 3818 GIST Probing: According to the specification, each GIST node MUST 3819 periodically repeat the discovery (Query/Response) operation. 3820 Values for the probe frequency are discussed in Section 4.4.4. 3821 The querying node will discover the route change by a modification 3822 in the Network-Layer-Information in the Response. The period can 3823 be negotiated independently for each GIST hop, so nodes that have 3824 access to the other techniques listed above MAY use long periods 3825 for the probing operation. 3827 +-------------+--------------------------+--------------------------+ 3828 | Method | Query direction | Response direction | 3829 +-------------+--------------------------+--------------------------+ 3830 | Local | Discovers new interface | Not applicable | 3831 | Trigger | (and peer if local) | | 3832 | | | | 3833 | Extended | Discovers new interface | May determine that route | 3834 | Trigger | and may determine new | from peer will have | 3835 | | peer | changed | 3836 | | | | 3837 | C-mode | Provides hint that | Provides hint that | 3838 | Monitoring | change has occurred | change has occurred | 3839 | | | | 3840 | Data Plane | Not applicable | NSLP informs GIST that a | 3841 | Monitoring | | change may have occurred | 3842 | | | | 3843 | Probing | Discovers changed NLI in | Discovers changed NLI in | 3844 | | Response | Query | 3845 +-------------+--------------------------+--------------------------+ 3847 7.1.3. GIST Behaviour Supporting Re-Routing 3849 The basic GIST behaviour necessary to support re-routing can be 3850 modelled using a 3-level classification of the validity of each item 3851 of current routing state. (In addition to current routing state, 3852 NSIS can maintain past routing state, described in Section 7.1.4 3853 below.) This classification applies separately to the Querying and 3854 Responding node for each pair of GIST peers. The levels are: 3856 Bad: The routing state is either missing altogether, or not safe to 3857 use to send data. 3859 Tentative: The routing state may have changed, but it is still 3860 usable for sending NSLP data pending verification. 3862 Good: The routing state has been established and no events affecting 3863 it have since been detected. 3865 These classifications are not identical to the states described in 3866 Section 6, but there are dependencies between them. Specifically, 3867 routing state is considered Bad until the machine first enters the 3868 Established state, at which point it becomes Good. Thereafter, the 3869 status may be invalidated for any of the reasons discussed above; it 3870 is an implementation issue to decide which techniques to implement in 3871 any given node, and how to reclassify routing state (as Bad or 3872 Tentative) for each. The status returns to Good, either when the 3873 state machine re-enters the Established state, or if GIST can 3874 determine from direct examination of the IP routing or forwarding 3875 tables that the peer has not changed. When the status returns to 3876 Good, GIST MUST if necessary update its routing state table so that 3877 the relationships between MRI/SID/NSLPID tuples and messaging 3878 associations are up to date. 3880 When classification of the routing state for the downstream direction 3881 changes to Bad/Tentative because of local IP routing indications, 3882 GIST MAY automatically change the classification in the upstream 3883 direction to Tentative unless local routing indicates that this is 3884 not necessary. This SHOULD NOT be done in the case where the initial 3885 change was indicated by the signalling application. This mechanism 3886 accounts for the fact that a routing change may affect several nodes, 3887 and so can be an indication that upstream routing may also have 3888 changed. In any case, whenever GIST updates the routing status, it 3889 informs the signalling application with the NetworkNotification API 3890 (Appendix B.4), unless the change was caused via the API in the first 3891 place. 3893 The GIST behaviour for state repair is different for the Querying and 3894 Responding node. At the Responding node, there is no additional 3895 behaviour, since the Responding node cannot initiate protocol 3896 transitions autonomously, it can only react to the Querying node. 3897 The Querying node has three options, depending on how the transition 3898 from 'Good' was initially caused: 3900 1. To inspect the IP routing/forwarding table and verifying that the 3901 next peer has not changed. This technique MUST NOT be used if 3902 the transition was caused by a signalling application, but SHOULD 3903 be used otherwise if available. 3905 2. To move to the 'Awaiting Refresh' state. This technique MUST NOT 3906 be used if the current status is 'Bad', since data is being 3907 incorrectly delivered. 3909 3. To move to the 'Awaiting Response' state. This technique may be 3910 used at any time, but has the effect of freezing NSLP 3911 communication while GIST state is being repaired. 3913 The second and third techniques trigger the execution of a GIST 3914 handshake to carry out the repair. It may be desirable to delay the 3915 start of the handshake process, either to wait for the network to 3916 stabilise, to avoid flooding the network with Query traffic for a 3917 large number of affected flows, or to wait for confirmation that the 3918 node is still on the path from the upstream peer. One approach is to 3919 delay the handshake until there is NSLP data to be transmitted. 3920 Implementation of such delays is a matter of local policy; however, 3921 GIST MUST begin the handshake immediately if the status change was 3922 caused by an InvalidateRoutingState API call marked as 'Urgent', and 3923 SHOULD begin it if the upstream routing state is still known to be 3924 Good. 3926 7.1.4. Load Splitting and Route Flapping 3928 The Q-mode encapsulation rules of Section 5.8 try to ensure that the 3929 Query messages discovering the path mimic the flow as accurately as 3930 possible. However, in environments where there is load balancing 3931 over multiple routes, and this is based on header fields differing 3932 between flow and Q-mode packets or done on a round-robin basis, the 3933 path discovered by the Query may vary from one handshake to the next 3934 even though the underlying network is stable. This will appear to 3935 GIST as a route flap; route flapping can also be caused by problems 3936 in the basic network connectivity or routing protocol operation. For 3937 example, a mobile node might be switching back and forth between two 3938 links, or might appear to have disappeared even though it is still 3939 attached to the network via a different route. 3941 This specification does not define mechanisms for GIST to manage 3942 multiple parallel routes or an unstable route; instead, GIST MAY 3943 expose this to the NSLP, which can then manage it according to 3944 signalling application requirements. The algorithms already 3945 described always maintain the concept of the current route, i.e. the 3946 latest peer discovered for a particular flow. Instead, GIST allows 3947 the use of prior signalling paths for some period while the 3948 signalling applications still need them. Since NSLP peers are a 3949 single GIST hop apart, the necessary information to represent a path 3950 can be just an entry in the node's routing state table for that flow 3951 (more generally, anything that uniquely identifies the peer, such as 3952 the NLI, could be used). Rather than requiring GIST to maintain 3953 multiple generations of this information, it is provided to the 3954 signalling application in the same node in an opaque form for each 3955 message that is received from the peer. The signalling application 3956 can store it if necessary and provide it back to the GIST layer in 3957 case it needs to be used. Because this is a reference to information 3958 about the source of a prior signalling message, it is denoted 'SII- 3959 Handle' (for Source Identification Information) in the abstract API 3960 of Appendix B. 3962 Note that GIST if possible SHOULD use the same SII-Handle for 3963 multiple sessions to the same peer, since this then allows signalling 3964 applications to aggregate some signalling, such as summary refreshes 3965 or bulk teardowns. Messages sent using the SII-Handle MUST bypass 3966 the routing state tables at the sender, and this MUST be indicated by 3967 setting the E flag in the common header (Appendix A.1). Messages 3968 other than Data messages MUST NOT be sent in this way. At the 3969 receiver, GIST MUST NOT validate the MRI/SID/NSLPID against local 3970 routing state and instead indicates the mode of reception to 3971 signalling applications through the API (Appendix B.2). Signalling 3972 applications should validate the source and effect of the message 3973 themselves, and if appropriate should in particular indicate to GIST 3974 (see Appendix B.5) that routing state is no longer required for this 3975 flow. This is necessary to prevent GIST in nodes on the old path 3976 initiating routing state refresh and thus causing state conflicts at 3977 the crossover router. 3979 GIST notifies signalling applications about route modifications as 3980 two types of event, additions and deletions. An addition is notified 3981 as a change of the current routing state according to the Bad/ 3982 Tentative/Good classification above, while deletion is expressed as a 3983 statement that an SII handle no longer lies on the path. Both can be 3984 reported through the NetworkNotification API call (Appendix B.4). A 3985 minimal implementation MAY notify a route change as a single (add, 3986 delete) operation; however, a more sophisticated implementation MAY 3987 delay the delete notification, for example if it knows that the old 3988 route continues to be used in parallel, or that the true route is 3989 flapping between the two. It is then a matter of signalling 3990 application design whether to tear down state on the old path, leave 3991 it unchanged, or modify it in some signalling application specific 3992 way to reflect the fact that multiple paths are operating in 3993 parallel. 3995 7.1.5. Signalling Application Operation 3997 Signalling applications can use these functions as provided by GIST 3998 to carry out rapid local repair following re-routing events. The 3999 signalling application instances carry out the multi-hop aspects of 4000 the procedure, including crossover node detection, and tear-down/ 4001 reinstallation of signalling application state; they also trigger 4002 GIST to carry out the local routing state maintenance operations over 4003 each individual hop. The local repair procedures depend heavily on 4004 the fact that stateful NSLP nodes are a single GIST hop apart; this 4005 is enforced by the details of the GIST peer discovery process. 4007 The following outline description of a possible set of NSLP actions 4008 takes the scenario of Figure 8 as an example. 4010 1. The signalling application at node E1 is notified by GIST of 4011 route changes affecting the downstream and upstream directions. 4012 The downstream status was updated to Bad because of a trigger 4013 from the local forwarding tables, and the upstream status changed 4014 automatically to Tentative as a consequence. The signalling 4015 application at E1 MAY begin local repair immediately, or MAY 4016 propagate a notification upstream to D1 that re-routing has 4017 occurred. 4019 2. The signalling application at node D1 is notified of the route 4020 change, either by signalling application notifications or from 4021 the GIST level (e.g. by a trigger from a link-state topology 4022 database). If the information propagates faster within the IP 4023 routing protocol, GIST will change the upstream/downstream 4024 routing state to Tentative/Bad automatically, and this will cause 4025 the signalling application to propagate the notification further 4026 upstream. 4028 3. This process continues until the notification reaches node A. 4029 Here, there is no downstream routing change, so GIST only learns 4030 of the update via the signalling application trigger. Since the 4031 upstream status is still Good, it therefore begins the repair 4032 handshake immediately. 4034 4. The handshake initiated by node A causes its downstream routing 4035 state to be confirmed as Good and unchanged there; it also 4036 confirms the (Tentative) upstream routing state at B as Good. 4037 This is enough to identify B as the crossover router, and the 4038 signalling application and GIST can begin the local repair 4039 process. 4041 An alternative way to reach step (4) is that node B is able to 4042 determine autonomously that there is no likelihood of an upstream 4043 route change. For example, it could be an area border router and the 4044 route change is only intra-area. In this case, the signalling 4045 application and GIST will see that the upstream state is Good and can 4046 begin the local repair directly. 4048 After a route deletion, a signalling application may wish to remove 4049 state at another node which is no longer on the path. However, since 4050 it is no longer on the path, in principle GIST can no longer send 4051 messages to it. In general, provided this state is soft, it will 4052 time out anyway; however, the timeouts involved may have been set to 4053 be very long to reduce signalling load. Instead, signalling 4054 applications MAY use the SII-Handle described above to route explicit 4055 teardown messages. 4057 7.2. NAT Traversal 4059 GIST messages, for example for the path-coupled MRM, must carry 4060 addressing and higher layer information as payload data in order to 4061 define the flow signalled for. (This applies to all GIST messages, 4062 regardless of how they are encapsulated or which direction they are 4063 travelling in.) At an addressing boundary the data flow packets will 4064 have their headers translated; if the signalling payloads are not 4065 translated consistently, the signalling messages will refer to 4066 incorrect (and probably meaningless) flows after passing through the 4067 boundary. In addition, GIST handshake messages carry additional 4068 addressing information about the GIST nodes themselves, and this must 4069 also be processed appropriately when traversing a NAT. 4071 There is a dual problem of whether the GIST peers either side of the 4072 boundary can work out how to address each other, and whether they can 4073 work out what translation to apply to the signalling packet payloads. 4074 Existing generic NAT traversal techniques such as STUN [26] or TURN 4075 [27] can operate only on the two addresses visible in the IP header. 4076 It is therefore intrinsically difficult to use these techniques to 4077 discover a consistent translation of the three or four interdependent 4078 addresses for the flow and signalling source and destination. 4080 For legacy NATs and MRMs that carry addressing information, the base 4081 GIST specification is therefore limited to detecting the situation 4082 and triggering the appropriate error conditions to terminate the 4083 signalling path. (MRMs that do not contain addressing information 4084 could traverse such NATs safely, with some modifications to the GIST 4085 processing rules. Such modifications could be described in the 4086 documents defining such MRMs.) Legacy NAT handling is covered in 4087 Section 7.2.1 below. A more general solution can be constructed 4088 using GIST-awareness in the NATs themselves; this solution is 4089 outlined in Section 7.2.2 with processing rules in Section 7.2.3. 4091 In all cases, GIST interaction with the NAT is determined by the way 4092 the NAT handles the Query/Response messages in the initial GIST 4093 handshake; these messages are UDP datagrams. Best current practice 4094 for NAT treatment of UDP traffic is defined in [39], and the legacy 4095 NAT handling defined in this specification is fully consistent with 4096 that document. The GIST-aware NAT traversal technique is equivalent 4097 to requiring an Application Layer Gateway in the NAT for a specific 4098 class of UDP transactions, namely those where the destination UDP 4099 port for the initial message is the GIST port (see Section 9). 4101 7.2.1. Legacy NAT Handling 4103 Legacy NAT detection during the GIST handshake depends on analysis of 4104 the IP header and S flag in the GIST common header, and the NLI 4105 object included in the handshake messages. The message sequence 4106 proceeds differently depending on whether the Querying node is on the 4107 internal or external side of the NAT. 4109 For the case of the Querying node on the internal side of the NAT, if 4110 the S flag is not set in the Query (S=0), a legacy NAT cannot be 4111 detected. The receiver will generate a normal Response to the 4112 interface-address given in the NLI in the Query, but the interface- 4113 address will not be routable and the Response will not be delivered. 4114 If retransmitted Queries keep S=0, this behaviour will persist until 4115 the Querying node times out. The signalling path will thus terminate 4116 at this point, not traversing the NAT. 4118 The situation changes once S=1 in a Query; note the Q-mode 4119 encapsulation rules recommend that S=1 is used at least for some 4120 retransmissions (see Section 5.8). If S=1, the receiver MUST check 4121 the source address in the IP header against the interface-address in 4122 the NLI, and if these addresses do not match this indicates that a 4123 legacy NAT has been found. For MRMs which contain addressing 4124 information that needs translation, legacy NAT traversal is not 4125 possible. The receiver MUST return an "Object Type Error" message 4126 (Appendix A.4.4.9) with subcode 4 ("Untranslated Object") indicating 4127 the MRI as the object in question. The error message MUST be 4128 addressed to the source address from the IP header of the incoming 4129 message. The Responding node SHOULD use the destination IP address 4130 of the original datagram as the source address for IP header of the 4131 Response; this makes it more likely that the NAT will accept the 4132 incoming message, since it looks like a normal UDP/IP request/reply 4133 exchange. If this message is able to traverse back through the NAT, 4134 the Querying node will terminate the handshake immediately; 4135 otherwise, this reduces to the previous case of a lost Response and 4136 the Querying node will give up on reaching its retransmission limit. 4138 When the Querying node is on the external side of the NAT, the Query 4139 will only traverse the NAT if some static configuration has been 4140 carried out on the NAT to forward GIST Q-mode traffic to a node on 4141 the internal network. Regardless of the S-flag in the Query, the 4142 Responding node cannot directly detect the presence of the NAT. It 4143 MUST send a normal Response with S=1 to an address derived from the 4144 Querying node's NLI which will traverse the NAT as normal UDP 4145 traffic. The Querying node MUST check the source address in the IP 4146 header with the NLI in the Response, and when it finds a mismatch it 4147 MUST terminate the handshake. 4149 Note that in either of the error cases (internal or external Querying 4150 node), an alternative to terminating the handshake could be to invoke 4151 some legacy NAT traversal procedure. This specification does not 4152 define any such procedure, although one possible approach is 4153 described in [41]. Any such traversal procedure MUST be incorporated 4154 into GIST using the existing GIST extensibility capabilities. 4156 7.2.2. GIST-aware NAT Traversal 4158 The most robust solution to the NAT traversal problem is to require 4159 that a NAT is GIST-aware, and to allow it to modify messages based on 4160 the contents of the MRI. This makes the assumption that NATs only 4161 rewrite the header fields included in this payload, and not other 4162 higher layer identifiers. Provided this is done consistently with 4163 the data flow header translation, signalling messages will be valid 4164 each side of the boundary, without requiring the NAT to be signalling 4165 application aware. Note, however, that if the NAT does not 4166 understand the MRI, and the N-flag in the MRI is clear (see 4167 Appendix A.3.1), it should reject the message with an "Object Type 4168 Error" message (Appendix A.4.4.9) with subcode 4 ("Untranslated 4169 Object"). 4171 This specification defines an additional object that a NAT inserts 4172 into all Q-mode encapsulated messages and which is echoed back in any 4173 replies, i.e. Response or Error messages. NATs apply GIST-specific 4174 processing only to Q-mode encapsulated messages or replies carrying 4175 the NAT traversal object. All other GIST messages, either in C-mode, 4176 or D-mode messages with no NAT-Traversal object, should be treated as 4177 normal data traffic by the NAT, i.e. with IP and transport layer 4178 header translation but no GIST-specific processing. 4180 The new object, the NAT-Traversal object (Appendix A.3.9), carries 4181 the translation between the MRIs which are appropriate for the 4182 internal and external sides of the NAT. It also carries a list of 4183 which other objects in the message have been translated. This should 4184 always include the NLI, and the Stack-Configuration-Data if present; 4185 if GIST is extended with further objects that carry addressing data, 4186 this list allows a message receiver to know if the new objects were 4187 supported by the NAT. Finally, the NAT-Traversal object MAY be used 4188 to carry data to assist the NAT in back-translating D-mode responses; 4189 this could be the original NLI or SCD, or opaque equivalents in the 4190 case of topology hiding. 4192 A consequence of this approach is that the routing state tables at 4193 the signalling application peers each side of the NAT are no longer 4194 directly compatible. In particular, the values for Message-Routing- 4195 Information are different, which is why the unmodified MRI is 4196 propagated in the NAT-Traversal object to allow subsequent C-mode 4197 messages to be interpreted correctly. 4199 7.2.3. Message Processing Rules 4201 This specification normatively defines the behaviour of a GIST node 4202 receiving a message containing a NAT-Traversal object. However, it 4203 does not define normative behaviour for a NAT translating GIST 4204 messages, since much of this will depend on NAT implementation and 4205 policy about allocating bindings. In addition, it is not necessary 4206 for a GIST implementation itself. Therefore, those aspects of the 4207 following description are informative; full details of NAT behaviour 4208 for handling GIST messages can be found in [42]. 4210 A possible set of operations for a NAT to process a Q-mode 4211 encapsulated message is as follows. Note that for a Data message, 4212 only a subset of the operations is applicable. 4214 1. Verify that bindings for any data flow are actually in place. 4216 2. Create a new Message-Routing-Information object with fields 4217 modified according to the data flow bindings. 4219 3. Create bindings for subsequent C-mode signalling based on the 4220 information in the Network-Layer-Information and Stack- 4221 Configuration-Data objects. 4223 4. Create new Network-Layer-Information and if necessary Stack- 4224 Configuration-Data objects with fields to force D-mode response 4225 messages through the NAT, and to allow C-mode exchanges using the 4226 C-mode signalling bindings. 4228 5. Add a NAT-Traversal object, listing the objects which have been 4229 modified and including the unmodified MRI and any other data 4230 needed to interpret the response. If a NAT-Traversal object is 4231 already present, in the case of a sequence of NATs, the list of 4232 modified objects may be updated and further opaque data added, 4233 but the MRI contained in it is left unchanged. 4235 6. Encapsulate the message according to the normal rules of this 4236 specification for the Q-mode encapsulation. If the S-flag was 4237 set in the original message, the same IP source address selection 4238 policy should be applied to the forwarded message. 4240 7. Forward the message with these new payloads. 4242 A GIST node receiving such a message MUST verify that all mandatory 4243 objects containing addressing have been translated correctly, or else 4244 reject the message with an "Object Type Error" message 4245 (Appendix A.4.4.9) with subcode 4 ("Untranslated Object"). The error 4246 message MUST include the NAT-Traversal object as the first TLV after 4247 the common header, and this is also true for any other error message 4248 generated as a reply. Otherwise, the message is processed 4249 essentially as normal. If no state needs to be updated for the 4250 message, the NAT-Traversal object can be effectively ignored. The 4251 other possibility is that a Response must be returned, either because 4252 the message is the beginning of a handshake for a new flow, or it is 4253 a refresh for existing state. In both cases, the GIST node MUST 4254 create the Response in the normal way using the local form of the 4255 MRI, and its own NLI and (if necessary) SCD. It MUST also include 4256 the NAT-Traversal object as the first object in the Response after 4257 the common header. 4259 A NAT will intercept D-mode messages with the normal encapsulation 4260 containing such echoed NAT-Traversal objects. The NAT processing is 4261 a subset of the processing for the Q-mode encapsulated case: 4263 1. Verify the existence of bindings for the data flow. 4265 2. Leave the Message-Routing-Information object unchanged. 4267 3. Modify the NLI and SCD objects for the Responding node if 4268 necessary, and create or update any bindings for C-mode 4269 signalling traffic. 4271 4. Forward the message. 4273 A GIST node receiving such a message MUST use the MRI from the NAT- 4274 Traversal object as the key to index its internal routing state; it 4275 MAY also store the translated MRI for additional (e.g. diagnostic) 4276 information, but this is not used in the GIST processing. The 4277 remainder of GIST processing is unchanged. 4279 Note that Confirm messages are not given GIST-specific processing by 4280 the NAT. Thus, a Responding node which has delayed state 4281 installation until receiving the Confirm, only has available the 4282 untranslated MRI describing the flow, and the untranslated NLI as 4283 peer routing state. This would prevent the correct interpretation of 4284 the signalling messages; also, subsequent Query (refresh) messages 4285 would always be seen as route changes because of the NLI change. 4286 Therefore, a Responding node that wishes to delay state installation 4287 until receiving a Confirm must somehow reconstruct the translations 4288 when the Confirm arrives. How to do this is an implementation issue; 4289 one approach is to carry the translated objects as part of the 4290 Responder cookie which is echoed in the Confirm. Indeed, for one of 4291 the cookie constructions in Section 8.5 this is automatic. 4293 7.3. Interaction with IP Tunnelling 4295 The interaction between GIST and IP tunnelling is very simple. An IP 4296 packet carrying a GIST message is treated exactly the same as any 4297 other packet with the same source and destination addresses: in other 4298 words, it is given the tunnel encapsulation and forwarded with the 4299 other data packets. 4301 Tunnelled packets will not be identifiable as GIST messages until 4302 they leave the tunnel, since any router alert option and the standard 4303 GIST protocol encapsulation (e.g. port numbers) will be hidden within 4304 the standard tunnel encapsulation. If signalling is needed for the 4305 tunnel itself, this has to be initiated as a separate signalling 4306 session by one of the tunnel endpoints - that is, the tunnel counts 4307 as a new flow. Because the relationship between signalling for the 4308 microflow and signalling for the tunnel as a whole will depend on the 4309 signalling application in question, it is a signalling application 4310 responsibility to be aware of the fact that tunnelling is taking 4311 place and to carry out additional signalling if necessary; in other 4312 words, at least one tunnel endpoint must be signalling application 4313 aware. 4315 In some cases, it is the tunnel exit point (i.e. the node where 4316 tunnelled data and downstream signalling packets leave the tunnel) 4317 that will wish to carry out the tunnel signalling, but this node will 4318 not have knowledge or control of how the tunnel entry point is 4319 carrying out the data flow encapsulation. The information about how 4320 the inner MRI/SID relate to the tunnel MRI/SID needs to be carried in 4321 the signalling data from the tunnel entry point; this functionality 4322 is the equivalent to the RSVP SESSION_ASSOC object of [18]. In the 4323 NSIS protocol suite, these bindings are managed by the signalling 4324 applications, either implicitly (e.g. by SID re-use) or explicitly by 4325 carrying objects that bind the inner and outer SIDs as part of the 4326 NSLP payload. 4328 7.4. IPv4-IPv6 Transition and Interworking 4330 GIST itself is essentially IP version neutral: version dependencies 4331 are isolated in the formats of the Message-Routing-Information, 4332 Network-Layer-Information and Stack-Configuration-Data objects, and 4333 GIST also depends on the version independence of the protocols that 4334 support messaging associations. In mixed environments, GIST 4335 operation will be influenced by the IP transition mechanisms in use. 4336 This section provides a high level overview of how GIST is affected, 4337 considering only the currently predominant mechanisms. 4339 Dual Stack: (As described in [36].) In mixed environments, GIST 4340 MUST use the same IP version for Q-mode encapsulated messages as 4341 given by the MRI of the flow it is signalling for, and SHOULD do 4342 so for other signalling also (see Section 5.2.2). Messages with 4343 mismatching versions MUST be rejected with a "MRI Validation 4344 Failure" error message (Appendix A.4.4.12) with subcode 1 ("IP 4345 Version Mismatch"). The IP version used in D-mode is closely tied 4346 to the IP version used by the data flow, so it is intrinsically 4347 impossible for an IPv4-only or IPv6-only GIST node to support 4348 signalling for flows using the other IP version. Hosts which are 4349 dual stack for applications and routers which are dual stack for 4350 forwarding need GIST implementations which can support both IP 4351 versions. Applications with a choice of IP versions might select 4352 a version based on which could be supported in the network by 4353 GIST, which could be established by invoking parallel discovery 4354 procedures. 4356 Packet Translation: (Applicable to SIIT [9] and NAT-PT [19].) Some 4357 transition mechanisms allow IPv4 and IPv6 nodes to communicate by 4358 placing packet translators between them. From the GIST 4359 perspective, this should be treated essentially the same way as 4360 any other NAT operation (e.g. between internal and external 4361 addresses) as described in Section 7.2. The translating node 4362 needs to be GIST-aware; it will have to translate the addressing 4363 payloads between IPv4 and IPv6 formats for flows which cross 4364 between the two. The translation rules for the fields in the MRI 4365 payload (including e.g. DiffServ-codepoint and flow-label) are as 4366 defined in [9]. 4368 Tunnelling: (Applicable to 6to4 [21].) Many transition mechanisms 4369 handle the problem of how an end to end IPv6 (or IPv4) flow can be 4370 carried over intermediate IPv4 (or IPv6) regions by tunnelling; 4371 the methods tend to focus on minimising the tunnel administration 4372 overhead. 4374 From the GIST perspective, the treatment should be similar to any 4375 other IP tunnelling mechanism, as described in Section 7.3. In 4376 particular, the end to end flow signalling will pass transparently 4377 through the tunnel, and signalling for the tunnel itself will have 4378 to be managed by the tunnel endpoints. However, additional 4379 considerations may arise because of special features of the tunnel 4380 management procedures. In particular, [22] is based on using an 4381 anycast address as the destination tunnel endpoint. GIST MAY use 4382 anycast destination addresses in the Q-mode encapsulation of 4383 D-mode messages if necessary, but MUST NOT use them in the 4384 Network-Layer-Information addressing field; unicast addresses MUST 4385 be used instead. Note that the addresses from the IP header are 4386 not used by GIST in matching requests and replies, so there is no 4387 requirement to use anycast source addresses. 4389 8. Security Considerations 4391 The security requirement for GIST is to protect the signalling plane 4392 against identified security threats. For the signalling problem as a 4393 whole, these threats have been outlined in [31]; the NSIS framework 4394 [30] assigns a subset of the responsibilities to the NTLP. The main 4395 issues to be handled can be summarised as: 4397 Message Protection: Signalling message content can be protected 4398 against eavesdropping, modification, injection and replay while in 4399 transit. This applies both to GIST payloads, and GIST should also 4400 provide such protection as a service to signalling applications 4401 between adjacent peers. 4403 Routing State Integrity Protection: It is important that signalling 4404 messages are delivered to the correct nodes, and nowhere else. 4405 Here, 'correct' is defined as 'the appropriate nodes for the 4406 signalling given the Message-Routing-Information'. In the case 4407 where the MRI is based on the Flow Identification for path-coupled 4408 signalling, 'appropriate' means 'the same nodes that the 4409 infrastructure will route data flow packets through'. GIST has no 4410 role in deciding whether the data flow itself is being routed 4411 correctly; all it can do is ensure the signalling is routed 4412 consistently with it. GIST uses internal state to decide how to 4413 route signalling messages, and this state needs to be protected 4414 against corruption. 4416 Prevention of Denial of Service Attacks: GIST nodes and the network 4417 have finite resources (state storage, processing power, 4418 bandwidth). The protocol tries to minimise exhaustion attacks 4419 against these resources and not allow GIST nodes to be used to 4420 launch attacks on other network elements. 4422 The main additional issue is handling authorisation for executing 4423 signalling operations (e.g. allocating resources). This is assumed 4424 to be done in each signalling application. 4426 In many cases, GIST relies on the security mechanisms available in 4427 messaging associations to handle these issues, rather than 4428 introducing new security measures. Obviously, this requires the 4429 interaction of these mechanisms with the rest of the GIST protocol to 4430 be understood and verified, and some aspects of this are discussed in 4431 Section 5.7. 4433 8.1. Message Confidentiality and Integrity 4435 GIST can use messaging association functionality, specifically in 4436 this version TLS (Section 5.7.3), to ensure message confidentiality 4437 and integrity. Implementation of this functionality is REQUIRED but 4438 its use for any given flow or signalling application is OPTIONAL. In 4439 some cases, confidentiality of GIST information itself is not likely 4440 to be a prime concern, in particular since messages are often sent to 4441 parties which are unknown ahead of time, although the content visible 4442 even at the GIST level gives significant opportunities for traffic 4443 analysis. Signalling applications may have their own mechanism for 4444 securing content as necessary; however, they may find it convenient 4445 to rely on protection provided by messaging associations, since it 4446 runs unbroken between signalling application peers. 4448 8.2. Peer Node Authentication 4450 Cryptographic protection (of confidentiality or integrity) requires a 4451 security association with session keys. These can be established by 4452 an authentication and key exchange protocol based on shared secrets, 4453 public key techniques or a combination of both. Authentication and 4454 key agreement is possible using the protocols associated with the 4455 messaging association being secured. TLS incorporates this 4456 functionality directly. GIST nodes rely on the messaging association 4457 protocol to authenticate the identity of the next hop, and GIST has 4458 no authentication capability of its own. 4460 With routing state discovery, there are few effective ways to know 4461 what is the legitimate next or previous hop as opposed to an 4462 impostor. In other words, cryptographic authentication here only 4463 provides assurance that a node is 'who' it is (i.e. the legitimate 4464 owner of identity in some namespace), not 'what' it is (i.e. a node 4465 which is genuinely on the flow path and therefore can carry out 4466 signalling for a particular flow). Authentication provides only 4467 limited protection, in that a known peer is unlikely to lie about its 4468 role. Additional methods of protection against this type of attack 4469 are considered in Section 8.3 below. 4471 It is an implementation issue whether peer node authentication should 4472 be made signalling application dependent; for example, whether 4473 successful authentication could be made dependent on presenting 4474 credentials related to a particular signalling role (e.g. signalling 4475 for QoS). The abstract API of Appendix B leaves open such policy and 4476 authentication interactions between GIST and the NSLP it is serving. 4477 However, it does allow applications to inspect the authenticated 4478 identity of the peer to which a message will be sent before 4479 transmission. 4481 8.3. Routing State Integrity 4483 Internal state in a node (see Section 4.2) is used to route messages. 4484 If this state is corrupted, signalling messages may be misdirected. 4486 In the case where the MRM is path-coupled, the messages need to be 4487 routed identically to the data flow described by the MRI, and the 4488 routing state table is the GIST view of how these flows are being 4489 routed through the network in the immediate neighbourhood of the 4490 node. Routes are only weakly secured (e.g. there is no cryptographic 4491 binding of a flow to a route), and there is no authoritative 4492 information about flow routes other than the current state of the 4493 network itself. Therefore, consistency between GIST and network 4494 routing state has to be ensured by directly interacting with the IP 4495 routing mechanisms to ensure that the signalling peers are the 4496 appropriate ones for any given flow. An overview of security issues 4497 and techniques in this context is provided in [38]. 4499 In one direction, peer identification is installed and refreshed only 4500 on receiving a Response (compare Figure 4). This MUST echo the 4501 cookie from a previous Query, which will have been sent along the 4502 flow path with the Q-mode encapsulation, i.e. end-to-end addressed. 4503 Hence, only the true next peer or an on-path attacker will be able to 4504 generate such a message, provided freshness of the cookie can be 4505 checked at the querying node. 4507 In the other direction, peer identification MAY be installed directly 4508 on receiving a Query containing addressing information for the 4509 signalling source. However, any node in the network could generate 4510 such a message; indeed, many nodes in the network could be the 4511 genuine upstream peer for a given flow. To protect against this, 4512 four strategies are used: 4514 Filtering: the receiving node MAY reject signalling messages which 4515 claim to be for flows with flow source addresses which could be 4516 ruled out by ingress filtering. An extension of this technique 4517 would be for the receiving node to monitor the data plane and to 4518 check explicitly that the flow packets are arriving over the same 4519 interface and if possible from the same link layer neighbour as 4520 the D-mode signalling packets. If they are not, it is likely that 4521 at least one of the signalling or flow packets is being spoofed. 4523 Return routability checking: the receiving node MAY refuse to 4524 install upstream state until it has completed a Confirm handshake 4525 with the peer. This echoes the Response cookie of the Response, 4526 and discourages nodes from using forged source addresses. This 4527 also plays a role in denial of service prevention, see below. 4529 Authorisation: a stronger approach is to carry out a peer 4530 authorisation check (see Section 4.4.2) as part of messaging 4531 association setup. The ideal situation is that the receiving node 4532 can determine the correct upstream node address from routing table 4533 analysis or knowledge of local topology constraints, and then 4534 verify from the authorised peer database (APD) that the peer has 4535 this IP address. This is only technically feasible in a limited 4536 set of deployment environments. The APD can also be used to list 4537 the subsets of nodes which are feasible peers for particular 4538 source or destination subnets, or to blacklist nodes which have 4539 previously originated attacks or exist in untrustworthy networks, 4540 which provide weaker levels of authorisation checking. 4542 SID segregation: The routing state lookup for a given MRI and NSLPID 4543 MUST also take the SID into account. A malicious node can only 4544 overwrite existing GIST routing state if it can guess the 4545 corresponding SID; it can insert state with random SID values, but 4546 generally this will not be used to route signalling messages for 4547 which state has already been legitimately established. 4549 8.4. Denial of Service Prevention and Overload Protection 4551 GIST is designed so that in general each Query only generates at most 4552 one Response which is at most only slightly larger than the Query, so 4553 that a GIST node cannot become the source of a denial of service 4554 amplification attack. (There is a special case of retransmitted 4555 Response messages, see Section 5.3.3.) 4557 However, GIST can still be subjected to denial-of-service attacks 4558 where an attacker using forged source addresses forces a node to 4559 establish state without return routability, causing a problem similar 4560 to TCP SYN flood attacks. Furthermore, an adversary might use 4561 modified or replayed unprotected signalling messages as part of such 4562 an attack. There are two types of state attacks and one 4563 computational resource attack. In the first state attack, an 4564 attacker floods a node with messages that the node has to store until 4565 it can determine the next hop. If the destination address is chosen 4566 so that there is no GIST-capable next hop, the node would accumulate 4567 messages for several seconds until the discovery retransmission 4568 attempt times out. The second type of state-based attack causes GIST 4569 state to be established by bogus messages. A related computational/ 4570 network-resource attack uses unverified messages to cause a node 4571 query an authentication or authorisation infrastructure, or attempt 4572 to cryptographically verify a digital signature. 4574 We use a combination of two defences against these attacks: 4576 1. The responding node need not establish a session or discover its 4577 next hop on receiving the Query, but MAY wait for a Confirm, 4578 possibly on a secure channel. If the channel exists, the 4579 additional delay is one one-way delay and the total is no more 4580 than the minimal theoretically possible delay of a three-way 4581 handshake, i.e., 1.5 node-to-node round-trip times. The delay 4582 gets significantly larger if a new connection needs to be 4583 established first. 4585 2. The Response to the Query contains a cookie, which is repeated in 4586 the Confirm. State is only established for messages that contain 4587 a valid cookie. The setup delay is also 1.5 round-trip times. 4588 This mechanism is similar to that in SCTP [20] and other modern 4589 protocols. 4591 There is a potential overload condition if a node is flooded with 4592 Query or Confirm messages. One option is for the node to bypass 4593 these messages altogether as described in Section 4.3.2, effectively 4594 falling back to being a non-NSIS node. If this is not possible, a 4595 node MAY still choose to limit the rate at which it processes Query 4596 messages and discard the excess, although it SHOULD first adapt its 4597 policy to one of sending Responses statelessly if it is not already 4598 doing so. A conformant GIST node will automatically decrease the 4599 load by retransmitting Queries with an exponential backoff. A non- 4600 conformant node (launching a DoS attack) can generate uncorrelated 4601 Queries at an arbitrary rate, which makes it hard to apply rate- 4602 limiting without also affecting genuine handshake attempts. However, 4603 if Confirm messages are requested, the cookie binds the message to a 4604 Querying node address which has been validated by a return 4605 routability check and rate-limits can be applied per-source. 4607 Once a node has decided to establish routing state, there may still 4608 be transport and security state to be established between peers. 4609 This state setup is also vulnerable to denial of service attacks. 4610 GIST relies on the implementations of the lower layer protocols that 4611 make up messaging associations to mitigate such attacks. In the 4612 current specification, the querying node is always the one wishing to 4613 establish a messaging association, so it is the responding node that 4614 needs to be protected. It is possible for an attacking node to 4615 execute these protocols legally to set up large numbers of 4616 associations that were never used, and responding node 4617 implementations MAY use rate-limiting or other techniques to control 4618 the load in such cases. 4620 Signalling applications can use the services provided by GIST to 4621 defend against certain (e.g. flooding) denial of service attacks. In 4622 particular, they can elect to process only messages from peers that 4623 have passed a return routability check or been authenticated at the 4624 messaging association level (see Appendix B.2). Signalling 4625 applications that accept messages under other circumstances (in 4626 particular, before routing state has been fully established at the 4627 GIST level) need to take this into account when designing their 4628 denial of service prevention mechanisms, for example by not creating 4629 local state as a result of processing such messages. Signalling 4630 applications can also manage overload by invoking flow control, as 4631 described in Section 4.1.1. 4633 8.5. Requirements on Cookie Mechanisms 4635 The requirements on the Query cookie can be summarised as follows: 4637 Liveness: The cookie must be live, that is, it must change from one 4638 handshake to the next. To prevent replay attacks. 4640 Unpredictability: The cookie must not be guessable e.g. from a 4641 sequence or timestamp. To prevent direct forgery based on seeing 4642 a history of captured messages. 4644 Easily validated: It must be efficient for the Q-Node to validate 4645 that a particular cookie matches an in-progress handshake, for a 4646 routing state machine which already exists. To discard responses 4647 which have been randomly generated by an adversary, or to discard 4648 responses to queries which were generated with forged source 4649 addresses or an incorrect address in the included NLI object. 4651 Uniqueness: The cookie must be unique to a given handshake since it 4652 is actually used to match the Response to a handshake anyway, e.g. 4653 because of messaging association multiplexing. 4655 Likewise, the requirements on the Responder cookie can be summarised 4656 as follows: 4658 Liveness: The cookie must be live as above. To prevent replay 4659 attacks. 4661 Creation simplicity: The cookie must be lightweight to generate. To 4662 avoid resource exhaustion at the responding node. 4664 Validation simplicity: It must be simple for the R-node to validate 4665 that an R-cookie was generated by itself and no-one else, without 4666 storing state about the handshake it was generated for. 4668 Binding: The cookie must be bound to the routing state that will be 4669 installed. To prevent use with different routing state e.g. in a 4670 modified Confirm. The routing state here includes the NLI of the 4671 Query, the MRI/NSLPID for the messaging, and the interface on 4672 which the Query was received. 4674 A suitable implementation for the Q-Cookie is a cryptographically 4675 strong random number which is unique for this routing state machine 4676 handshake. A node MUST implement this or an equivalently strong 4677 mechanism. Guidance on random number generation can be found in 4679 [32]. 4681 A suitable implementation for the R-Cookie is as follows: 4683 R-Cookie = liveness data + hash (locally known secret, 4684 Q-Node NLI, MRI, NSLPID, 4685 reception interface, 4686 liveness data) 4688 A node MUST implement this or an equivalently strong mechanism. 4689 There are several alternatives for the liveness data. One is to use 4690 a timestamp like SCTP. Another is to give the local secret a (rapid) 4691 rollover, with the liveness data as the generation number of the 4692 secret, like IKEv2. In both cases, the liveness data has to be 4693 carried outside the hash, to allow the hash to be verified at the 4694 Responder. Another approach is to replace the hash with encryption 4695 under a locally known secret, in which case the liveness data does 4696 not need to be carried in the clear. Any symmetric cipher immune to 4697 known plaintext attacks can be used. 4699 To support the validation simplicity requirement, the Responder can 4700 check the liveness data to filter out some blind (flooding) attacks 4701 before beginning any cryptographic cookie verification. To support 4702 this usage, the liveness data must be carried in the clear and not be 4703 easily guessable; this rules out the timestamp approach, and suggests 4704 the use of sequence of secrets with the liveness data identifying the 4705 position in the sequence. The secret strength and rollover frequency 4706 must be high enough that the secret cannot be brute-forced during its 4707 lifetime. Note that any node can use a Query to discover the current 4708 liveness data, so it remains hard to defend against sophisticated 4709 attacks which disguise such probes within a flood of Queries from 4710 forged source addresses. Therefore, it remains important to use an 4711 efficient hashing mechanism or equivalent. 4713 If a node receives a message for which cookie validation fails, it 4714 MAY return an "Object Value Error" message (Appendix A.4.4.10) with 4715 subcode 4 ("Invalid Cookie") to the sender, as well as dropping the 4716 message. However, sending the error in general makes a node a source 4717 of backscatter. Therefore, this MUST only be enabled selectively, 4718 e.g. during initial deployment or debugging. 4720 8.6. Security Protocol Selection Policy 4722 This specification defines a single mandatory-to-implement security 4723 protocol (TLS, Section 5.7.3). However, it is possible to define 4724 additional security protocols in the future, for example to allow re- 4725 use with other types of credentials, or migrate towards protocols 4726 with stronger security properties. In addition, use of any security 4727 protocol for a messaging association is optional. Security protocol 4728 selection is carried out as part of the GIST handshake mechanism 4729 (Section 4.4.1). 4731 The selection process may be vulnerable to downgrade attacks, where a 4732 man in the middle modifies the capabilities offered in the Query or 4733 Response to mislead the peers into accepting a lower level of 4734 protection than is achievable. There is a two part defence against 4735 such attacks (the following is based the same concepts as [25]): 4737 1. The Response does not depend on the Stack-Proposal in the Query 4738 (see Section 5.7.1). Therefore, tampering with the Query has no 4739 effect on the resulting messaging association configuration. 4741 2. The Responding node's Stack-Proposal is echoed in the Confirm. 4742 The Responding node checks this to validate that the proposal it 4743 made in the Response is the same as the one received by the 4744 Querying node. Note that as a consequence of the previous point, 4745 the Responding node does not have to remember the proposal 4746 explicitly, since it is a static function of local policy. 4748 The validity of the second part depends on the strength of the 4749 security protection provided for the Confirm. If the Querying node 4750 is prepared to create messaging associations with null security 4751 properties (e.g. TCP only), the defence is ineffective, since the 4752 man in the middle can re-insert the original Responder's Stack- 4753 Proposal, and the Responding node will assume that the minimal 4754 protection is a consequence of Querying node limitations. However, 4755 if the messaging association provides at least integrity protection 4756 that cannot be broken in real-time, the Confirm cannot be modified in 4757 this way. Therefore, if the Querying node does not apply a security 4758 policy to the messaging association protocols to be created that 4759 ensures at least this minimal level of protection is met, it remains 4760 open to the threat that a downgrade has occurred. Applying such a 4761 policy ensures capability discovery process will result in the setup 4762 of a messaging association with the correct security properties as 4763 appropriate for the two peers involved. 4765 8.7. Residual Threats 4767 Taking the above security mechanisms into account, the main residual 4768 threats against NSIS are three types of on-path attack, as well as 4769 implementation-related weaknesses. 4771 An on-path attacker who can intercept the initial Query can do most 4772 things it wants to the subsequent signalling. It is very hard to 4773 protect against this at the GIST level; the only defence is to use 4774 strong messaging association security to see whether the Responding 4775 node is authorised to take part in NSLP signalling exchanges. To 4776 some extent, this behaviour is logically indistinguishable from 4777 correct operation, so it is easy to see why defence is difficult. 4778 Note that an on-path attacker of this sort can do anything to the 4779 traffic as well as the signalling. Therefore, the additional threat 4780 induced by the signalling weakness seems tolerable. 4782 At the NSLP level, there is a concern about transitivity of trust of 4783 correctness of routing along the signalling chain. The NSLP at the 4784 querying node can have good assurance that it is communicating with 4785 an on-path peer or a node delegated by the on-path node by depending 4786 on the security protection provided by GIST. However, it has no 4787 assurance that the node beyond the responder is also on-path, or that 4788 the MRI (in particular) is not being modified by the responder to 4789 refer to a different flow. Therefore, if it sends signalling 4790 messages with payloads (e.g. authorisation tokens) which are valuable 4791 to nodes beyond the adjacent hop, it is up to the NSLP to ensure that 4792 the appropriate chain of trust exists. This could be achieved using 4793 higher layer security protection such as CMS [29]. 4795 There is a further residual attack by a node which is not on the path 4796 of the Query, but is on the path of the Response, or is able to use a 4797 Response from one handshake to interfere with another. The attacker 4798 modifies the Response to cause the Querying node to form an adjacency 4799 with it rather than the true peer. In principle, this attack could 4800 be prevented by including an additional cryptographic object in the 4801 Response which ties the Response to the initial Query and the routing 4802 state and can be verified by the Querying node. 4804 Certain security aspects of GIST operation depend on signalling 4805 application behaviour: a poorly implemented or compromised NSLP could 4806 degrade GIST security. However, the degradation would only affect 4807 GIST handling of the NSLP's own signalling traffic or overall 4808 resource usage at the node where the weakness occurred, and 4809 implementation weakness or compromise could have just as great an 4810 effect within the NSLP itself. GIST depends on NSLPs to choose SIDs 4811 appropriately (Section 4.1.3). If NSLPs choose non-random SIDs this 4812 makes off-path attacks based on SID guessing easier to carry out. 4813 NSLPs can also leak information in structured SIDs, but they could 4814 leak similar information in the NLSP payload data anyway. 4816 9. IANA Considerations 4818 This section defines the registries and initial codepoint assignments 4819 for GIST. It also defines the procedural requirements to be followed 4820 by IANA in allocating new codepoints. Note that the guidelines on 4821 the technical criteria to be followed in evaluating requests for new 4822 codepoint assignments are covered normatively in a separate document 4823 which considers the NSIS protocol suite in a unified way. That 4824 document discusses the general issue of NSIS extensibility, as well 4825 as the technical criteria for particular registries; see [14] for 4826 further details. 4828 The registry definitions that follow leave large blocks of codes 4829 marked "Reserved - not to be allocated". This is to allow a future 4830 revision of this specification or another Standards Track document to 4831 modify the relative space given to different allocation policies 4832 without having to change the initial rules retrospectively if they 4833 turn out to have been inappropriate, e.g. if the space for one 4834 particular policy is exhausted too quickly. 4836 The allocation policies used in this section follow the guidance 4837 given in [6]. In addition, for a number of the GIST registries, this 4838 specification also defines private/experimental ranges as discussed 4839 in [11]. Note that the only environment in which these codepoints 4840 can validly be used is a closed one in which the experimenter knows 4841 all the experiments in progress. 4843 This specification allocates the following codepoints in existing 4844 registries: 4846 Well-known UDP port XXX as the destination port for Q-mode 4847 encapsulated GIST messages (Section 5.3). 4849 This specification creates the following registries with the 4850 structures as defined below: 4852 NSLP Identifiers: Each signalling application requires the 4853 assignment of one of more NSLPIDs. The following NSLPID is 4854 allocated by this specification: 4856 +---------+---------------------------------------------------------+ 4857 | NSLPID | Application | 4858 +---------+---------------------------------------------------------+ 4859 | 0 | Used for GIST messages not related to any signalling | 4860 | | application. | 4861 +---------+---------------------------------------------------------+ 4863 Every other NSLPID that uses an MRM which requires RAO usage MUST 4864 be associated with a specific RAO value; multiple NSLPIDs MAY be 4865 associated with the same value. RAO value assignments require a 4866 specification of the processing associated with messages that 4867 carry the value. NSLP specifications MUST normatively depend on 4868 this document for the processing, specifically Section 4.3.1, 4869 Section 4.3.4 and Section 5.3.2. The NSLPID is a 16 bit integer, 4870 and allocation policies for further values are as follows: 4872 1-32703: IESG Approval 4874 32704-32767: Private/Experimental Use 4876 32768-65536: Reserved - not to be allocated 4878 GIST Message Type: The GIST common header (Appendix A.1) contains a 4879 1 byte message type field. The following values are allocated by 4880 this specification: 4882 +---------+----------+ 4883 | MType | Message | 4884 +---------+----------+ 4885 | 0 | Query | 4886 | | | 4887 | 1 | Response | 4888 | | | 4889 | 2 | Confirm | 4890 | | | 4891 | 3 | Data | 4892 | | | 4893 | 4 | Error | 4894 | | | 4895 | 5 | MA-Hello | 4896 +---------+----------+ 4898 Allocation policies for further values are as follows: 4900 6-63: Standards Action 4902 64-119: Expert Review 4904 120-127: Private/Experimental Use 4906 128-255: Reserved - not to be allocated 4908 Object Types: There is a 12-bit field in the object header 4909 (Appendix A.2). The following values for object type are defined 4910 by this specification: 4912 +---------+-----------------------------+ 4913 | OType | Object Type | 4914 +---------+-----------------------------+ 4915 | 0 | Message Routing Information | 4916 | | | 4917 | 1 | Session ID | 4918 | | | 4919 | 2 | Network Layer Information | 4920 | | | 4921 | 3 | Stack Proposal | 4922 | | | 4923 | 4 | Stack Configuration Data | 4924 | | | 4925 | 5 | Query Cookie | 4926 | | | 4927 | 6 | Responder Cookie | 4928 | | | 4929 | 7 | NAT Traversal | 4930 | | | 4931 | 8 | NSLP Data | 4932 | | | 4933 | 9 | Error | 4934 | | | 4935 | 10 | Hello ID | 4936 +---------+-----------------------------+ 4938 Allocation policies for further values are as follows: 4940 10-1023: Standards Action 4942 1024-1999: Specification Required 4944 2000-2047: Private/Experimental Use 4946 2048-4095: Reserved - not to be allocated 4948 When a new object type is allocated according to one of the first 4949 two policies, the specification MUST provide the object format and 4950 define the setting of the extensibility bits (A/B, see 4951 Appendix A.2.1). 4953 Message Routing Methods: GIST allows multiple message routing 4954 methods (see Section 3.3). The MRM is indicated in the leading 4955 byte of the MRI object (Appendix A.3.1). This specification 4956 defines the following values: 4958 +------------+------------------------+ 4959 | MRM-ID | Message Routing Method | 4960 +------------+------------------------+ 4961 | 0 | Path Coupled MRM | 4962 | | | 4963 | 1 | Loose End MRM | 4964 +------------+------------------------+ 4966 Allocation policies for further values are as follows: 4968 2-63: Standards Action 4970 64-119: Expert Review 4972 120-127: Private/Experimental Use 4974 128-255: Reserved - not to be allocated 4976 When a new MRM is defined according to one of the first two 4977 policies, a specification document will be required. This MUST 4978 provide the information described in Section 3.3. 4980 MA-Protocol-IDs: Each protocol that can be used in a messaging 4981 association is identified by a 1-byte MA-Protocol-ID 4982 (Section 5.7). Note that the MA-Protocol-ID is not an IP Protocol 4983 number; indeed, some of the messaging association protocols - such 4984 as TLS - do not have an IP Protocol number. This is used as a tag 4985 in the Stack-Proposal and Stack-Configuration-Data objects 4986 (Appendix A.3.4 and Appendix A.3.5). The following values are 4987 defined by this specification: 4989 +---------------------+-----------------------------------------+ 4990 | MA-Protocol-ID | Protocol | 4991 +---------------------+-----------------------------------------+ 4992 | 0 | Reserved - not to be allocated | 4993 | | | 4994 | 1 | TCP opened in the forwards direction | 4995 | | | 4996 | 2 | TLS initiated in the forwards direction | 4997 +---------------------+-----------------------------------------+ 4999 Allocation policies for further values are as follows: 5001 3-63: Standards Action 5003 64-119: Expert Review 5005 120-127: Private/Experimental Use 5007 128-255: Reserved - not to be allocated 5009 When a new MA-Protocol-ID is allocated according to one of the 5010 first two policies, a specification document will be required. 5011 This MUST define the format for the MA-protocol-options field (if 5012 any) in the Stack-Configuration-Data object that is needed to 5013 define its configuration. If a protocol is to be used for 5014 reliable message transfer, it MUST be described how delivery 5015 errors are to be detected by GIST. Extensions to include new 5016 channel security protocols MUST include a description of how to 5017 integrate the functionality described in Section 3.9 with the rest 5018 of GIST operation. If the new MA-Protocol-ID can be used in 5019 conjunction with existing ones (for example, a new transport 5020 protocol option which could be used with Transport Layer 5021 Security), the specification MUST define the interaction between 5022 the two. 5024 Error Codes/Subcodes: There is a 2 byte error code and 1 byte 5025 subcode in the Value field of the Error object (Appendix A.4.1). 5026 Error codes 1-12 are defined in Appendix A.4.4 together with 5027 subcodes 0-5 (code 1), 0-5 (code 9), 0-5 (code 10), and 0-2 (code 5028 12). Additional codes and subcodes are allocated on a first-come, 5029 first-served basis. When a new code/subcode combination is 5030 allocated, the following information MUST be provided: 5032 Error case: textual name of error 5034 Error class: from the categories given in Appendix A.4.3 5036 Error code: allocated by IANA, if a new code is required 5038 Error subcode: subcode point, also allocated by IANA 5040 Additional information: what additional information fields it is 5041 mandatory to include in the error message, from Appendix A.4.2 5043 Additional Information Types: An Error object (Appendix A.4.1) may 5044 contain Additional Information fields. Each possible field type 5045 is identified by a 16-bit AI-Type. AI-Types 1-4 are defined in 5046 Appendix A.4.2; additional AI-Types are allocated on a first-come, 5047 first-served basis. 5049 10. Acknowledgements 5051 This document is based on the discussions within the IETF NSIS 5052 working group. It has been informed by prior work and formal and 5053 informal inputs from: Cedric Aoun, Attila Bader, Roland Bless, Bob 5054 Braden, Marcus Brunner, Benoit Campedel, Yoshiko Chong, Luis 5055 Cordeiro, Elwyn Davies, Christian Dickmann, Pasi Eronen, Alan Ford, 5056 Xiaoming Fu, Bo Gao, Ruediger Geib, Eleanor Hepworth, Thomas Herzog, 5057 Cheng Hong, Teemu Huovila, Jia Jia, Cornelia Kappler, Georgios 5058 Karagiannis, Ruud Klaver, Chris Lang, John Loughney, Allison Mankin, 5059 Jukka Manner, Pete McCann, Andrew McDonald, Glenn Morrow, Dave Oran, 5060 Andreas Pashalidis, Henning Peters, Tom Phelan, Akbar Rahman, Takako 5061 Sanda, Charles Shen, Melinda Shore, Martin Stiemerling, Martijn 5062 Swanink, Mike Thomas, Hannes Tschofenig, Sven van den Bosch, Michael 5063 Welzl, Lars Westberg, and Mayi Zoumaro-djayoon. Parts of the TLS 5064 usage description (Section 5.7.3) were derived from the Diameter base 5065 protocol specification, RFC3588. In addition, Hannes Tschofenig 5066 provided a detailed set of review comments on the security section, 5067 and Andrew McDonald provided the formal description for the initial 5068 packet formats and the name matching algorithm for TLS. Chris Lang's 5069 implementation work provided objective feedback on the clarity and 5070 feasibility of the specification, and he also provided the state 5071 machine description and the initial error catalogue and formats. 5072 Magnus Westerlund carried out a detailed AD review which identified a 5073 number of issues and led to significant clarifications, which was 5074 followed by an even more detailed IESG review, with comments from 5075 Jari Arkko, Ross Callon, Brian Carpenter, Lisa Dusseault, Lars 5076 Eggert, Ted Hardie, Sam Hartman, Russ Housley, Cullen Jennings, and a 5077 very detailed analysis by Adrian Farrel from the Routing Area 5078 directorate. 5080 11. References 5082 11.1. Normative References 5084 [1] Braden, R., "Requirements for Internet Hosts - Communication 5085 Layers", STD 3, RFC 1122, October 1989. 5087 [2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 5088 June 1995. 5090 [3] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 5092 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 5093 Levels", BCP 14, RFC 2119, March 1997. 5095 [5] Schiller, J., "Cryptographic Algorithms for Use in the Internet 5096 Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005. 5098 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 5099 Considerations Section in RFCs", BCP 26, RFC 2434, 5100 October 1998. 5102 [7] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 5103 the Differentiated Services Field (DS Field) in the IPv4 and 5104 IPv6 Headers", RFC 2474, December 1998. 5106 [8] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 5107 RFC 2711, October 1999. 5109 [9] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 5110 RFC 2765, February 2000. 5112 [10] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 5113 Public Key Infrastructure Certificate and Certificate 5114 Revocation List (CRL) Profile", RFC 3280, April 2002. 5116 [11] Narten, T., "Assigning Experimental and Testing Numbers 5117 Considered Useful", BCP 82, RFC 3692, January 2004. 5119 [12] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 5120 Specifications: ABNF", RFC 4234, October 2005. 5122 [13] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 5123 Protocol Version 1.1", RFC 4346, April 2006. 5125 [14] Loughney, J., "NSIS Extensibility Model", 5126 draft-loughney-nsis-ext-02 (work in progress), March 2006. 5128 11.2. Informative References 5130 [15] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 5131 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 5132 Specification", RFC 2205, September 1997. 5134 [16] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 5135 RFC 2246, January 1999. 5137 [17] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 5139 [18] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP 5140 Operation Over IP Tunnels", RFC 2746, January 2000. 5142 [19] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 5143 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 5145 [20] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 5146 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 5147 Paxson, "Stream Control Transmission Protocol", RFC 2960, 5148 October 2000. 5150 [21] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 5151 IPv4 Clouds", RFC 3056, February 2001. 5153 [22] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 5154 RFC 3068, June 2001. 5156 [23] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 5157 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 5158 September 2001. 5160 [24] Grossman, D., "New Terminology and Clarifications for 5161 Diffserv", RFC 3260, April 2002. 5163 [25] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 5164 Haukka, "Security Mechanism Agreement for the Session 5165 Initiation Protocol (SIP)", RFC 3329, January 2003. 5167 [26] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 5168 - Simple Traversal of User Datagram Protocol (UDP) Through 5169 Network Address Translators (NATs)", RFC 3489, March 2003. 5171 [27] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 5172 Underneath NAT (STUN)", draft-ietf-behave-turn-03 (work in 5173 progress), March 2007. 5175 [28] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 5176 Security Mechanism (GTSM)", RFC 3682, February 2004. 5178 [29] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, 5179 July 2004. 5181 [30] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 5182 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 5183 June 2005. 5185 [31] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 5186 Steps in Signaling (NSIS)", RFC 4081, June 2005. 5188 [32] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 5189 Requirements for Security", BCP 106, RFC 4086, June 2005. 5191 [33] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 5192 Transport Layer Security (TLS)", RFC 4279, December 2005. 5194 [34] Conta, A., Deering, S., and M. Gupta, "Internet Control Message 5195 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 5196 Specification", RFC 4443, March 2006. 5198 [35] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 5199 (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in progress), 5200 March 2007. 5202 [36] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 5203 IPv6 Hosts and Routers", RFC 4213, October 2005. 5205 [37] Kent, S. and K. Seo, "Security Architecture for the Internet 5206 Protocol", RFC 4301, December 2005. 5208 [38] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 5209 Nordmark, "Mobile IP Version 6 Route Optimization Security 5210 Design Background", RFC 4225, December 2005. 5212 [39] Audet, F. and C. Jennings, "Network Address Translation (NAT) 5213 Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, 5214 January 2007. 5216 [40] Floyd, S. and V. Jacobson, "The Synchronisation of Periodic 5217 Routing Messages", SIGCOMM Symposium on Communications 5218 Architectures and Protocols pp. 33--44, September 1993. 5220 [41] Pashalidis, A. and H. Tschofenig, "GIST Legacy NAT Traversal", 5221 draft-pashalidis-nsis-gist-legacynats-01 (work in progress), 5222 March 2007. 5224 [42] Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal", 5225 draft-pashalidis-nsis-gimps-nattraversal-04 (work in progress), 5226 March 2007. 5228 [43] Tschofenig, H., "GIST State Machine", 5229 draft-ietf-nsis-ntlp-statemachine-03 (work in progress), 5230 March 2007. 5232 [44] Ramaiah, A., "Improving TCP's Robustness to Blind In-Window 5233 Attacks", draft-ietf-tcpm-tcpsecure-07 (work in progress), 5234 February 2007. 5236 Appendix A. Bit-Level Formats and Error Messages 5238 This appendix provides formats for the various component parts of the 5239 GIST messages defined abstractly in Section 5.2. The whole of this 5240 appendix is normative. 5242 Each GIST message consists of a header and a sequence of objects. 5243 The GIST header has a specific format, described in more detail in 5244 Appendix A.1 below. An NSLP message is one object within a GIST 5245 message. Note that GIST itself provides the NSLP message length 5246 information and signalling application identification. General 5247 object formatting guidelines are provided in Appendix A.2 below, 5248 followed in Appendix A.3 by the format for each object. Finally, 5249 Appendix A.4 provides the formats used for error reporting. 5251 In the following object diagrams, '//' is used to indicate a variable 5252 sized field and ':' is used to indicate a field that is optionally 5253 present. 5255 A.1. The GIST Common Header 5257 This header begins all GIST messages. It has a fixed format, as 5258 shown below. 5260 0 1 2 3 5261 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 5262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5263 | Version | GIST hops | Message Length | 5264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5265 | NSLPID | Type |S|R|E| Reserved| 5266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5268 Version (8 bits): The GIST protocol version number. 5270 GIST hops (8 bits): A hop count for the number of GIST-aware nodes 5271 this message can still be processed by (including the 5272 destination). 5274 Message Length (16 bits): The total number of 32-bit words in the 5275 message after the common header itself. 5277 NSLPID (16 bits): IANA assigned identifier of the signalling 5278 application the message refers to. 5280 Type (8 bits): The GIST message type (Query, Response, etc.). 5282 S flag: S=1 if the IP source address is the same as the signalling 5283 source address, S=0 if it is different. 5285 R flag: R=1 if a reply to this message is explicitly requested. 5287 E flag: E=1 if the message was explicitly routed (Section 7.1.5). 5289 The rules governing the use of the R-flag depend on the GIST message 5290 type. It MUST always be set (R=1) in Query messages, since these 5291 always elicit a Response, and never in Confirm, Data or Error 5292 messages. It MAY be set in an MA-Hello; if set, another MA-Hello 5293 MUST be sent in reply. It MAY be set in a Response, but MUST be set 5294 if the Response contains a Responder cookie; if set, a Confirm MUST 5295 be sent in reply. The E flag MUST NOT be set unless the message type 5296 is a Data message. 5298 Parsing failures may be caused by unknown Version or Type values, 5299 inconsistent R or E flag setting, or a Message Length inconsistent 5300 with the set of objects carried. In all cases the receiver MUST if 5301 possible return a "Common Header Parse Error" message 5302 (Appendix A.4.4.1) with the appropriate subcode, and not process the 5303 message further. 5305 A.2. General Object Format 5307 Each object begins with a fixed header giving the object Type and 5308 object Length. This is followed by the object Value, which is a 5309 whole number of 32-bit words long. 5311 0 1 2 3 5312 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 5313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5314 |A|B|r|r| Type |r|r|r|r| Length | 5315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5316 // Value // 5317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5319 A/B flags: The bits marked 'A' and 'B' are extensibility flags which 5320 are defined in Appendix A.2.1 below; the remaining bits marked 'r' 5321 are reserved. 5323 Type (12 bits): An IANA-assigned identifier for the type of object. 5325 Length (12 bits): Length has the units of 32-bit words, and measures 5326 the length of Value. If there is no Value, Length=0. If the 5327 Length is not consistent with the contents of the object, an 5328 "Object Value Error" message (Appendix A.4.4.10) with subcode 0 5329 "Incorrect Length" MUST be returned and the message dropped. 5331 Value (variable): Value is (therefore) a whole number of 32 bit 5332 words. If there is any padding required, the length and location 5333 are be defined by the object-specific format information; objects 5334 which contain variable length (e.g. string) types may need to 5335 include additional length subfields to do so. 5337 Any part of the object used for padding or defined as reserved 5338 (marked 'Reserved' or 'Rsv' or, in the case of individual bits, 'r' 5339 in the diagrams below) MUST be set to 0 on transmission and MUST be 5340 ignored on reception. 5342 A.2.1. Object Extensibility 5344 The leading two bits of the TLV header are used to signal the desired 5345 treatment for objects whose Type field is unknown at the receiver. 5346 The following three categories of object have been identified, and 5347 are described here. 5349 AB=00 ("Mandatory"): If the object is not understood, the entire 5350 message containing it MUST be rejected with an "Object Type Error" 5351 message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object"). 5353 AB=01 ("Ignore"): If the object is not understood, it MUST be 5354 deleted and the rest of the message processed as usual. 5356 AB=10 ("Forward"): If the object is not understood, it MUST be 5357 retained unchanged in any message forwarded as a result of message 5358 processing, but not stored locally. 5360 The combination AB=11 is reserved. If a message is received 5361 containing an object with AB=11, it MUST be rejected with an "Object 5362 Type Error" message (Appendix A.4.4.9) with subcode 5 ("Invalid 5363 Extensibility Flags"). 5365 These extensibility rules define only the processing within the GIST 5366 layer. There is no requirement on GIST implementations to support an 5367 extensible service interface to signalling applications, so 5368 unrecognised objects with AB=01 or AB=10 do not need to be indicated 5369 to NSLPs. If a new GIST object is defined which requires such an 5370 interaction, it should be specified with AB=11. 5372 A.3. GIST TLV Objects 5374 A.3.1. Message-Routing-Information 5375 Type: Message-Routing-Information 5377 Length: Variable (depends on MRM) 5379 0 1 2 3 5380 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 5381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5382 | MRM-ID |N| Reserved | | 5383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 5384 // Method-specific addressing information (variable) // 5385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5387 MRM-ID (8 bits): An IANA-assigned identifier for the message routing 5388 method. 5390 N flag: If set (N=1), this means that NATs do not need to translate 5391 this MRM; if clear (N=0) it means that the method-specific 5392 information contains network or transport layer information that a 5393 NAT must process. 5395 The remainder of the object contains method-specific addressing 5396 information, which is described below. 5398 A.3.1.1. Path-Coupled MRM 5400 In the case of basic path-coupled routing, the addressing information 5401 takes the following format. The N-flag N=0 for this MRM. 5403 0 1 2 3 5404 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 5405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5406 |IP-Ver |P|T|F|S|A|B|D|Reserved | 5407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5408 // Source Address // 5409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5410 // Destination Address // 5411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5412 | Source Prefix | Dest Prefix | Protocol | DS-field |Rsv| 5413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5414 : Reserved | Flow Label : 5415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5416 : SPI : 5417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5418 : Source Port : Destination Port : 5419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5420 IP-Ver (4 bits): The IP version number, 4 or 6. 5422 Source/Destination address (variable): The source and destination 5423 addresses are always present and of the same type; their length 5424 depends on the value in the IP-Ver field. 5426 Source/Dest Prefix (each 8 bits): The length of the mask to be 5427 applied to the source and destination addresses for address 5428 wildcarding. In the normal case where the MRI refers only to 5429 traffic between specific host addresses, the Source/Dest Prefix 5430 values would both be 32/128 for IPv4/6 respectively. 5432 P flag: P=1 means that the Protocol field is significant. 5434 Protocol (8 bits): The IP protocol number. This MUST be ignored if 5435 P=0. In the case of IPv6, the Protocol field refers to the true 5436 upper layer protocol carried by the packets, i.e. excluding any IP 5437 option headers. This is therefore not necessarily the same as the 5438 Next Header value from the base IPv6 header. 5440 T flag: T=1 means that DiffServ field (DS-field) is significant. 5442 DS-field (6 bits): The DiffServ field. See [7] and [24]. 5444 F flag: F=1 means that flow label is present and is significant. F 5445 MUST NOT be set if IP-Ver is not 6. 5447 Flow Label (20 bits): The flow label; only present if F=1. If F=0, 5448 the entire 32 bit word containing the Flow Label is absent. 5450 S flag: S=1 means that the SPI field is present and is significant. 5451 The S flag MUST be 0 if the P flag is 0. 5453 SPI field (32 bits): The SPI field; see [37]. If S=0, the entire 32 5454 bit word containing the SPI is absent. 5456 A/B flags: These can only be set if P=1. If either is set, the port 5457 fields are also present. If P=0, the A/B flags MUST both be zero 5458 and the word containing the port numbers is absent. 5460 Source/Destination Port (each 16 bits): If either of A (source), B 5461 (destination) is set the word containing the port numbers is 5462 included in the object. However, the contents of each field is 5463 only significant if the corresponding flag is set; otherwise, the 5464 contents of the field is regarded as padding, and the MRI refers 5465 to all ports (i.e. acts as a wildcard). If the flag is set and 5466 Port=0x0000, the MRI will apply to a specific port, whose value is 5467 not yet known. If neither of A or B is set, the word is absent. 5469 D flag: The Direction flag has the following meaning: the value 0 5470 means 'in the same direction as the flow' (i.e. downstream), and 5471 the value 1 means 'in the opposite direction to the flow' (i.e. 5472 upstream). 5474 The MRI format defines a number of constraints on the allowed 5475 combinations of flags and fields in the object. If these constraints 5476 are violated this constitutes a parse error, and an "Object Value 5477 Error" message (Appendix A.4.4.10) with subcode 2 ("Invalid Flag- 5478 Field Combination") MUST be returned. 5480 A.3.1.2. Loose-End MRM 5482 In the case of the loose-end MRM, the addressing information takes 5483 the following format. The N-flag N=0 for this MRM. 5485 0 1 2 3 5486 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 5487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5488 |IP-Ver |D| Reserved | 5489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5490 // Source Address // 5491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5492 // Destination Address // 5493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5495 IP-Ver (4 bits): The IP version number, 4 or 6. 5497 Source/Destination address (variable): The source and destination 5498 addresses are always present and of the same type; their length 5499 depends on the value in the IP-Ver field. 5501 D flag: The Direction flag has the following meaning: the value 0 5502 means 'towards the edge of the network', and the value 1 means 5503 'from the edge of the network'. Note that for Q-mode messages, 5504 the only valid value is D=0 (see Section 5.8.2). 5506 A.3.2. Session Identification 5508 Type: Session-Identification 5510 Length: Fixed (4 32-bit words) 5511 0 1 2 3 5512 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 5513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5514 | | 5515 + + 5516 | | 5517 + Session ID + 5518 | | 5519 + + 5520 | | 5521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5523 A.3.3. Network-Layer-Information 5525 Type: Network-Layer-Information 5527 Length: Variable (depends on length of Peer-Identity and IP version) 5529 0 1 2 3 5530 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 5531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5532 | PI-Length | IP-TTL |IP-Ver | Reserved | 5533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5534 | Routing State Validity Time | 5535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5536 // Peer Identity // 5537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5538 // Interface Address // 5539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5541 PI-Length (8 bits): The byte length of the Peer Identity field. 5543 Peer Identity (variable): The Peer Identity field. Note that the 5544 Peer-Identity field itself is padded to a whole number of words. 5546 IP-TTL (8 bits): Initial or reported IP layer TTL. 5548 IP-Ver (4 bits): The IP version for the Interface Address field. 5550 Interface Address (variable): The IP address allocated to the 5551 interface, matching the IP-Ver field. 5553 Routing State Validity Time (32 bits): The time for which the 5554 routing state for this flow can be considered correct without a 5555 refresh. Given in milliseconds. The value 0 (zero) is reserved 5556 and MUST NOT be used. 5558 A.3.4. Stack Proposal 5560 Type: Stack-Proposal 5562 Length: Variable (depends on number of profiles and size of each 5563 profile) 5565 0 1 2 3 5566 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 5567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5568 | Prof-Count | Reserved | 5569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5570 // Profile 1 // 5571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5572 : : 5573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5574 // Profile N // 5575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5576 Prof-Count (8 bits): The number of profiles listed. MUST be > 0. 5578 Each profile is itself a sequence of protocol layers, and the profile 5579 is formatted as a list as follows: 5581 o The first byte is a count of the number of layers in the profile. 5582 MUST be > 0. 5584 o This is followed by a sequence of 1-byte MA-Protocol-IDs as 5585 described in Section 5.7. 5587 o The profile is padded to a word boundary with 0, 1, 2 or 3 zero 5588 bytes. These bytes MUST be ignored at the receiver. 5590 If there are no profiles (Prof-Count=0) then an "Object Value Error" 5591 message (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") 5592 MUST be returned; if a particular profile is empty (the leading byte 5593 of the profile is zero), then subcode 3 ("Empty List") MUST be used. 5594 In both cases, the message MUST be dropped. 5596 A.3.5. Stack-Configuration-Data 5598 Type: Stack-Configuration-Data 5600 Length: Variable (depends on number of protocols and size of each 5601 MA-protocol-options field) 5603 0 1 2 3 5604 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 5605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5606 | MPO-Count | Reserved | 5607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5608 | MA-Hold-Time | 5609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5610 // MA-protocol-options 1 // 5611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5612 : : 5613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5614 // MA-protocol-options N // 5615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5617 MPO-Count (8 bits): The number of MA-protocol-options fields present 5618 (these contain their own length information). The MPO-Count MAY 5619 be zero, but this will only be the case if none of the MA- 5620 protocols referred to in the Stack-Proposal require option data. 5622 MA-Hold-Time (32 bits): The time for which the messaging association 5623 will be held open without traffic or a hello message. Note that 5624 this value is given in milliseconds, so the default time of 30 5625 seconds (Section 4.4.5) corresponds to a value of 30000. The 5626 value 0 (zero) is reserved and MUST NOT be used. 5628 The MA-protocol-options fields are formatted as follows: 5630 0 1 2 3 5631 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 5632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5633 |MA-Protocol-ID | Profile | Length |D| Reserved | 5634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5635 // Options Data // 5636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5638 MA-Protocol-ID (8 bits): Protocol identifier as described in 5639 Section 5.7. 5641 Profile (8 bits): Tag indicating which profile from the accompanying 5642 Stack-Proposal object this applies to. Profiles are numbered from 5643 1 upwards; the special value 0 indicates 'applies to all 5644 profiles'. 5646 Length (8 bits): The byte length of MA-protocol-options field that 5647 follows. This will be zero-padded up to the next word boundary. 5649 D flag: If set (D=1), this protocol MUST NOT be used for a messaging 5650 association. 5652 Options Data (variable): Any options data for this protocol. Note 5653 that the format of the options data might differ depending on 5654 whether the field is in a Query or Response. 5656 A.3.6. Query Cookie 5658 Type: Query-Cookie 5660 Length: Variable (selected by querying node) 5662 0 1 2 3 5663 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 5664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5665 // Query Cookie // 5666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5668 The contents are implementation defined. See Section 8.5 for further 5669 discussion. 5671 A.3.7. Responder Cookie 5673 Type: Responder-Cookie 5675 Length: Variable (selected by responding node) 5677 0 1 2 3 5678 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 5679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5680 // Responder Cookie // 5681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5683 The contents are implementation defined. See Section 8.5 for further 5684 discussion. 5686 A.3.8. Hello-ID 5688 Type: Hello-ID 5690 Length: Fixed (1 32-bit word) 5691 0 1 2 3 5692 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 5693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5694 | Hello-ID | 5695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5697 The contents are implementation defined. See Section 5.2.2 for 5698 further discussion. 5700 A.3.9. NAT Traversal 5702 Type: NAT-Traversal 5704 Length: Variable (depends on length of contained fields) 5706 This object is used to support the NAT traversal mechanisms described 5707 in Section 7.2.2. 5709 0 1 2 3 5710 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 5711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5712 | MRI-Length | Type-Count | NAT-Count | Reserved | 5713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5714 // Original Message-Routing-Information // 5715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5716 // List of translated objects // 5717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5718 | Length of opaque information | | 5719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 5720 // Information replaced by NAT #1 | 5721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5722 : : 5723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5724 | Length of opaque information | | 5725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 5726 // Information replaced by NAT #N | 5727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5729 MRI-Length (8 bits): The length of the included MRI payload in 32- 5730 bit words. 5732 Original Message-Routing-Information (variable): The MRI data from 5733 when the message was first sent, not including the object header. 5735 Type-Count (8 bits): The number of objects in the 'List of 5736 translated objects' field. 5738 List of translated objects (variable): This field lists the types of 5739 the objects that were translated by every NAT through which the 5740 message has passed. Each element in the list is a 16-bit field 5741 containing the first 16 bits of the object TLV header, including 5742 the AB extensibility flags, two reserved bits, and 12 bit object 5743 type. The list is initialised by the first NAT on the path; 5744 subsequent NATs may delete elements in the list. Padded with 2 5745 null bytes if necessary. 5747 NAT-Count (8 bits): The number of NATs traversed by the message, and 5748 the number of opaque payloads at the end of the object. The 5749 length fields for each opaque payload are byte counts, not 5750 including the 2 bytes of the length field itself. Note that each 5751 opaque information field is zero-padded to the next 32-bit word 5752 boundary if necessary. 5754 A.3.10. NSLP Data 5756 Type: NSLP-Data 5758 Length: Variable (depends on NSLP) 5760 This object is used to deliver data between NSLPs. GIST regards the 5761 data as a number of complete 32-bit words, as given by the length 5762 field in the TLV; any padding to a word boundary must be carried out 5763 within the NSLP itself. 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 // NSLP Data // 5769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5771 A.4. Errors 5773 A.4.1. Error Object 5775 Type: Error 5777 Length: Variable (depends on error) 5778 0 1 2 3 5779 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 5780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5781 | Error Class | Error Code | Error Subcode | 5782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5783 |S|M|C|D|Q| Reserved | MRI Length | Info Count | 5784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5785 | | 5786 + Common Header + 5787 | (of original message) | 5788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5789 : Session Id : 5790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5791 : Message Routing Information : 5792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5793 : Additional Information Fields : 5794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5795 : Debugging Comment : 5796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5798 The flags are: 5799 S - S=1 means the Session ID object is present 5800 M - M=1 means MRI object is present 5801 C - C=1 means a debug Comment is present after header. 5802 D - D=1 means the original message was received in D-mode 5803 Q - Q=1 means the original message was received Q-mode encapsulated 5804 (can't be set if D=0). 5806 A GIST Error object contains an 8 bit error-class (see 5807 Appendix A.4.3), a 16 bit error-code, an 8 bit error-subcode, and as 5808 much information about the message which triggered the error as is 5809 available. This information MUST include the Common header of the 5810 original message and MUST also include the Session Id and MRI objects 5811 if these could be decoded correctly. These objects are included in 5812 their entirety, except for their TLV Headers. The MRI Length field 5813 gives the length of the MRI object in 32-bit words. 5815 The Info Count field contains the number of Additional Information 5816 fields in the object, and the possible formats for these fields are 5817 given in Appendix A.4.2. The precise set of fields to include 5818 depends on the error code/subcode. For every error description in 5819 the error catalogue Appendix A.4.4, the line "Additional Info:" 5820 states what fields MUST be included; further fields beyond these MAY 5821 be included by the sender, and the fields may be included in any 5822 order. The Debugging Comment is a null- terminated UTF-8 string, 5823 padded if necessary to a whole number of 32- bit words with more null 5824 characters. 5826 A.4.2. Additional Information Fields 5828 The Common Error Header may be followed by some Additional 5829 Information fields. Each Additional Information field has a simple 5830 TLV format as follows: 5831 0 1 2 3 5832 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 5833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5834 | AI-Type | AI-Length | 5835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5836 // AI-Value // 5837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5839 The AI-Type is a 16-bit IANA assigned value. The AI-Length gives the 5840 number of 32-bit words in AI-Value; if an AI-Value is not present, 5841 AI-Length=0. The AI-Types and AI-Lengths and AI-Value formats of the 5842 currently defined Additional Information fields are shown below. 5844 Message Length Info: 5845 0 1 2 3 5846 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 5847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5848 | Calculated Length | Reserved | 5849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5850 AI-Type: 1 5851 AI-Length: 1 5852 Calculated Length (16 bits): the length of the original message 5853 calculated by adding up all the objects in the message. Measured in 5854 32-bit words. 5856 MTU Info: 5857 0 1 2 3 5858 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 5859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5860 | Link MTU | Reserved | 5861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5862 AI-Type: 2 5863 AI-Length: 1 5864 Link MTU (16 bits): the IP MTU for a link along which a message 5865 could not be sent. Measured in bytes. 5867 Object Type Info: 5869 0 1 2 3 5870 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 5871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5872 | Object Type | Reserved | 5873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5874 AI-Type: 3 5875 AI-Length: 1 5876 Object type (16 bits): This provides information about the type 5877 of object which caused the error. 5879 Object Value Info: 5880 0 1 2 3 5881 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 5882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5883 | Rsv | Real Object Length | Offset | 5884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5885 // Object // 5886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5887 AI-Type: 4 5888 AI-Length: variable (depends on Object length) 5889 This object carries information about a TLV object which was found 5890 to be invalid in the original message. An error message MAY contain 5891 more than one Object Value Info object. 5893 Real Object Length (12 bits) Since the length in the original TLV 5894 header may be inaccurate, this field provides the actual length of 5895 the object (including the TLV Header) included in the error 5896 message. Measured in 32-bit words. 5898 Offset (16 bits): The byte in the object at which the GIST node 5899 found the error. The first byte in the object has offset=0. 5901 Object (variable): The invalid TLV object (including the TLV 5902 Header). 5904 A.4.3. Error Classes 5906 The first byte of the error object, "Error Class", indicates the 5907 severity level. The currently defined severity levels are: 5909 0 (Informational): reply data which should not be thought of as 5910 changing the condition of the protocol state machine. 5912 1 (Success): reply data which indicates that the message being 5913 responded to has been processed successfully in some sense. 5915 2 (Protocol-Error): the message has been rejected because of a 5916 protocol error (e.g. an error in message format). 5918 3 (Transient-Failure): the message has been rejected because of a 5919 particular local node status which may be transient (i.e. it may 5920 be worthwhile to retry after some delay). 5922 4 (Permanent-Failure): the message has been rejected because of 5923 local node status which will not change without additional out of 5924 band (e.g. management) operations. 5926 Additional error class values are reserved. 5928 The allocation of error classes to particular errors is not precise; 5929 the above descriptions are deliberately informal. Actual error 5930 processing SHOULD take into account the specific error in question; 5931 the error class may be useful supporting information (e.g. in network 5932 debugging). 5934 A.4.4. Error Catalogue 5936 This section lists all the possible GIST errors, including when they 5937 are raised and what additional information fields MUST be carried in 5938 the error object. 5940 A.4.4.1. Common Header Parse Error 5942 Class: Protocol-Error 5943 Code: 1 5944 Additional Info: For subcode 3 only, Message Length Info carries 5945 the calculated message length. 5947 This message is sent if a GIST node receives a message where the 5948 common header cannot be parsed correctly, or where an error in the 5949 overall message format is detected. Note that in this case the 5950 original MRI and Session ID MUST NOT be included in the Error Object. 5951 This error code is split into subcodes as follows: 5953 0: Unknown Version: The GIST version is unknown. The (highest) 5954 supported version supported by the node can be inferred from the 5955 Common Header of the Error message itself. 5957 1: Unknown Type: The GIST message type is unknown. 5959 2: Invalid R-flag: The R flag in the header is inconsistent with the 5960 message type. 5962 3: Incorrect Message Length: The overall message length is not 5963 consistent with the set of objects carried. 5965 4: Invalid E-flag: The E flag is set in the header but this is not a 5966 Data message. 5968 5: Missing Magic Number A D-mode message directly addressed to this 5969 node (with the normal or Q-mode encapsulation) did not begin with 5970 the correct magic number. 5972 A.4.4.2. Hop Limit Exceeded 5974 Class: Permanent-Failure 5975 Code: 2 5976 Additional Info: None 5978 This message is sent if a GIST node receives a message with a GIST 5979 hop count of zero, or a GIST node tries to forward a message after 5980 its GIST hop count has been decremented to zero on reception. This 5981 message indicates either a routing loop or too small an initial hop 5982 count value. 5984 A.4.4.3. Incorrect Encapsulation 5986 Class: Protocol-Error 5987 Code: 3 5988 Additional Info: None 5990 This message is sent if a GIST node receives a message which uses an 5991 incorrect encapsulation method (e.g. a Query arrives over an MA). 5993 A.4.4.4. Incorrectly Delivered Message 5995 Class: Protocol-Error 5996 Code: 4 5997 Additional Info: None 5999 This message is sent if a GIST node receives a message over an MA 6000 which is not associated with the MRI/NSLPID/SID combination in the 6001 message. 6003 A.4.4.5. No Routing State 6005 Class: Protocol-Error 6006 Code: 5 6007 Additional Info: None 6009 This message is sent if a node receives a message for which routing 6010 state should exist, but has not yet been created and thus there is no 6011 appropriate Querying-SM or Responding-SM. This can occur on 6012 receiving a Data or Confirm message at a node whose policy requires 6013 routing state to exist before such messages can be accepted. See 6014 also Section 6.1 and Section 6.3. 6016 A.4.4.6. Unknown NSLPID 6018 Class: Permanent-Failure 6019 Code: 6 6020 Additional Info: None 6022 This message is sent if a router receives a directly addressed 6023 message for an NSLP which it does not support. 6025 A.4.4.7. Endpoint Found 6027 Class: Permanent-Failure 6028 Code: 7 6029 Additional Info: None 6031 This message is sent if a GIST node at a flow endpoint receives a 6032 Query message for an NSLP which it does not support. 6034 A.4.4.8. Message Too Large 6036 Class: Permanent-Failure 6037 Code: 8 6038 Additional Info: MTU Info 6040 A router receives a message which it can't forward because it exceeds 6041 the IP MTU on the next or subsequent hops. 6043 A.4.4.9. Object Type Error 6045 Class: Protocol-Error 6046 Code: 9 6047 Additional Info: Object Type Info 6049 This message is sent if a GIST node receives a message containing a 6050 TLV object with an invalid type. The message indicates the object 6051 type at fault in the additional info field. This error code is split 6052 into subcodes as follows: 6054 0: Duplicate Object: This subcode is used if a GIST node receives a 6055 message containing multiple instances of an object which may only 6056 appear once in a message. In the current specification, this 6057 applies to all objects. 6059 1: Unrecognised Object: This subcode is used if a GIST node receives 6060 a message containing an object which it does not support, and the 6061 extensibility flags AB=00. 6063 2: Missing Object: This subcode is used if a GIST node receives a 6064 message which is missing one or more mandatory objects. This 6065 message is also sent if a Stack-Proposal is sent without a 6066 matching Stack-Configuration-Data object when one was necessary, 6067 or vice versa. 6069 3: Invalid Object Type: This subcode is used if the object type is 6070 known, but it is not valid for this particular GIST message type. 6072 4: Untranslated Object: This subcode is used if the object type is 6073 known and is mandatory to interpret, but it contains addressing 6074 data which has not been translated by an intervening NAT. 6076 5: Invalid Extensibility Flags: This subcode is used if an object is 6077 received with the extensibility flags AB=11. 6079 A.4.4.10. Object Value Error 6081 Class: Protocol-Error 6082 Code: 10 6083 Additional Info: 1 or 2 Object Value Info fields as given below 6085 This message is sent if a node receives a message containing an 6086 object which cannot be properly parsed. The error message contains a 6087 single Object Value Info object, except for subcode 5 as stated 6088 below. This error code is split into subcodes as follows: 6090 0: Incorrect Length: The overall length does not match the object 6091 length calculated from the object contents. 6093 1: Value Not Supported: The value of a field is not supported by the 6094 GIST node. 6096 2: Invalid Flag-Field Combination: An object contains an invalid 6097 combination of flags and/or fields. At the moment this only 6098 relates to the Path-Coupled MRI (Appendix A.3.1.1), but in future 6099 there may be more. 6101 3: Empty List: At the moment this only relates to Stack-Proposals. 6102 The error message is sent if a stack proposal with a length > 0 6103 contains only null bytes (a length of 0 is handled as "Value Not 6104 Supported"). 6106 4: Invalid Cookie: The message contains a cookie which could not be 6107 verified by the node. 6109 5: Stack-Proposal - Stack-Configuration-Data Mismatch: This subcode 6110 is used if a GIST node receives a message in which the data in the 6111 Stack-Proposal object is inconsistent with the information in the 6112 Stack Configuration Data object. In this case, both the Stack- 6113 Proposal object and Stack-Configuration-Data object MUST be 6114 included in separate Object Value Info fields in that order. 6116 A.4.4.11. Invalid IP layer TTL 6118 Class: Permanent-Failure 6119 Code: 11 6120 Additional Info: None 6122 This error indicates that a message was received with an IP layer TTL 6123 outside an acceptable range; for example, that an upstream Query was 6124 received with an IP layer TTL of less than 254 (i.e. more than one IP 6125 hop from the sender). The actual IP distance can be derived from the 6126 IP-TTL information in the NLI object carried in the same message. 6128 A.4.4.12. MRI Validation Failure 6130 Class: Permanent-Failure 6131 Code: 12 6132 Additional Info: Object Value Info 6134 This error indicates that a message was received with an MRI that 6135 could not be accepted, e.g. because of too much wildcarding or 6136 failing some validation check (cf. Section 5.8.1.2). The Object 6137 Value Info includes the MRI so the error originator can indicate the 6138 part of the MRI which caused the problem. The error code is divided 6139 into subcodes as follows: 6141 0: MRI Too Wild: The MRI contained too much wildcarding (e.g. too 6142 short a destination address prefix) to be forwarded correctly down 6143 a single path. 6145 1: IP Version Mismatch: The MRI in a path-coupled Query message 6146 refers to an IP version which is not implemented on the interface 6147 used, or is different from the IP version of the Query 6148 encapsulation (see Section 7.4). 6150 2: Ingress Filter Failure: The MRI in a path-coupled Query message 6151 describes a flow which would not pass ingress filtering on the 6152 interface used. 6154 Appendix B. API between GIST and Signalling Applications 6156 This appendix provides an abstract API between GIST and signalling 6157 applications. It should not constrain implementers, but rather help 6158 clarify the interface between the different layers of the NSIS 6159 protocol suite. In addition, although some of the data types carry 6160 the information from GIST information elements, this does not imply 6161 that the format of that data as sent over the API has to be the same. 6163 Conceptually the API has similarities to the sockets API, 6164 particularly that for unconnected UDP sockets. An extension for an 6165 API like that for UDP connected sockets could be considered. In this 6166 case, for example, the only information needed in a SendMessage 6167 primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle 6168 (which can be null). Other information which was persistent for a 6169 group of messages could be configured once for the socket. Such 6170 extensions may make a concrete implementation more efficient but do 6171 not change the API semantics, and so are not considered further here. 6173 B.1. SendMessage 6175 This primitive is passed from a signalling application to GIST. It 6176 is used whenever the signalling application wants to initiate sending 6177 a message. 6179 SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, 6180 NSLPID, Session-ID, MRI, SII-Handle, 6181 Transfer-Attributes, Timeout, IP-TTL, GIST-Hop-Count ) 6183 The following arguments are mandatory. 6185 NSLP-Data: The NSLP message itself. 6187 NSLP-Data-Size: The length of NSLP-Data. 6189 NSLP-Message-Handle: A handle for this message, that can be used by 6190 GIST as a reference in subsequent MessageStatus notifications 6191 (Appendix B.3). Notifications could be about error conditions or 6192 about the security attributes that will be used for the message. 6193 A NULL handle may be supplied if the NSLP is not interested in 6194 such notifications. 6196 NSLPID: An identifier indicating which NSLP this is. 6198 Session-ID: The NSIS session identifier. Note that it is assumed 6199 that the signalling application provides this to GIST rather than 6200 GIST providing a value itself. 6202 MRI: Message routing information for use by GIST in determining the 6203 correct next GIST hop for this message. The MRI implies the 6204 message routing method to be used and the message direction. 6206 The following arguments are optional: 6208 SII-Handle: A handle, previously supplied by GIST, to a data 6209 structure that should be used to route the message explicitly to a 6210 particular GIST next hop. 6212 Transfer-Attributes: Attributes defining how the message should be 6213 handled (see Section 4.1.2). The following attributes can be 6214 considered: 6216 Reliability: Values 'unreliable' or 'reliable'. 6218 Security: This attribute allows the NSLP to specify what level of 6219 security protection is requested for the message (such as 6220 'integrity' or 'confidentiality'), and can also be used to 6221 specify what authenticated signalling source and destination 6222 identities should be used to send the message. The 6223 possibilities can be learned by the signalling application from 6224 prior MessageStatus or RecvMessage notifications. If an NSLP- 6225 Message-Handle is provided, GIST will inform the signalling 6226 application of what values it has actually chosen for this 6227 attribute via a MessageStatus callback. This might take place 6228 either synchronously (where GIST is selecting from available 6229 messaging associations), or asynchronously (when a new 6230 messaging association needs to be created). 6232 Local Processing: This attribute contains hints from the 6233 signalling application about what local policy should be 6234 applied to the message; in particular, its transmission 6235 priority relative to other messages, or whether GIST should 6236 attempt to set up or maintain forward routing state. 6238 Timeout: Length of time GIST should attempt to send this message 6239 before indicating an error. 6241 IP-TTL: The value of the IP layer TTL that should be used when 6242 sending this message (may be overridden by GIST for particular 6243 messages). 6245 GIST-Hop-Count: The value for the hop count when sending the 6246 message. 6248 B.2. RecvMessage 6250 This primitive is passed from GIST to a signalling application. It 6251 is used whenever GIST receives a message from the network, including 6252 the case of null messages (zero length NSLP payload), typically 6253 initial Query messages. For Queries, the results of invoking this 6254 primitive are used by GIST to check whether message routing state 6255 should be created (see the discussion of the 'Routing-State-Check' 6256 argument below). 6258 RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLPID, Session-ID, MRI, 6259 Routing-State-Check, SII-Handle, Transfer-Attributes, 6260 IP-TTL, IP-Distance, GIST-Hop-Count, 6261 Inbound-Interface ) 6263 NSLP-Data: The NSLP message itself (may be empty). 6265 NSLP-Data-Size: The length of NSLP-Data (may be zero). 6267 NSLPID: An identifier indicating which NSLP this is message is for. 6269 Session-ID: The NSIS session identifier. 6271 MRI: Message routing information that was used by GIST in forwarding 6272 this message. Implicitly defines the message routing method that 6273 was used and the direction of the message relative to the MRI. 6275 Routing-State-Check: This boolean is True if GIST is checking with 6276 the signalling application to see if routing state should be 6277 created with the peer or the message should be forwarded further 6278 (see Section 4.3.2). If True, the signalling application should 6279 return the following values via the RecvMessage call: 6281 A boolean indicating whether to set up the state. 6283 Optionally, an NSLP-Payload to carry in the generated Response 6284 or forwarded Query respectively. 6286 This mechanism could be extended to enable the signalling 6287 application to indicate to GIST whether state installation should 6288 be immediate or deferred (see Section 5.3.3 and Section 6.3 for 6289 further discussion). 6291 SII-Handle: A handle to a data structure, identifying a peer address 6292 and interface. Can be used to identify route changes and for 6293 explicit routing to a particular GIST next hop. 6295 Transfer-Attributes: The reliability and security attributes that 6296 were associated with the reception of this particular message. As 6297 well as the attributes associated with SendMessage, GIST may 6298 indicate the level of verification of the addresses in the MRI. 6299 Three attributes can be indicated: 6301 * Whether the signalling source address is one of the flow 6302 endpoints (i.e. whether this is the first or last GIST hop); 6304 * Whether the signalling source address has been validated by a 6305 return routability check. 6307 * Whether the message was explicitly routed (and so has not been 6308 validated by GIST as delivered consistently with local routing 6309 state). 6311 IP-TTL: The value of the IP layer TTL this message was received with 6312 (if available). 6314 IP-Distance: The number of IP hops from the peer signalling node 6315 which sent this message along the path, or 0 if this information 6316 is not available. 6318 GIST-Hop-Count: The value of the hop count the message was received 6319 with, after being decremented in the GIST receive-side processing. 6321 Inbound-Interface: Attributes of the interface on which the message 6322 was received, such as whether it lies on the internal or external 6323 side of a NAT. These attributes have only local significance and 6324 are implementation defined. 6326 B.3. MessageStatus 6328 This primitive is passed from GIST to a signalling application. It 6329 is used to notify the signalling application that a message that it 6330 requested to be sent could not be dispatched, or to inform the 6331 signalling application about the transfer attributes that have been 6332 selected for the message (specifically, security attributes). The 6333 signalling application can respond to this message with a return code 6334 to abort the sending of the message if the attributes are not 6335 acceptable. 6337 MessageStatus (NSLP-Message-Handle, Transfer-Attributes, Error-Type) 6338 NSLP-Message-Handle: A handle for the message provided by the 6339 signalling application in SendMessage. 6341 Transfer-Attributes: The reliability and security attributes that 6342 will be used to transmit this particular message. 6344 Error-Type: Indicates the type of error that occurred. For example, 6345 'no next node found'. 6347 B.4. NetworkNotification 6349 This primitive is passed from GIST to a signalling application. It 6350 indicates that a network event of possible interest to the signalling 6351 application occurred. 6353 NetworkNotification ( NSLPID, MRI, Network-Notification-Type ) 6355 NSLPID: An identifier indicating which NSLP this is message is for. 6357 MRI: Provides the message routing information to which the network 6358 notification applies. 6360 Network-Notification-Type: Indicates the type of event that caused 6361 the notification and associated additional data. Five events have 6362 been identified: 6364 Last Node: GIST has detected that this is the last NSLP-aware 6365 node in the path. See Section 4.3.4. 6367 Routing Status Change: GIST has installed new routing state, has 6368 detected that existing routing state may no longer be valid, or 6369 has re-established existing routing state. See Section 7.1.3. 6370 The new status is reported; if the status is Good, the SII- 6371 Handle of the peer is also reported, as for RecvMessage. 6373 Route Deletion: GIST has determined that an old route is now 6374 definitely invalid, e.g. that flows are definitely not using it 6375 (see Section 7.1.4). The SII-Handle of the peer is also 6376 reported. 6378 Node Authorisation Change: The authorisation status of a peer has 6379 changed, meaning that routing state is no longer valid or that 6380 a signalling peer is no longer reachable; see Section 4.4.2. 6382 Communication Failure: Communication with the peer has failed; 6383 messages may have been lost. 6385 B.5. SetStateLifetime 6387 This primitive is passed from a signalling application to GIST. It 6388 indicates the duration for which the signalling application would 6389 like GIST to retain its routing state. It can also give a hint that 6390 the signalling application is no longer interested in the state. 6392 SetStateLifetime ( NSLPID, MRI, SID, State-Lifetime ) 6394 NSLPID: Provides the NSLPID to which the routing state lifetime 6395 applies. 6397 MRI: Provides the message routing information to which the routing 6398 state lifetime applies; includes the direction (in the D flag). 6400 SID: The session ID which the signalling application will be using 6401 with this routing state. Can be wildcarded. 6403 State-Lifetime: Indicates the lifetime for which the signalling 6404 application wishes GIST to retain its routing state (may be zero, 6405 indicating that the signalling application has no further interest 6406 in the GIST state). 6408 B.6. InvalidateRoutingState 6410 This primitive is passed from a signalling application to GIST. It 6411 indicates that the signalling application has knowledge that the next 6412 signalling hop known to GIST may no longer be valid, either because 6413 of changes in the network routing or the processing capabilities of 6414 signalling application nodes. See Section 7.1. 6416 InvalidateRoutingState ( NSLPID, MRI, Status, NSLP-Data, 6417 NSLP-Data-Size, Urgent ) 6419 NSLPID: The NSLP originating the message. May be null (in which 6420 case the invalidation applies to all signalling applications). 6422 MRI: The flow for which routing state should be invalidated; 6423 includes the direction of the change (in the D flag). 6425 Status: The new status that should be assumed for the routing state, 6426 one of Bad or Tentative (see Section 7.1.3). 6428 NSLP-Data, NSLP-Data-Size Optional: a payload provided by the NSLP 6429 to be used the next GIST handshake. This can be used as part of a 6430 conditional peering process (see Section 4.3.2). The payload will 6431 be transmitted without security protection. 6433 Urgent: A hint as to whether rediscovery should take place 6434 immediately, or only with the next signalling message. 6436 Appendix C. Deployment Issues with Router Alert Options 6438 The GIST peer discovery handshake (Section 4.4.1) depends on the 6439 interception of Q-mode encapsulated IP packets (Section 4.3.1 and 6440 Section 5.3.2) by routers. There are two fundamental requirements on 6441 the process: 6443 1. Packets relevant to GIST must be intercepted. 6445 2. Packets not relevant to GIST must be forwarded transparently. 6447 This specification defines the GIST behaviour to ensure that both 6448 requirements are met for a GIST-capable node. However, GIST packets 6449 will also encounter non-GIST nodes, for which requirement (2) still 6450 applies. If non-GIST nodes block Q-mode packets, GIST will not 6451 function. It is always possible for middleboxes to block specific 6452 traffic types; by using a normal encapsulation for Q-mode traffic at 6453 the UDP level, GIST allows NATs at least to pass these messages 6454 (Section 7.2.1), and firewalls can be configured with standard 6455 policies. However, where the Q-mode encapsulation uses a Router 6456 Alert Option (RAO) at the IP level this can lead to additional 6457 problems. The situation is different for IPv4 and IPv6. 6459 The IPv4 RAO is defined by [3], which defines the RAO format with a 6460 2-byte value field; however, only one value (zero) is defined and 6461 there is no IANA registry for further allocations. It states that 6462 unknown values should be ignored (i.e. the packets forwarded as 6463 normal IP traffic); however, it has also been reported that some 6464 existing implementations simply ignore the RAO value completely (i.e. 6465 process any packet with an RAO as though the option value was zero). 6466 Therefore, the use of non-zero RAO values cannot be relied on to make 6467 GIST traffic transparent to existing implementations. (Note that it 6468 may still be valuable to be able to allocate non-zero RAO values for 6469 IPv4: this makes the interception process more efficient for nodes 6470 which do examine the value field, and makes no difference to nodes 6471 which - incorrectly - ignore it. Whether or not non-zero RAO values 6472 are used does not change the GIST protocol operation, but needs to be 6473 decided when new NSLPs are registered.) 6475 The second stage of the analysis is therefore what happens when a 6476 non-GIST node which implements RAO handling sees a Q-mode packet. 6477 The RAO specification simply states that "Routers that recognize this 6478 option shall examine packets carrying it more closely (check the IP 6479 Protocol field, for example) to determine whether or not further 6480 processing is necessary." There are two possible basic behaviours 6481 for GIST traffic: 6483 1. The "closer examination" of the packet is sufficiently 6484 intelligent to realise that the node does not need to process it 6485 and should forward it. This could either be by virtue of the 6486 fact that the node has not been configured to match IP- 6487 Protocol=UDP for RAO packets at all, or that even if UDP traffic 6488 is intercepted the port numbers do not match anything locally 6489 configured. 6491 2. The "closer examination" of the packet identifies it as UDP, and 6492 delivers it to the UDP stack on the node. In this case, it can 6493 no longer be guaranteed to be processed appropriately. Most 6494 likely it will simply be dropped or rejected with an ICMP error 6495 (because there is no GIST process on the destination port to 6496 deliver it to). 6498 Analysis of open-source operating system source code shows the first 6499 type of behaviour, and this has also been seen in direct GIST 6500 experiments with commercial routers, including the case when they 6501 process other uses of the RAO (i.e. RSVP). However, it has also 6502 been reported that other RAO implementations will exhibit the second 6503 type of behaviour. The consequence of this would be that Q-mode 6504 packets are blocked in the network and GIST could not be used. Note 6505 that although this caused by some subtle details in the RAO 6506 processing rules, the end result is the same as if the packet was 6507 simply blocked for other reasons (for example, many IPv4 firewalls 6508 drop packets with options by default). 6510 The GIST specification allows two main options for circumventing 6511 nodes which block Q-mode traffic in IPv4. Whether to use these 6512 options is a matter of implementation and configuration choice. 6514 o A GIST node can be configured to send Q-mode packets without the 6515 RAO at all. This should avoid the above problems, but should only 6516 be done if it is known that nodes on the path to the receiver are 6517 able to intercept such packets. (See Section 5.3.2.1.) 6519 o If a GIST node can identify exactly where the packets are being 6520 blocked (e.g. from ICMP messages), or can discover some point on 6521 the path beyond the blockage (e.g. by use of traceroute or by 6522 routing table analysis), it can send the Q-mode messages to that 6523 point using IP-in-IP tunelling without any RAO. This bypasses the 6524 input side processing on the blocking node, but picks up normal 6525 GIST behaviour beyond it. 6527 If in the light of deployment experience the problem of blocked 6528 Q-mode traffic turns out to be widespread and these techniques turn 6529 out to be insufficient, a further possibility is to define an 6530 alternative Q-mode encapsulation which does not use UDP. This would 6531 require a specification change. Such an option would be restricted 6532 to network-internal use, since operation through NATs and firewalls 6533 would be much harder with it. 6535 The situation with IPv6 is rather different, since in that case the 6536 use of non-zero RAO values is well established in the specification 6537 ([8]) and an IANA registry exists. The main problem is that several 6538 implementations are still immature: for example, some treat any RAO- 6539 marked packet as though it was for local processing without further 6540 analysis. Since this prevents any RAO usage at all (including the 6541 existing standardised ones) in such a network, it seems reasonable to 6542 assume that such implementations will be fixed as part of the general 6543 deployment of IPv6. 6545 Appendix D. Example Routing State Table and Handshake 6547 Figure 9 shows a signalling scenario for a single flow being managed 6548 by two signalling applications using the path-coupled message routing 6549 method. The flow sender and receiver and one router support both, 6550 two other routers support one each. The figure also shows the 6551 routing state table at node B. 6553 A B C D E 6554 +------+ +-----+ +-----+ +-----+ +--------+ 6555 | Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow | 6556 |Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver| 6557 | | +-+ +-+ |GIST | |GIST | |GIST | | | 6558 +------+ +-----+ +-----+ +-----+ +--------+ 6559 Flow Direction ------------------------------>> 6561 +------------------------------------+---------+--------+-----------+ 6562 | Message Routing Information | Session | NSLPID | Routing | 6563 | | ID | | State | 6564 +------------------------------------+---------+--------+-----------+ 6565 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | IP-A | 6566 | {IP-A, IP-E, proto/ports}; D=up | | | | 6567 | | | | | 6568 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | (null) | 6569 | {IP-A, IP-E, proto/ports}; D=down | | | | 6570 | | | | | 6571 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | IP-A | 6572 | {IP-A, IP-E, proto/ports}; D=up | | | | 6573 | | | | | 6574 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | Points to | 6575 | {IP-A, IP-E, proto/ports}; D=down | | | B-D MA | 6576 +------------------------------------+---------+--------+-----------+ 6578 Figure 9: A Signalling Scenario 6580 The upstream state is just the same address for each application. 6581 For the downstream direction, NSLP1 only requires D-mode messages and 6582 so no explicit routing state towards C is needed. NSLP2 requires a 6583 messaging association for its messages towards node D, and node C 6584 does not process NSLP2 at all, so the peer state for NSLP2 is a 6585 pointer to a messaging association that runs directly from B to D. 6586 Note that E is not visible in the state table (except implicitly in 6587 the address in the message routing information); routing state is 6588 stored only for adjacent peers. (In addition to the peer 6589 identification, IP hop counts are stored for each peer where the 6590 state itself if not null; this is not shown in the table.) 6592 Figure 10 shows a GIST handshake setting up a messaging association 6593 for B-D signalling, with the exchange of Stack Proposals and MA- 6594 protocol-options in each direction. The Querying node selects TLS/ 6595 TCP as the stack configuration and sets up the messaging association 6596 over which it sends the Confirm. 6598 -------------------------- Query ----------------------------> 6599 IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST) 6600 Q-mode magic number (0x4e04 bda5) 6601 GIST(Header(Type=Query; NSLPID=NSLP2; R=1; S=0) 6602 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 6603 SessionID(0x1234) NLI(Peer='string1'; IA=IP#B) 6604 QueryCookie(0x139471239471923526) 6605 StackProposal(#Proposals=3;1=TLS/TCP; 2=TLS/SCTP; 3=TCP) 6606 StackConfigurationData(HoldTime=300; #MPO=2; 6607 TCP(Applicable: all; Data: null) 6608 SCTP(Applicable: all; Data: null))) 6610 <---------------------- Response ---------------------------- 6611 IP(Src=IP#D; Dst=IP#B); UDP(Src=GIST; Dst=6789) 6612 D-mode magic number (0x4e04 bda5) 6613 GIST(Header(Type=Response; NSLPID=NSLP2; R=1; S=1) 6614 MRI(MRM=Path-Coupled; Flow=F; Direction=up) 6615 SessionID(0x1234) NLI(Peer='stringr2', IA=IP#D) 6616 QueryCookie(0x139471239471923526) 6617 ResponderCookie(0xacdefedcdfaeeeded) 6618 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP) 6619 StackConfigurationData(HoldTime=200; #MPO=3; 6620 TCP(Applicable: 3; Data: port=6123) 6621 TCP(Applicable: 1; Data: port=5438) 6622 SCTP(Applicable: all; Data: port=3333))) 6624 -------------------------TCP SYN-----------------------> 6625 <----------------------TCP SYN/ACK---------------------- 6626 -------------------------TCP ACK-----------------------> 6627 TCP connect(IP Src=IP#B; IP Dst=IP#D; Src Port=9166; Dst Port=6123) 6628 <-----------------------TLS INIT-----------------------> 6630 ------------------------ Confirm ----------------------------> 6631 [Sent within messaging association] 6632 GIST(Header(Type=Confirm; NSLPID=NSLP2; R=0; S=1) 6633 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 6634 SessionID(0x1234) NLI(Peer='string1'; IA=IP#B) 6635 ResponderCookie(0xacdefedcdfaeeeded) 6636 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP) 6637 StackConfigurationData(HoldTime=300)) 6639 Figure 10: GIST Handshake Message Sequence 6641 Appendix E. Change History 6643 Note to the RFC Editor: this appendix to be removed before 6644 publication as an RFC. 6646 E.1. Changes in Version -13 6648 The following changes were made in version 13. Some are further 6649 follow ups to IESG review comments. 6651 1. Changed the C-mode/D-mode selection rules in Section 4.3.3 to 6652 make the use of C-mode a SHOULD unless capacity can be 6653 explicitly engineered. Also added a reference to this fact in 6654 the rate control section, Section 5.3.3, and an explanation of 6655 the effect this has on signalling application behaviour. [Lars 6656 Eggert] 6658 2. Amended the message size limit text in Section 4.3.3 to include 6659 a check on the first-hop MTU as well as the path MTU and 576 6660 byte limit. [Lars Eggert] 6662 3. Added 2119 text at the start of Section 5.8 to define the level 6663 of support required for particular MRMs. 6665 4. Added a note at the end of the first paragraph of Section 7.1.4 6666 to point out the applicability to mobile environments. 6668 5. Added the possibility for the InvalidateRoutingState call 6669 (Appendix B.6) to provide an NSLP payload to support conditional 6670 peering. 6672 6. Clarified the text in Section 4.4.1 to state that the MA-Hold- 6673 Time in the Confirm overrides that in the Query, and also 6674 rewrote part of Section 4.4.5 to make more precise that the MA- 6675 Hold-Time is the time that a node will keep an MA open, rather 6676 than the time it requires the peer to keep it open. 6678 7. Modified the text on MA multiplexing in Section 5.7.1 to make it 6679 clear that re-use is allowed if the candidate MA has equivalent 6680 or better (transport and security) performance as any of the 6681 options offered in the Query, not that it has to be equivalent 6682 to all of them. 6684 8. Extended the rules about message transmission at the end of 6685 Section 4.3.3, to point out that absence of routing state may be 6686 used as trigger for a handshake. 6688 9. Made the reference to TLS1.0 informational to satisfy nit 6689 processing rules. 6691 10. Added text in Section 5.3.3 to clarify that a node should stop 6692 its retransmission process on receiving a response to any of its 6693 messages. 6695 11. Modified the magic number so that it is carried in all D-mode 6696 message (normal and otherwise), with changes in Section 3.6, 6697 Section 5.2.1, and Section 5.3 and a new error subcode in 6698 Appendix A.4.4.1. 6700 E.2. Changes in Version -12 6702 The following changes were made in response to IESG review. The 6703 changes have been classified into three categories: protocol changes 6704 (things which would directly affect, technical clarifications, and 6705 editorial issues. The name of the reviewer is included with each 6706 change. 6708 Protocol changes: 6710 1. Modified the processing rules for the GIST hop count. An 6711 initial check for GHC=0 followed by a decrement is now done on 6712 the receive side (Section 4.3.1); the local processing 6713 description in Section 4.3.2 now forces peering (preventing 6714 bypass) if the GHC has reached zero. A check is added for a 6715 valid NSLP-supplied GHC in Section 4.3.3, and this also includes 6716 the old text from Section 4.3.4 on loop control in NSLPs by 6717 preserving the GHC. Section 4.3.3 also includes guidance on how 6718 to select an initial GHC (referring to IP TTL setting). A note 6719 on not retrying if a loop was known to have been formed has been 6720 removed, and it has been clarified that the mechanism does not 6721 prevent looping per se, just infinite looping. [Adrian Farrel] 6723 2. Changed the class of the "Endpoint Found" error 6724 (Appendix A.4.4.7) to Permanent-Failure, to ensure that the 6725 Querying state machine terminates when it occurs. [Adrian 6726 Farrel] 6728 3. Modified the MA-Hello message (Section 5.1, Section 5.2.2, 6729 Appendix A.3.8) to include a Hello-ID object which allows the 6730 correlation of request/response exchanges, and described the 6731 corresponding processing - that failure to get a response can 6732 trigger er_MAFailure - in Section 6.4. Note that the response 6733 message must have R=0. [Adrian Farrel, Roland Bless] 6735 4. Added a new section on Legacy NAT handling in Section 7.2.1 6736 describing how to detect and respond to such NATs; also re- 6737 arranged some of the text from old section 1.1 into the start of 6738 Section 7.2, and added minor details of S flag processing in 6739 Section 5.2.2, Section 5.3.1, and Section 5.3.2. [Jari Arkko, 6740 Brian Carpenter] 6742 5. Modified the error message format in Appendix A.4 so that the 6743 Additional Information fields are carried in proper TLV objects. 6744 Also created a registry for these objects in Section 9 and 6745 updated other IANA text about error code registration. The 6746 individual error messages now only define the minimum Additional 6747 Information fields to be carried; their order, and whether to 6748 carry others, are left open. [Adrian Farrel] 6750 6. Added a magic number to the Q-mode encapsulation in 6751 Section 5.3.2 to minimise the risk of incorrect interception of 6752 UDP datagrams as GIST packets, also updating the reception rules 6753 in Section 4.3.1 and the example in Appendix D. Also added a 6754 new Section 3.6 in the overview part explaining the 6755 architectural impacts of GIST arising from the way that it can 6756 intercept end to end packets. [Sam Hartman] 6758 7. Extended the analysis of routing state errors to handle cases 6759 including peer node restarts and malicious traffic (blind 6760 attacks). The overall description is now in a dedicated 6761 Section 4.4.6, with the discussion in Section 5.3.3 simplified 6762 and corresponding corrections in Section 4.3.2 and Section 6. 6763 [Adrian Farrel] 6765 8. Added a new Section 4.4.2 on the criteria which should be used 6766 in deciding whether to authorise the creation of a secured MA, 6767 and pointers in Section 4.4.1 and Section 4.4.3 to when during 6768 protocol operation those criteria should be invoked. Also 6769 updated the text in Section 8.3 to indicate how these 6770 authorisation checks prevent the on-path or upstream node 6771 attacks mentioned there. [Sam Hartman, Russ Housley, Cullen 6772 Jennings] 6774 9. Added a new Section 5.7.3.1 to define the algorithm used to 6775 check names against the database of authorised peers, and noted 6776 in Section 9 that definition of future channel security 6777 protocols must provide the same information. [Sam Hartman, Russ 6778 Housley, Cullen Jennings] 6780 10. Extended the text (mainly in Section 4.3.1, also in 6781 Section 4.3.4 and Section 9) to be explicit about how the GIST 6782 specification provides the required message processing rules for 6783 packets carrying the RAO and how this should be called up when 6784 RAO value assignments are requested by NSLPs. Also, made the 6785 prohibition on packet fragmentation in Q-mode absolute in 6786 Section 5.3.2.1. Added an informative Appendix C on deployment 6787 issues with the RAO in IPv4. [Adrian Farrel] 6789 11. Made the NLI present in all Response messages (even those sent 6790 over an MA as a result of multiplexing). The NLI is needed 6791 because it contains the Responding node's value for the routing 6792 state validity time, and also can be monitored by the Querying 6793 node for certain classes of route change (e.g. changes in the 6794 inbound interface at the peer). [Raised during interoperability 6795 testing] 6797 Technical clarifications: 6799 1. Added text in Section 4.3.3 and extended text in Section 4.4.5 6800 to explain the restrictions on MA usage when in-order delivery 6801 (for a single SID) is required. [Lars Eggert] 6803 2. Strengthened the text in Section 4.3.3 to be more precise about 6804 the message size thresholds which cause C mode to be required. 6805 Also, tidied up related text in Section 5.3.2, Section 5.8.1.2, 6806 Section 5.8.1.3, and Section 5.8.2.2. [Lars Eggert] 6808 3. Added text in Section 3.2 to explain why D-mode is not expected 6809 to evolve and how such functionality would actually be 6810 incorporated. Also added a discussion about how a very simple 6811 version of some security functions could be added directly to 6812 D-mode. [Lars Eggert, Sam Hartman] 6814 4. Clarified that the validation checks in Section 4.3.2 must be 6815 applied in sequence, and re-ordered the sequence of checks to 6816 prevent carrying out a routing state inventory over a messaging 6817 association. [Adrian Farrel] 6819 5. Modified Section 4.3.2 to prohibit bypass in the case that the 6820 node is the endpoint of a flow; correspondingly, clarified the 6821 routing state table in Section 4.2.1 to eliminate storing null 6822 state for flow endpoints, and Section 4.3.3 to prevent sending 6823 messages from a flow endpoint to itself. [Adrian Farrel] 6825 6. Added text in Section 4.4.3 to clarify the uniqueness 6826 requirement on Peer-Identity, and to note the possibility of 6827 using the Router-ID as a source for it, with caveats on when 6828 this may not be sufficient. [Adrian Farrel] 6830 7. Clarified the format of the object list in the NAT Traversal 6831 object (Appendix A.3.9) as containing all 16 bits of the start 6832 of the object TLV. [Adrian Farrel] 6834 8. Modified the description of TLS usage in Section 5.7.3 to 6835 clarify that negotiation is performed within TLS, and also using 6836 RFC4307-style terminology to describe the ciphersuites to be 6837 supported. [Russ Housley] 6839 9. Strengthened the text in Section 4.3.2 and Section 4.3.4 to 6840 explain why it is crucial that a node forwarding Query messages 6841 must not modify them, and give some implementation guidance on 6842 how to do so. [Adrian Farrel] 6844 10. Modified the description of MA multiplexing with matching Peer- 6845 Identity and non-matching Interface-Address in Section 4.4.3 to 6846 indicate that while the non-malicious cases should be rare, the 6847 malicious case needs to be considered under the general heading 6848 of denial of service issues, for which the text in Section 8.4 6849 has been slightly extended. [Adrian Farrel] 6851 11. Refined the text in Section 4.4.4 to clarify that the 6852 requirement is to have a Query received within the timeout 6853 period (rather than just to send it), and to provide more 6854 detailed guidance on how to adapt the timer value if rate 6855 limiting is impacting the number of Queries that can be sent. 6856 [Adrian Farrel] 6858 12. Moved the text on SID selection from Section 3.7 to a new 6859 Section 4.1.3 where it is more reasonable for it to be normative 6860 (as a requirement on the API). Also added text on residual 6861 threats in Section 8.7 explaining how GIST depends on the NSLP 6862 to follow the rules here. [Sam Hartman] 6864 13. Totally restructured the description of Q-mode encapsulation in 6865 Section 5.3.2, to provide more detailed rules for IP-level 6866 interception and UDP encapsulation, including a description of 6867 what IP-layer options are allowed (and how they should be 6868 handled) and what additional encapsulation layers are not 6869 allowed. [Sam Hartman] 6871 14. Added discussion of overload protection mechanisms mainly in 6872 Section 8.4, with supporting text in Section 4.1.1 and 6873 Section 4.3.2. [Adrian Farrel] 6875 15. Clarified in Section 6.3 that the policy on whether to require a 6876 Confirm can be changed at a node whenever it likes, but that the 6877 state machine diagram only covers the simple case where the 6878 policy is fixed when one is in a state waiting for a Confirm in 6879 the first place. [Adrian Farrel] 6881 16. Clarified when the R flag should be set in Responses, added a 6882 rule for receiving a Confirm in Established state, and clarified 6883 when to_Expire_RNode can occur in Section 6.3. [Adrian Farrel] 6885 17. Added text in Section 6.4 explaining what other actions should 6886 be taken when a messaging association fails. [Adrian Farrel] 6888 18. Extended the text in Section 4.3.1 to explain the different 6889 significance of the RAO and NSLPID values in a Q-mode message. 6890 [Lisa Dusseault] 6892 19. Modified the route change discussion in Section 7.1, adding a 6893 new Section 7.1.4 covering the possibility that there may be 6894 multiple routes in use in parallel (either because of load 6895 splitting or very rapid route flapping). The new subsection 6896 includes some of the text from the old section 1.1, and also 6897 introduces the SII concept. [Brian Carpenter, Cullen Jennings] 6899 Editorial issues: 6901 1. Merged together the two subsections in Section 5.4 and removed 6902 the old figure. The section apparently caused confusion between 6903 C- and D-mode and was in any case technically incorrect for the 6904 case of TCP. [Lars Eggert] 6906 2. Added a note in Section 3.1 to clarify that the actual set of 6907 allowed protocol combinations is in Section 5.7 and that this 6908 section is only for conceptual guidance. Also modified the 6909 diagram to indicate that both TLS and DTLS are possible 6910 instantiations of Transport Layer Security, and removed 6911 references to DTLS in Section 5.7.3, instead clarifying in 6912 Section 9 that defining new MA-Protocol-IDs requires the 6913 definition of any interactions with existing options. [Lars 6914 Eggert, Russ Housley, Lisa Dusseault] 6916 3. Retitled Section 7 from 'Advanced' to 'Additional'. Some of the 6917 features were felt not to be so advanced. [Lars Eggert] 6919 4. Use British English consistently (this affects only the word 6920 'signalling' and its associates). [Lars Eggert] 6922 5. Eliminated the term 'primary key' from the description of the 6923 routing state table in Section 4.2.1. [Adrian Farrel] 6925 6. Clarified what determines whether Q-mode messages have a Router 6926 Alert Option in their IP encapsulation in Section 4.3.1. 6927 [Adrian Farrel] 6929 7. Clarified how routing state table entries are created in 6930 Section 4.2.1 by adding a reference to the handshake sections 6931 [Adrian Farrel] 6933 8. Added a reference in Section 4.1.2 to the authentication section 6934 (Section 8.2) to indicate the origin of the keying material 6935 [Adrian Farrel] 6937 9. Re-wrote the start of Section 4.1 to clarify that the interface 6938 definition itself is non-normative. [Adrian Farrel] 6940 10. Eliminated the RFC2119 words in Section 3, since these related 6941 to NSLP behaviour or related node configuration requirements. 6942 [Adrian Farrel] 6944 11. Modified the text in Section 3.7 to clarify that the SID really 6945 is the responsibility of the NSLP to chose, maintain along the 6946 path, and enforce uniqueness of. [Adrian Farrel] 6948 12. Deleted the word 'policy' in Section 4.3.2; the interaction is 6949 with the signalling application itself, not the signalling 6950 application policy. [Adrian Farrel] 6952 13. Added a note in Section 4.3.4 that directly addressed messages 6953 shouldn't be received at nodes without the NSLP during normal 6954 operation (i.e. that this is not impossible, it's just not 6955 expected). [Adrian Farrel] 6957 14. Modified the text at the start of Section 4.4 to make it clear 6958 that messaging associations have an independent lifecycle from 6959 routing state once they have been created. [Adrian Farrel] 6961 15. Modified the text in Section 4.4.3 to describe use of an MA for 6962 multiple items of routing state as multiplexing rather than re- 6963 use; changed some of the other uses of the term 're-use' to 6964 multiplexing also. [Adrian Farrel] 6966 16. Expanded the definition of the D flag in Appendix A.3.1.2 to 6967 give an interpretation for the values 0 and 1. [Adrian Farrel] 6969 17. Deleted the confusing terms 'Upper Layer' and 'Higher Layer' in 6970 the description of the MA-Protocol-ID registry, Section 9. 6971 [Adrian Farrel] 6973 18. Added text in Section 1 highlighting the importance of the 6974 framework and threats document as background reading for this 6975 specification. [Adrian Farrel, Cullen Jennings] 6977 19. Clarified the padding issues for NSLP-Data in Appendix A.3.10; 6978 the NSLP itself provides and receives data which is already 6979 aligned on 32-bit boundaries. [Adrian Farrel] 6981 20. Added a note on the Stack-Configuration-Data object 6982 (Appendix A.3.5) that the format allows the MPO-Count to be 6983 zero. [Adrian Farrel] 6985 21. Clarified that profiles in the Stack-Proposal object 6986 (Appendix A.3.4) must be non-empty; an error is raised for 6987 either empty profiles or an empty list of profiles. Also, that 6988 pad bytes must be ignored. [Adrian Farrel] 6990 22. Clarified the syntax of the Confirm message including how it 6991 depends on when and how it is sent. In particular, 6992 Section 4.4.1 now states that the first Confirm MUST contain the 6993 abbreviated SCD, and Section 4.4.5 covers the error case if the 6994 object is missing. The description of the Confirm in 6995 Section 5.1 has been re-written, and the format of the SCD in 6996 Appendix A.3.5 emphasises that the time is given in milliseconds 6997 and that the value 0 is reserved. [Adrian Farrel, Roland Bless] 6999 23. Modified the text in Section 6.4 to explain and motivate the 7000 differences between the various MA states and the logic for 7001 transitions between them; in particular, turned the Connected -> 7002 Idle transition into one driven by policy rather then directly 7003 by timers. Clarified that the value 0 for MA-Hold-Time is 7004 reserved in Appendix A.3.5, and also emphasised that the format 7005 carries a value in milliseconds. [Adrian Farrel, Roland Bless] 7007 24. Clarified that the value 0 for Routing-State Validity time is 7008 reserved and must not be used. [Adrian Farrel] 7010 25. Updated the text in Appendix A to use RFC2119 language 7011 correctly. [Adrian Farrel] 7013 26. Clarified the text on extensibility in Appendix A.2.1 to explain 7014 that adding new non-mandatory objects should not change the 7015 interaction with NSLPs. [Adrian Farrel] 7017 27. Updated the text in Appendix A.3.1.1 to clarify under what 7018 circumstances various combinations of flags can be set, and to 7019 indicate what error message should be returned if the rules are 7020 violated. [Adrian Farrel] 7022 28. Added a reference to the working group state machine draft in 7023 Section 6. [Adrian Farrel] 7025 29. Added a reference to the framework for the origin of the 7026 assumption about signalling application behaviour supporting re- 7027 routing in Section 7.1.1. [Adrian Farrel] 7029 30. Extended the description of the meaning of the 'Reserved' blocks 7030 in the IANA considerations (Section 9). [Adrian Farrel] 7032 31. Clarified in Section 9 that the information needed to justify 7033 certain registrations needs to be in the separate specfication 7034 document (rather than in the registry itself). [Adrian Farrel] 7036 32. Clarified the required information to accompany the registration 7037 of a new error in Section 9. [Adrian Farrel] 7039 33. Added a note in Section 4.4.5 that the MA-Hello request/response 7040 diagnostic can be used for MA protocol failure detection. 7041 [Adrian Farrel] 7043 34. Added a note in Section 4.4.5 to indicate that the MA-Hold-Time 7044 setting can take NSLP behaviour (e.g. refresh timers) into 7045 account. [Adrian Farrel] 7047 35. Rephrased the description of the case of colliding peer-identity 7048 and interface-address in Section 4.4.3 including a forward 7049 reference to Section 8.7 for the case of on-path attacks. 7050 [Adrian Farrel] 7052 36. Added clarification in Section 4.4.1 about how the Querying node 7053 knows when downstream routing state has been installed, and 7054 included a forward pointer from Section 3.4. [Adrian Farrel] 7056 37. Expanded the rationale for the use of UDP for D-mode in 7057 Section 3.2 (that it is at least partly NAT-friendly). [Adrian 7058 Farrel] 7060 38. Expanded the rationale for the existence of C-mode in 7061 Section 3.2. [Adrian Farrel] 7063 39. Added a definition for [message] routing in Section 2, 7064 distinguishing it from normal IP routing; qualified the term 7065 'routing' in other parts of the document, where this could be 7066 ambiguous. [Adrian Farrel] 7068 40. Modified the text in step 5 of the example in Section 3.10 to 7069 make it clear that the forwarding between successive hops is a 7070 signalling application rather than a GIST responsibility. [Sam 7071 Hartman, Lisa Dusseault] 7073 41. Modified the text in Section 3.10, Section 5.7.3, and 7074 Appendix B.1 to make it clear that 'security' is not a simple 7075 true/false attribute. (The more detailed text on message 7076 transfer attributes elsewhere already made this distinction.) 7077 [Sam Hartman] 7079 42. Added a note to the end of Section 1 pointing more strongly to 7080 the NSIS extensibility document for general guidelines on 7081 protocol extensibility. [Sam Hartman] 7083 43. Added a note at the start of Section 7.2 to highlight the 7084 relationship of the various NAT traversal solutions for GIST to 7085 the IETF BCP on NAT traversal. [Sam Hartman] 7087 44. Modified the description of upstream node attacks in Section 3.7 7088 and Section 8.3 to clarify that the effect would be to disrupt 7089 the signalling flow rather than the traffic flow itself. [Sam 7090 Hartman] 7092 45. Removed old section 5.7.4 on alternative channel security 7093 protocols, and created a new Section 3.9 describing the security 7094 services that GIST requires and where it depends on the channel 7095 security protocol to provide them. [Russ Housley] 7097 46. Modified some of the text in Section 1 about the meaning of the 7098 term "path-coupled", and also noted in Section 3.3 the future 7099 flexibility about defining alternative probe methods. [Adrian 7100 Farrel] 7102 47. Modified Section 1 to leave open the concept of using GIST for 7103 multicast in certain circumstances. [Adrian Farrel] 7105 48. Added a new Section 3.5 introducing the peering concept in more 7106 detail, removing some of the related terminology details and 7107 providing forward pointers to the relevant normative sections. 7108 [Ted Hardie] 7110 49. Modified the start of the example (Section 3.10) to be clear 7111 that it covers just a single segment of the path. [Lisa 7112 Dusseault] 7114 50. Modified the end of Section 3.2 to clarify that there is no 7115 semantic relationship between the MA and flow concepts. [Lisa 7116 Dusseault] 7118 51. Extended the definition of D-mode in Section 3.2 to introduce 7119 Query-mode at the same time. [Lisa Dusseault] 7121 52. Rewrote the start and end of Section 4.3.2 to clarify that the 7122 scope of the discussion is the interaction with the NSLP, and 7123 that only the description of the GIST internal processing is 7124 deferred to a later section. [Lisa Dusseault] 7126 53. Modified the text at the end of Section 4.3.3 to be clear about 7127 which options use Q-mode and which do on. [Lisa Dusseault] 7129 54. Modified the labelling in Figure 4 to avoid the label 'Q-node' 7130 etc. (could cause confusion with Q-mode). [Lisa Dusseault] 7132 55. Split the old section on state maintenance into Section 4.4.4 7133 and Section 4.4.5 to avoid confusion between the two types of 7134 operation. [Lisa Dusseault] 7136 Various other minor editorial corrections have also been made. 7138 E.3. Changes In Version -11 7140 1. Added some text in Section 1 to clarify the scope of GIST 7141 applicability with non-path-coupled message routing methods. 7143 2. Loosened the text about the Query encapsulation to indicate that 7144 a Router Alert Option is needed for all the current message 7145 routing methods but not necessarily for future ones. 7147 3. Clarified the rules for deriving protocol encapsulation 7148 addresses for the Response and other messages in Section 4.4.1 7149 and Section 5.3.1. 7151 4. Updated the ABNF and message descriptions in Section 3.4 to 7152 cover the case of NAT traversal for stateless data messages; 7153 also minor changes in Section 7.2. 7155 5. Re-corrected the timeout processing rules in Section 6.4 (update 7156 in version 10 changed rule 3 but should have changed rule 4). 7157 In addition, the rule 3 processing is made conditional on the 7158 state (i.e. split) since different timers are running in the two 7159 states. 7161 6. Clarified that the E flag can only be set on Data messages, and 7162 added notes to the flag description in Section 7.1.5 and the 7163 format description in Appendix A.1. Also, included a new error 7164 condition to cover incorrect setting in Appendix A.4.4.1. 7166 7. Clarified the text in Section 8.4 to note the issues about 7167 Response size contributing to reflection attacks, and also the 7168 defence against various forms of message spoofing in 7169 Section 8.5. 7171 8. Stated that MA-Protocol-ID value 0 is reserved (not allocated) 7172 in Section 9. 7174 9. Clarified the units (bytes, 32-bit words) for all length fields 7175 in Appendix A. 7177 10. Clarified that the restriction on the D flag value for the 7178 loose-end MRM applies only to Q-mode messages in 7179 Appendix A.3.1.2. 7181 11. Added the Hold Time to the example in Appendix D. 7183 E.4. Changes In Version -10 7185 1. Added further guidance on parameter setting for initial backoff 7186 and rate control for D-mode to Section 5.3.3 [AD review comment 7187 M1]. 7189 2. Rephrased the end of Section 8.6 to highlight the threat left 7190 open when the Querying node does not apply a strong security 7191 policy to offered Stack-Proposal [AD review comment M2]. 7193 3. Clarified in Section 7.2 that although NAT behaviour is only 7194 informatively described in this specification, it is being 7195 defined in a separate document [AD review M3]. 7197 4. Strengthened and clarified the reference to the extensibility 7198 document for technical guidance on codepoint allocation, and 7199 made the reference normative. Added rationale for the 7200 'Reserved' blocks in the various registries, and added further 7201 notes on what information must be provided to support an 7202 allocation request [AD review comment M4]. 7204 5. Fixed an identifier collision in the ABNF for the GIST messages 7205 in Section 5.2.2 (Common-Header in the message header and 7206 common-header as a payload in error messages) and re-verified 7207 the ABNF [AD review comment L1]. 7209 6. Clarified the text in Section 3.3 about the impact on NATs of 7210 defining a new MRM, referring to the specification split 7211 described in Section 7.2.3. Also added a flag to the MRM format 7212 (Appendix A.3.1) to denote MRIs which do not contain network or 7213 transport addresses, and made more specific the error message to 7214 be returned if a NAT does not understand an MRM in Section 7.2.2 7215 [AD review comment L2]. 7217 7. Added discussion in Section 4.1.2 on delivery failure detected 7218 for reliable messaging in general, and for the case of Forwards- 7219 TCP in particular in Section 5.7.2. Also noted that this needs 7220 to be considered for future MA-Protocol-IDs used for reliable 7221 messaging (Section 9) [AD review comment L3]. 7223 8. Added clarifying text to Section 5.1 on what it means to invert 7224 the direction of an MRI [AD review comment L5]. 7226 9. Enhanced the format descriptions in Appendix A to include 7227 descriptions of all message and object fields and also field 7228 lengths [AD review comment L6]. 7230 10. Added more explanation in Section 5.2.2 of how a message 7231 direction is defined, in particular in the context of TTL 7232 measurement [AD review comment L7]. 7234 11. Added a new explanation of why a well-known port is needed for 7235 the query encapsulation in Section 5.3.2 [AD review comment L8]. 7237 12. Added a note that DCCP does not provide reliability in 7238 Section 5.4 [AD review comment L9]. 7240 13. Clarified the rules on how long to retain stack configuration 7241 data in Section 5.7.1 and included a default timer value [AD 7242 review comment L10]. 7244 14. Modified the text about stack-proposal verification as part of 7245 downgrade protection in Section 5.7.1, to clarify that the MUST 7246 applies directly to the object verification itself; also noted 7247 the action to be taken in case of a failed verification [AD 7248 review comment L11]. 7250 15. Added further information on the addressing used in opening a 7251 forwards-TCP connection in Section 5.7.2 [AD review comment 7252 L12]. 7254 16. Modified the text in Section 5.8.1.2 to say that using the 7255 signalling source address is a consequence of setting DF itself 7256 rather than why DF was set in the first place; also weakened the 7257 instruction from MUST to SHOULD [AD review comment L14]. 7259 17. Added further clarification of why routing state installed by a 7260 downstream Query should supersede that from an upstream Query in 7261 Section 5.8.1.3 [AD review comment L15]. 7263 18. Corrected a timer in the Messaging Association state machine 7264 (Section 6.4) from NoHello to SendHello. Also, added default 7265 values for MA-Hold-Time and route change probe frequency, and 7266 explanatory text for each, to Section 4.4.4 and Section 4.4.5 7267 [AD review comment L16]. 7269 19. Re-arranged the text in Section 7.2 to highlight the rules about 7270 precisely which messages are and are not translated in a GIST- 7271 specific way by NATs [AD review comment L19]. 7273 20. Explicitly noted that 'r' bits are also reserved in Appendix A.2 7274 [AD review comment L20]. 7276 21. Added an error condition for processing messages which have the 7277 extensibility flags AB set to 11 in Appendix A.2.1 [AD review 7278 comment L21]. 7280 22. Fixed the table of MRM identifiers in Section 9 so the field 7281 name matches that in Appendix A.3.1 [AD review comment L22]. 7283 23. Clarified why only D=0 is valid for the loose-end MRM in 7284 Appendix A.3.1.2 [AD review comment L23]. 7286 24. Clarified the rules about processing the NAT traversal object in 7287 Appendix A.3.9 to cover the case where there are several NATs 7288 along the path with different capabilities [AD review comment 7289 L24]. 7291 25. Strengthened the text in Appendix A.4.1 to be clearer about what 7292 additional information fields must be included in error messages 7293 [AD review comment L25]. 7295 26. Tidied up the use of acronyms throughout the document, including 7296 adding some to the terminology list in Section 2 [AD review 7297 comment N1]. 7299 27. Added references to RFC4086 and updated 2119 language for 7300 cryptographic randomness of SIDs and cookies in Section 3.7 and 7301 Section 8.5 respectively [AD review comment N2]. 7303 28. Modified the transition labelling in Figure 7 to make it clearer 7304 that in the Established-Established transition, the 7305 [!confirmRequired] qualification applies only to the rx_Query 7306 case [AD review comment N4]. 7308 29. Added a reference for OSPF in Section 7.1.2 [AD review comment 7309 N5]. 7311 30. Changed NAT terminology from public/private to external/internal 7312 to match BEHAVE usage in Section 7.2 and Section 7.4 [AD review 7313 comment N6]. 7315 31. Updated a number of i-d references to published RFCs or working 7316 group documents [AD review comment N7 partial]. 7318 32. Fixed rfc2119 capitalisation of MUST not in Appendix A.3.5 [AD 7319 review comment N8]. 7321 33. Fixed an error subcode name from 'Invalid Object' to 'Invalid 7322 Object Type' in Appendix A.4.4.9 [AD review comment N9]. 7324 34. Added the NTO to the GIST message ABNF in Section 5.1 and 7325 updated the forward reference to the NAT traversal section 7326 [tracker issue 104]. 7328 35. Removed a spurious rule about creating listening MAs in 7329 Section 6.3 and strengthened the rules about needing to have 7330 these available but with an open policy on when to create and 7331 destroy them in Section 5.7.1 [tracker issue 105]. 7333 36. Added text that limits the applicability of the private/ 7334 experimental space to closed network environments [tracker issue 7335 106]. 7337 37. Added text in Section 7.1.5 encouraging GIST to use a single SII 7338 across multiple sessions if possible to allow signalling 7339 application aggregation [tracker issue 107]. 7341 38. Specified that this document would define GIST version 1 in 7342 Section 5.2.1 [tracker issue 108]. 7344 39. Added the ability for RecvMessage to pass up interface 7345 attributes in Appendix B.2 [tracker issue 110]. 7347 40. Added additional text on rules for selecting stack proposals and 7348 MA re-use in Section 5.7.1 to ensure that re-used associations 7349 have properties that the Querying node actually needs [tracker 7350 issue 111]. 7352 41. Added a brief introduction to the GIST message types in a new 7353 Section 3.4. 7355 In addition, the following AD review comments did not lead to text 7356 changes. See the mailing list discussion at 7357 http://www1.ietf.org/mail-archive/web/nsis/current/msg06307.html. 7359 L4: Direct use of PMTUD by GIST. 7361 L13: Use of TLS 1.0 rather than 1.1. 7363 L17: Guidance on NSLP behaviour during rerouting, 7365 L18: Behaviour of GIST-unaware NATs. 7367 N3: Node state machine logic. 7369 E.5. Changes In Version -09 7371 1. Added a new Section 3.8 clarifying the relationship between 7372 signalling applications and NSLPIDs; modified terminology in the 7373 remainder of the document likewise. 7375 2. Added a new Section 8.6 explaining the rationale behind the 7376 downgrade attack prevention mechanism. 7378 3. Re-wrote parts of Section 4.3.2, Section 6.1 and Appendix B.2 to 7379 clarify the way that GIST is assumed to interact with signalling 7380 applications to exercise policy control over whether or not two 7381 nodes become signalling peers during a GIST handshake. 7383 4. Generalised an error message Appendix A.4.4.12 to cover 7384 additional MRI validation checks in Section 4.3.4 and 7385 Section 5.8.1.2. 7387 5. Allowed an optional Stack-Configuration-Data object in Confirm 7388 messages to allow messaging association lifetime to be 7389 negotiated even in the case of late state installation at the 7390 Responding node (see Section 4.4.1 and Section 4.4.5). 7392 6. Removed the option in Section 4.4.3 of allowing a node to treat 7393 messaging associations with the same authenticated end points as 7394 equivalent. 7396 7. Include additional guidance in Section 4.4.4 to prevent routing 7397 state being erroneously refreshed in the case of rerouting 7398 events; also included general guidance notes on timer setting. 7400 8. Clarified that the Stack-Proposal lists protocols in top-to- 7401 bottom order (see Section 5.7.1). 7403 9. Enhanced the definition of TLS usage in Section 5.7.3 with 7404 details on ciphersuite requirements and authentication methods. 7406 10. Tidied up terminology and discussion of how protocol options 7407 data is carried in the SCD; renamed higher-layer-addressing to 7408 MA-protocol-options. 7410 E.6. Changes In Version -08 7412 1. Changed the protocol name from GIMPS to GIST (everywhere). 7414 2. Inserted RFC2119 language (MUST etc.) in the appropriate places. 7416 3. Added references to the actions to be taken in various error 7417 conditions, including the error messages to be send 7418 (throughout). 7420 4. Added legacy NAT traversal to the list of excluded functions in 7421 old section 1.1. 7423 5. Included some text at the end of Section 3.3 analysing the case 7424 of a GIST node which does not support a particular MRM. 7426 6. Added a flag to mark when messages have been explicitly routed, 7427 so they can bypass validation against current routing state (see 7428 Section 4.3.1). 7430 7. Re-wrote the discussion in Section 4.3.4 to cover all cases of 7431 nodes not hosting an NSLP (including end systems), in particular 7432 the validations that can be performed at intermediate GIST nodes 7433 (this replaces the old section 7.2). 7435 8. Clarified the rules about R and S flag setting in the common 7436 header and D flag in the MRI (Section 5). 7438 9. Included discussion of how a node with a choice of interfaces or 7439 IP versions should select one to use in the NLI (Section 5.2.2). 7441 10. Modified the description of messaging association protocol 7442 selections (Section 5.7 and elsewhere) to clarify that this is 7443 essentially capability discovery rather than an open ended 7444 protocol negotiation. 7446 11. Modified the description of how higher layer addressing 7447 information is carried (Section 5.7.1 and Appendix A.3.5) to 7448 allow the data to be tagged against a specific profile if 7449 necessary, or omitted if the protocol does not need it. 7451 12. Added a higher layer protocol definition for TLS in 7452 Section 5.7.3. 7454 13. Simplified and restructured the state machine presentation in 7455 Section 6, in particular using a single list for the events and 7456 eliminating the transition tables. Also modified the operation 7457 of the Responder machine to handle retransmitted Query messages 7458 correctly. 7460 14. Re-wrote the route change handling text in Section 7.1 to 7461 clarify the relative responsibilities of GIST and NSLPs and 7462 their interaction through the API. Notifications are now 7463 assumed to be a signalling application responsibility, and GIST 7464 behaviour is defined in terms of handling changes in a 3-state 7465 model of the correctness of the routing state for each 7466 direction. 7468 15. Updated the NAT traversal description in Section 7.2, including 7469 normative text about how GIST nodes should handle messages 7470 containing NAT-Traversal objects. 7472 16. Likewise, clarified that the responsibility for session/flow 7473 binding in the case of tunnelling is handled by NSLPs 7474 (Section 7.3). 7476 17. Formalised the IANA considerations (Section 9). 7478 18. Extended the routing state example (Appendix D) to include a 7479 message sequence for association setup. 7481 19. Re-arranged the sequence of sections, including placing this 7482 change history at the end. 7484 E.7. Changes In Version -07 7486 1. The open issues section has finally been removed in favour of the 7487 authoritative list of open issues in an online issue tracker at h 7488 ttp://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index. 7490 2. Clarified terminology on peering and adjacencies that there may 7491 be NSIS nodes between GIMPS peers that do some message 7492 processing, but that are not explicitly visible in the peer state 7493 tables. 7495 3. Added a description of the loose-end MRM (Section 5.8.2 and 7496 Appendix A.3.1.2). 7498 4. Added a description of an upstream Query encapsulation for the 7499 path-coupled MRM, Section 5.8.1.3, including rationale for and 7500 restrictions on its use. 7502 5. The formal description of the protocol in Section 6 has been 7503 significantly updated and extended in terms of detail. 7505 6. Modified the description of the interaction between NSLPs and 7506 GIMPS for handling inbound messages for which no routing state 7507 exists, to allow the NSLP to indicate whether state setup should 7508 proceed and to provide NSLP payloads for the Response or 7509 forwarded message (Section 3.10, Section 4.3.2 and Appendix B). 7511 7. Included new text, Section 5.6, on the processing and 7512 encapsulation of error messages. Also added formats and an error 7513 message catalogue in Appendix A.4, including a modified format 7514 for the overall GIMPS-Error message and the GIMPS-Error-Data 7515 object. 7517 8. Removed the old section 5.3.3 on NSLPID/RAO setting on the 7518 assumption that this will be covered in the extensibility 7519 document. 7521 9. Included a number of other minor corrections and clarifications. 7523 E.8. Changes In Version -06 7525 Version -06 does not introduce any major structural changes to the 7526 protocol definition, although it does clarify a number of details and 7527 resolve some outstanding open issues. The primary changes are as 7528 follows: 7530 1. Added a new high level Section 3.3 which gathers together the 7531 various aspects of the message routing method concept. 7533 2. Added a new high level Section 3.7 which explains the concept 7534 and significance of the session identifier. Also clarified that 7535 the routing state always depends on the session identifier. 7537 3. Added notes about the level of address validation performed by 7538 GIMPS in Section 4.1.2 and extensions to the API in Appendix B. 7540 4. Split the old Node-Addressing object into a Network-Layer- 7541 Information object and Stack-Configuration-Data object. The 7542 former refers to basic information about a node, and the latter 7543 carries information about messaging association configuration. 7544 Redefined the content of the various handshake messages 7545 accordingly in Section 4.4.1 and Section 5.1. 7547 5. Re-wrote Section 4.4.4 and Section 4.4.5 to clarify the rules on 7548 refresh and purge of routing state and messaging associations. 7549 Also, moved the routing state lifetime into the Network-Layer- 7550 Information object and added a messaging association lifetime to 7551 the Stack- Configuration-Data object (Section 5.2). 7553 6. Added specific message types for errors and MA-Refresh in 7554 Section 5.1. The error object is now GIMPS-specific 7555 (Appendix A.4.1). 7557 7. Moved the Flow-Identifier information about the message routing 7558 method from the general description of the object to the path- 7559 coupled MRM section (Section 5.8.1.1), and made a number of 7560 clarifications to the bit format (Appendix A.3.1.1). 7562 8. Removed text about assumptions on the version numbering of 7563 NSLPs, and restricted the scope of the description of TLV object 7564 formats and extensibility flags to GIMPS rather than the whole 7565 of NSIS (Appendix A). 7567 9. Added a new Section 5.5 explaining the possible relationships 7568 between message types and encapsulation formats. 7570 10. Added a new Section 6 in outline form, to capture the formal 7571 specification of the protocol operation. 7573 11. Added new security sections on cookie requirements (Section 8.5) 7574 and residual threats (Section 8.7). 7576 E.9. Changes In Version -05 7578 Version -05 reformulates the specification, to describe routing state 7579 maintenance in terms of exchanging explicitly identified Query/ 7580 Response/Confirm messages, leaving the upstream/downstream 7581 distinction as a specific detail of how Query messages are 7582 encapsulated. This necessitated widespread changes in the 7583 specification text, especially Section 4.2.1, Section 4.4, 7584 Section 5.1 and Section 5.3 (although the actual message sequences 7585 are unchanged). A number of other issues, especially in the area of 7586 message encapsulation, have also been closed. The main changes are 7587 the following: 7589 1. Added a reference to an individual draft on the Loose End MRM as 7590 a concrete example of an alternative message routing method. 7592 2. Added further text (particularly in Section 2) on what GIMPS 7593 means by the concept of 'session'. 7595 3. Firmed up the selection of UDP as the encapsulation choice for 7596 D-mode, removing the open issue on this topic. 7598 4. Defined the interaction between GIMPS and signalling 7599 applications for communicating about the cryptographic security 7600 properties of how a message will be sent or has been received 7601 (see Section 4.1.2 and Appendix B). 7603 5. Closed the issue on whether Query messages should use the 7604 signalling or flow source address in the IP header; both options 7605 are allowed by local policy and a flag in the common header 7606 indicates which was used. (See Section 5.8.1.2.) 7608 6. Added the necessary information elements to allow the IP hop 7609 count between adjacent GIMPS peers to be measures and reported. 7610 (See Section 5.2.2 and Appendix A.3.3.) 7612 7. The old open-issue text on selection of IP router alert option 7613 values has been moved into the main specification to capture the 7614 technical considerations that should be used in assigning such 7615 values (in old section 5.3.3). 7617 8. Resolved the open issue on lost Confirm messages by allowing a 7618 choice of timer-based retransmission of the Response, or an 7619 error message from the responding node which causes the 7620 retransmission of the Confirm (see Section 5.3.3). 7622 9. Closed the open issue on support for message scoping (this is 7623 now assumed to be a NSLP function). 7625 10. Moved the authoritative text for most of the remaining open 7626 issues to an online issue tracker. 7628 E.10. Changes In Version -04 7630 Version -04 includes mainly clarifications of detail and extensions 7631 in particular technical areas, in part to support ongoing 7632 implementation work. The main details are as follows: 7634 1. Substantially updated Section 4, in particular clarifying the 7635 rules on what messages are sent when and with what payloads 7636 during routing and messaging association setup, and also adding 7637 some further text on message transfer attributes. 7639 2. The description of messaging association protocol setup 7640 including the related object formats has been centralised in a 7641 new Section 5.7, removing the old Section 6.6 and also closing 7642 old open issues 8.5 and 8.6. 7644 3. Made a number of detailed changes in the message format 7645 definitions (Appendix A), as well as incorporating initial rules 7646 for encoding message extensibility information. Also included 7647 explicit formats for a general purpose Error object, and the 7648 objects used to discover supported messaging association 7649 protocols. Updated the corresponding open issues section (old 7650 section 9.3) with a new item on NSLP versioning. 7652 4. Updated the GIMPS API (Appendix B), including more precision on 7653 message transfer attributes, making the NSLP hint about storing 7654 reverse path state a return value rather than a separate 7655 primitive, and adding a new primitive to allow signalling 7656 applications to invalidate GIMPS routing state. Also, added a 7657 new parameter to SendMessage to allow signalling applications to 7658 'bypass' a message statelessly, preserving the source of an 7659 input message. 7661 5. Added an outline for the future content of an IANA 7662 considerations section (Section 9). Currently, this is 7663 restricted to identifying the registries and allocations 7664 required, without defining the allocation policies and other 7665 considerations involved. 7667 6. Shortened the background design discussion in Section 3. 7669 7. Made some clarifications in the terminology section relating to 7670 how the use of C-mode does and does not mandate the use of 7671 transport or security protection. 7673 8. The ABNF for message formats in Section 5.1 has been re-written 7674 with a grammar structured around message purpose rather than 7675 message direction, and additional explanation added to the 7676 information element descriptions in Section 5.2. 7678 9. The description of the D-mode transport in Section 5.3 has been 7679 updated. The encapsulation rules (covering IP addressing and 7680 UDP port allocation) have been corrected, and a new subsection 7681 on message retransmission and rate limiting has been added, 7682 superseding the old open issue on the same subject (section 7683 8.10). 7685 10. A new open issue on IP TTL measurement to detect non-GIMPS 7686 capable hops has been added (old section 9.5). 7688 E.11. Changes In Version -03 7690 Version -03 includes a number of minor clarifications and extensions 7691 compared to version -02, including more details of the GIMPS API and 7692 messaging association setup and the node addressing object. The full 7693 list of changes is as follows: 7695 1. Added a new section pinning down more formally the interaction 7696 between GIMPS and signalling applications (Section 4.1), in 7697 particular the message transfer attributes that signalling 7698 applications can use to control GIMPS (Section 4.1.2). 7700 2. Added a new open issue identifying where the interaction between 7701 the security properties of GIMPS and the security requirements of 7702 signalling applications should be identified (old section 9.10). 7704 3. Added some more text in Section 4.2.1 to clarify that GIMPS has 7705 the (sole) responsibility for generating the messages that 7706 refresh message routing state. 7708 4. Added more clarifying text and table to GHC and IP TTL handling 7709 discussion of Section 4.3.4. 7711 5. Split Section 4.4 into subsections for different scenarios, and 7712 added more detail on Node-Addressing object content and use to 7713 handle the case where association re-use is possible in 7714 Section 4.4.3. 7716 6. Added strawman object formats for Node-Addressing and Stack- 7717 Proposal objects in Section 5.1 and Appendix A. 7719 7. Added more detail on the bundling possibilities and appropriate 7720 configurations for various transport protocols in Section 5.4. 7722 8. Included some more details on NAT traversal in Section 7.2, 7723 including a new object to carry the untranslated address-bearing 7724 payloads, the NAT-Traversal object. 7726 9. Expanded the open issue discussion in old section 9.3 to include 7727 an outline set of extensibility flags. 7729 E.12. Changes In Version -02 7731 Version -02 does not represent any radical change in design or 7732 structure from version -01; the emphasis has been on adding details 7733 in some specific areas and incorporation of comments, including early 7734 review comments. The full list of changes is as follows: 7736 1. Added a new section 1.1 (since removed in version 12) which 7737 summarises restrictions on scope and applicability; some 7738 corresponding changes in terminology in Section 2. 7740 2. Closed the open issue on including explicit GIMPS state teardown 7741 functionality. On balance, it seems that the difficulty of 7742 specifying this correctly (especially taking account of the 7743 security issues in all scenarios) is not matched by the saving 7744 of state enabled. 7746 3. Removed the option of a special class of message transfer for 7747 reliable delivery of a single message. This can be implemented 7748 (inefficiently) as a degenerate case of C-mode if required. 7750 4. Extended Appendix A with a general discussion of rules for 7751 message and object formats across GIMPS and other NSLPs. Some 7752 remaining open issues are noted in old section 9.3 (since 7753 removed). 7755 5. Updated the discussion of RAO/NSLPID relationships to take into 7756 account the proposed message formats and rules for allocation of 7757 NSLP id, and propose considerations for allocation of RAO 7758 values. 7760 6. Modified the description of the information used to route 7761 messages (first given in Section 4.2.1 but also throughout the 7762 document). Previously this was related directly to the flow 7763 identification and described as the Flow-Routing-Information. 7764 Now, this has been renamed Message-Routing-Information, and 7765 identifies a message routing method and any associated 7766 addressing. 7768 7. Modified the text in Section 4.3 and elsewhere to impose sanity 7769 checks on the Message-Routing-Information carried in C-mode 7770 messages, including the case where these messages are part of a 7771 GIMPS-Query/Response exchange. 7773 8. Added rules for message forwarding to prevent message looping in 7774 a new Section 4.3.4, including rules on IP TTL and GIMPS hop 7775 count processing. These take into account the new RAO 7776 considerations described above. 7778 9. Added an outline mechanism for messaging association protocol 7779 stack setup, with the details in a new Section 6.6 and other 7780 changes in Section 4.4 and the various sections on message 7781 formats. 7783 10. Removed the open issue on whether storing reverse routing state 7784 is mandatory or optional. This is now explicit in the API 7785 (under the control of the local NSLP). 7787 11. Added an informative annex describing an abstract API between 7788 GIMPS and NSLPs in Appendix B. 7790 E.13. Changes In Version -01 7792 The major change in version -01 is the elimination of 7793 'intermediaries', i.e. imposing the constraint that signalling 7794 application peers are also GIMPS peers. This has the consequence 7795 that if a signalling application wishes to use two classes of 7796 signalling transport for a given flow, maybe reaching different 7797 subsets of nodes, it must do so by running different signalling 7798 sessions; and it also means that signalling adaptations for passing 7799 through NATs which are not signalling application aware must be 7800 carried out in D-mode. On the other hand, it allows the elimination 7801 of significant complexity in the C-mode handling and also various 7802 other protocol features (such as general route recording). 7804 The full set of changes is as follows: 7806 1. Added a worked example in Section 3.10. 7808 2. Stated that nodes which do not implement the signalling 7809 application should bypass the message (Section 4.3). 7811 3. Decoupled the state handling logic for routing state and 7812 messaging association state in Section 4.4. Also, allow 7813 messaging associations to be used immediately in both directions 7814 once they are opened. 7816 4. Added simple ABNF for the various GIMPS message types in a new 7817 Section 5.1, and more details of the common header and each 7818 object in Section 5.2, including bit formats in Appendix A. The 7819 common header format means that the encapsulation is now the 7820 same for all transport types (Section 5.4). 7822 5. Added some further details on D-mode encapsulation in 7823 Section 5.3, including more explanation of why a well known port 7824 is needed. 7826 6. Removed the possibility for fragmentation over DCCP 7827 (Section 5.4), mainly in the interests of simplicity and loss 7828 amplification. 7830 7. Removed all the tunnel mode encapsulations (old sections 5.3.3 7831 and 5.3.4). 7833 8. Fully re-wrote the route change handling description 7834 (Section 7.1), including some additional detection mechanisms 7835 and more clearly distinguishing between upstream and downstream 7836 route changes. Included further details on GIMPS/NSLP 7837 interactions, including where notifications are delivered and 7838 how local repair storms could be avoided. Removed old 7839 discussion of propagating notifications through signalling 7840 application unaware nodes (since these are now bypassed 7841 automatically). Added discussion on how to route messages for 7842 local state removal on the old path. 7844 9. Revised discussion of policy-based forwarding (old Section 7.2) 7845 to account for actual Flow-Routing-Information definition, and 7846 also how wildcarding should be allowed and handled. 7848 10. Removed old route recording section (old Section 6.3). 7850 11. Extended the discussion of NAT handling (Section 7.2) with an 7851 extended outline on processing rules at a GIMPS-aware NAT and a 7852 pointer to implications for C-mode processing and state 7853 management. 7855 12. Clarified the definition of 'correct routing' of signalling 7856 messages in Section 8 and GIMPS role in enforcing this. Also, 7857 opened the possibility that peer node authentication could be 7858 signalling application dependent. 7860 13. Removed old open issues on C-mode Encapsulation (section 8.7); 7861 added new open issues on Message Routing (old Section 9.3 of 7862 version -05, later moved to Section 3.3) and D-mode congestion 7863 control. 7865 14. Added this change history. 7867 Authors' Addresses 7869 Henning Schulzrinne 7870 Columbia University 7871 Department of Computer Science 7872 450 Computer Science Building 7873 New York, NY 10027 7874 US 7876 Phone: +1 212 939 7042 7877 Email: hgs+nsis@cs.columbia.edu 7878 URI: http://www.cs.columbia.edu 7880 Robert Hancock 7881 Siemens/Roke Manor Research 7882 Old Salisbury Lane 7883 Romsey, Hampshire SO51 0ZN 7884 UK 7886 Email: robert.hancock@roke.co.uk 7887 URI: http://www.roke.co.uk 7889 Full Copyright Statement 7891 Copyright (C) The IETF Trust (2007). 7893 This document is subject to the rights, licenses and restrictions 7894 contained in BCP 78, and except as set forth therein, the authors 7895 retain all their rights. 7897 This document and the information contained herein are provided on an 7898 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 7899 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 7900 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 7901 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 7902 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 7903 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7905 Intellectual Property 7907 The IETF takes no position regarding the validity or scope of any 7908 Intellectual Property Rights or other rights that might be claimed to 7909 pertain to the implementation or use of the technology described in 7910 this document or the extent to which any license under such rights 7911 might or might not be available; nor does it represent that it has 7912 made any independent effort to identify any such rights. Information 7913 on the procedures with respect to rights in RFC documents can be 7914 found in BCP 78 and BCP 79. 7916 Copies of IPR disclosures made to the IETF Secretariat and any 7917 assurances of licenses to be made available, or the result of an 7918 attempt made to obtain a general license or permission for the use of 7919 such proprietary rights by implementers or users of this 7920 specification can be obtained from the IETF on-line IPR repository at 7921 http://www.ietf.org/ipr. 7923 The IETF invites any interested party to bring to its attention any 7924 copyrights, patents or patent applications, or other proprietary 7925 rights that may cover technology that may be required to implement 7926 this standard. Please address the information to the IETF at 7927 ietf-ipr@ietf.org. 7929 Acknowledgment 7931 Funding for the RFC Editor function is provided by the IETF 7932 Administrative Support Activity (IASA).