idnits 2.17.1 draft-ietf-nsis-ntlp-14.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 6890. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 6901. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6908. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6914. 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 -- 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 (July 9, 2007) is 6107 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 240 -- Looks like a reference, but probably isn't: 'Flow' on line 255 -- Looks like a reference, but probably isn't: 'Adjacent' on line 265 -- Looks like a reference, but probably isn't: 'Message' on line 296 -- Looks like a reference, but probably isn't: 'Initialisation' on line 3708 == Unused Reference: '14' is defined on line 5231, 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) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '15') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '18') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '19') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. '21') (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '25') (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. '27') (Obsoleted by RFC 5082) -- Obsolete informational reference (is this intentional?): RFC 3852 (ref. '28') (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 (~~), 8 warnings (==), 19 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: January 10, 2008 Siemens/RMR 6 July 9, 2007 8 GIST: General Internet Signalling Transport 9 draft-ietf-nsis-ntlp-14 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 January 10, 2008. 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 . . . . . . . . 60 81 5.6. Error Message Processing . . . . . . . . . . . . . . . . 61 82 5.7. Messaging Association Setup . . . . . . . . . . . . . . . 62 83 5.8. Specific Message Routing Methods . . . . . . . . . . . . 66 84 6. Formal Protocol Specification . . . . . . . . . . . . . . . . 72 85 6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 74 86 6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 75 87 6.3. Responder Node Processing . . . . . . . . . . . . . . . . 78 88 6.4. Messaging Association Processing . . . . . . . . . . . . 81 89 7. Additional Protocol Features . . . . . . . . . . . . . . . . 85 90 7.1. Route Changes and Local Repair . . . . . . . . . . . . . 85 91 7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 92 92 7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 98 93 7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 98 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 101 95 8.1. Message Confidentiality and Integrity . . . . . . . . . . 101 96 8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 102 97 8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 102 98 8.4. Denial of Service Prevention and Overload Protection . . 104 99 8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 106 100 8.6. Security Protocol Selection Policy . . . . . . . . . . . 108 101 8.7. Residual Threats . . . . . . . . . . . . . . . . . . . . 109 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111 103 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 116 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 105 11.1. Normative References . . . . . . . . . . . . . . . . . . 117 106 11.2. Informative References . . . . . . . . . . . . . . . . . 118 107 Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 121 108 A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 121 109 A.2. General Object Format . . . . . . . . . . . . . . . . . . 122 110 A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 123 111 A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 132 112 Appendix B. API between GIST and Signalling Applications . . . . 141 113 B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 141 114 B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 143 115 B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 144 116 B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 145 117 B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 146 118 B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 146 119 Appendix C. Deployment Issues with Router Alert Options . . . . 148 120 Appendix D. Example Routing State Table and Handshake . . . . . 151 121 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 153 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 156 123 Intellectual Property and Copyright Statements . . . . . . . . . 157 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 signalling. 139 In the context of path-coupled signalling, examples of state 140 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 the current GIST design could be extended to do 147 so, especially in environments where the multicast replication points 148 can be made GIST-capable. GIST can also be extended to cover other 149 types of signalling pattern, not related to any end-to-end flow in 150 the network, in which case the distinction between GIST and end-to- 151 end 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 [29] 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 [29], and the accompanying threats document [30], 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 higher layer 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. The purpose of GIST is thus 178 to provide the common functionality of node discovery, message 179 routing and message transport in a way which is simple for multiple 180 signalling applications to re-use. 182 The structure of this specification is as follows. Section 2 defines 183 terminology, and Section 3 gives an informal overview of the protocol 184 design principles and operation. The normative specification is 185 contained mainly in Section 4 to Section 8. Section 4 describes the 186 message sequences and Section 5 their format and contents. Note that 187 the detailed bit formats are given in Appendix A. The protocol 188 operation is captured in the form of state machines in Section 6. 189 Section 7 describes some more advanced protocol features and security 190 considerations are contained in Section 8. In addition, Appendix B 191 describes an abstract API for the service which GIST provides to 192 signalling applications, and Appendix D provides an example message 193 flow. Parts of the GIST design use packets with IP options to probe 194 the network, which leads to some migration issues in the case of 195 IPv4, and these are discussed in Appendix C. 197 Because of the layered structure of the NSIS protocol suite, protocol 198 extensions to cover a new signalling requirement could be carried out 199 either within GIST, or within the signalling application layer, or 200 both. General guidelines on how to extend different layers of the 201 protocol suite, and in particular when and how it is appropriate to 202 extend GIST, are contained in a separate document. In this document, 203 Section 9 gives the formal IANA considerations for the registries 204 defined by the GIST specification. 206 2. Requirements Notation and Terminology 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in RFC 2119 [4]. In 211 addition, the security specifications in Section 5.7.3 use the 212 terminology MUST- and SHOULD+ from [5]. 214 The terminology used in this specification is defined in this 215 section. The basic entities relevant at the GIST level are shown in 216 Figure 1. In particular, this diagram distinguishes the different 217 address types as being associated with a flow (end-to-end addresses) 218 or signalling (addresses of adjacent signalling peers). 220 Source GIST (adjacent) peer nodes Destination 222 IP address IP addresses = Signalling IP address 223 = Flow Source/Destination Addresses = Flow 224 Source (depending on signalling direction) Destination 225 Address | | Address 226 V V 227 +--------+ +------+ Data Flow +------+ +--------+ 228 | Flow |-----------|------|-------------|------|-------->| Flow | 229 | Sender | | | | | |Receiver| 230 +--------+ | GIST |============>| GIST | +--------+ 231 | Node |<============| Node | 232 +------+ Signalling +------+ 233 GN1 Flow GN2 235 >>>>>>>>>>>>>>>>> = Downstream direction 236 <<<<<<<<<<<<<<<<< = Upstream direction 238 Figure 1: Basic Terminology 240 [Data] Flow: A set of packets identified by some fixed combination 241 of header fields. Flows are unidirectional; a bidirectional 242 communication is considered a pair of unidirectional flows. 244 Session: A single application layer exchange of information for 245 which some state information is to be manipulated or monitored. 246 See Section 3.7 for further detailed discussion. 248 Session Identifier (SID): An identifier for a session; the syntax is 249 a 128 bit value which is opaque to GIST. 251 [Flow] Sender: The node in the network which is the source of the 252 packets in a flow. A sender could be a host, or a router if for 253 example the flow is actually an aggregate. 255 [Flow] Receiver: The node in the network which is the sink for the 256 packets in a flow. 258 Downstream: In the same direction as the data flow. 260 Upstream: In the opposite direction to the data flow. 262 GIST Node: Any node supporting the GIST protocol, regardless of what 263 signalling applications it supports. 265 [Adjacent] Peer: The next node along the signalling path, in the 266 upstream or downstream direction, with which a GIST node 267 explicitly interacts. 269 Querying Node: The GIST node that initiates the handshake process to 270 discover the adjacent peer. 272 Responding Node: The GIST node that responds to the handshake, 273 becoming the adjacent peer to the Querying node. 275 Datagram Mode (D-mode): A mode of sending GIST messages between 276 nodes without using any transport layer state or security 277 protection. Datagram mode uses UDP encapsulation, with source and 278 destination IP addresses derived either from the flow definition 279 or previously discovered adjacency information. 281 Connection Mode (C-mode): A mode of sending GIST messages directly 282 between nodes using point-to-point messaging associations (see 283 below). Connection mode allows the re-use of existing transport 284 and security protocols where such functionality is required. 286 Messaging Association (MA): A single connection between two 287 explicitly identified GIST adjacent peers, i.e. between a given 288 signalling source and destination address. A messaging 289 association may use a transport protocol; if security protection 290 is required, it may use a network layer security association, or 291 use a transport layer security association internally. A 292 messaging association is bidirectional: signalling messages can be 293 sent over it in either direction, referring to flows of either 294 direction. 296 [Message] Routing: Message routing describes the process of 297 determining which is the next GIST peer along the signalling path. 298 For signalling along a flow path, the message routing carried out 299 by GIST is built on top of normal IP routing, that is, forwarding 300 packets within the network layer based on their destination IP 301 address. In this document, the term 'routing' generally refers to 302 GIST message routing unless particularly specified. 304 Message Routing Method (MRM): There can be different algorithms for 305 discovering the route that signalling messages should take. These 306 are referred to as message routing methods, and GIST supports 307 alternatives within a common protocol framework. See Section 3.3. 309 Message Routing Information (MRI): The set of data item values which 310 is used to route a signalling message according to a particular 311 MRM; for example, for routing along a flow path, the MRI includes 312 flow source and destination addresses, protocol and port numbers. 313 See Section 3.3. 315 Router Alert Option (RAO): An option that can be included in IP v4 316 and v6 headers to assist in the packet interception process; see 317 [3] and [8]. 319 Transfer Attributes: A description of the requirements which a 320 signalling application has for the delivery of a particular 321 message; for example, whether the message should be delivered 322 reliably. See Section 4.1.2. 324 3. Design Overview 326 3.1. Overall Design Approach 328 The generic requirements identified in the NSIS framework [29] for 329 transport of signalling messages are essentially two-fold: 331 Routing: Determine how to reach the adjacent signalling node along 332 each direction of the data path (the GIST peer), and if necessary 333 explicitly establish addressing and identity information about 334 that peer; 336 Transport: Deliver the signalling information to that peer. 338 To meet the routing requirement, one possibility is for the node to 339 use local routing state information to determine the identity of the 340 GIST peer explicitly. GIST defines a three-way handshake which 341 probes the network to set up the necessary routing state between 342 adjacent peers, during which signalling applications can also 343 exchange data. Once the routing decision has been made, the node has 344 to select a mechanism for transport of the message to the peer. GIST 345 divides the transport functionality into two parts, a minimal 346 capability provided by GIST itself, with the use of well-understood 347 transport protocols for the harder cases. Here, with details 348 discussed later, the minimal capability is restricted to messages 349 that are sized well below the lowest maximum transmission unit (MTU) 350 along a path, are infrequent enough not to cause concerns about 351 congestion and flow control, and do not need security protection or 352 guaranteed delivery. 354 In [29] all of these routing and transport requirements are assigned 355 to a single notional protocol, the NSIS Transport Layer Protocol 356 (NTLP). The strategy of splitting the transport problem leads to a 357 layered structure for the NTLP, with a specialised GIST messaging 358 layer running over standard transport and security protocols. The 359 basic concept is shown in Figure 2. Note that not every combination 360 of transport and security protocols implied by the figure is actually 361 possible for use in GIST; the actual combinations allowed by this 362 specification are defined in Section 5.7. The figure also shows GIST 363 offering its services to upper layers at an abstract interface, the 364 GIST API, further discussed in Section 4.1. 366 ^^ +-------------+ 367 || | Signalling | 368 NSIS +------------|Application 2| 369 Signalling | Signalling +-------------+ 370 Application |Application 1| | 371 Level +-------------+ | 372 || | | 373 VV | | 374 ========|===================|===== <-- GIST API 375 | | 376 ^^ +------------------------------------------------+ 377 || |+-----------------------+ +--------------+ | 378 || || GIST | | GIST State | | 379 || || Encapsulation |<<<>>>| Maintenance | | 380 || |+-----------------------+ +--------------+ | 381 || | GIST: Messaging Layer | 382 || +------------------------------------------------+ 383 NSIS | | | | 384 Transport .......................................... 385 Level . Transport Layer Security (TLS or DTLS) . 386 (NTLP) .......................................... 387 || | | | | 388 || +----+ +----+ +----+ +----+ 389 || |UDP | |TCP | |SCTP| |DCCP| ... other 390 || +----+ +----+ +----+ +----+ protocols 391 || | | | | 392 || ............................. 393 || . IP Layer Security . 394 || ............................. 395 VV | | | | 396 ===========================|=======|=======|=======|============ 397 | | | | 398 +----------------------------------------------+ 399 | IP | 400 +----------------------------------------------+ 402 Figure 2: Protocol Stack Architecture for Signalling Transport 404 3.2. Modes and Messaging Associations 406 Internally, GIST has two modes of operation: 408 Connection mode (C-mode): used for larger messages or where fast 409 signalling application state setup in the face of packet loss is 410 desirable, or where channel security is required. 412 Datagram mode (D-mode): used for small, infrequent messages with 413 modest delay constraints and no security requirements. A special 414 case of D-mode called Query-mode (Q-mode) is used when no routing 415 state exists. 417 C-mode can in principle use any stream or message-oriented transport 418 protocol; this specification defines TCP as the initial choice. It 419 can in principle employ specific network layer security associations, 420 or an internal transport layer security association; this 421 specification defines TLS as the initial choice. When GIST messages 422 are carried in C-mode, they are treated just like any other traffic 423 by intermediate routers between the GIST peers. Indeed, it would be 424 impossible for intermediate routers to carry out any processing on 425 the messages without terminating the transport and security protocols 426 used. 428 D-mode uses UDP, as a suitable NAT-friendly encapsulation which does 429 not require per-message shared state to be maintained between the 430 peers. Long-term evolution of GIST is assumed to preserve the 431 simplicity of the current D-mode design. Any extension to the 432 security or transport capabilities of D-mode can be viewed as the 433 selection of a different protocol stack under the GIST messaging 434 layer; this is then equivalent to defining another option within the 435 overall C-mode framework. This includes both the case of using 436 existing protocols, and specific development of a message exchange 437 and payload encapsulation to support GIST requirements. 438 Alternatively, if any necessary parameters (e.g. a shared secret for 439 use in integrity or confidentiality protection) can be negotiated 440 out-of-band, then the additional functions can be added directly to 441 D-mode by adding an optional object to the message (see 442 Appendix A.2.1). Note that in such an approach, downgrade attacks as 443 discussed in Section 8.6 would need to be prevented by policy at the 444 destination node. 446 It is possible to mix these two modes along a path. This allows, for 447 example, the use of D-mode at the edges of the network and C-mode in 448 the core of the network. Such combinations may make operation more 449 efficient for mobile endpoints, while allowing shared security 450 associations and transport connections between core routers to be 451 used for messages for multiple flows and signalling applications. 452 The setup for these protocols imposes an initialisation cost for the 453 use of C-mode, but in the long term this cost can be shared over all 454 signalling sessions between peers; once the transport layer state 455 exists, retransmission algorithms can operate much more aggressively 456 than would be possible in a pure D-mode design. 458 It must be understood that the routing and transport functions within 459 by GIST are not independent. If the message transfer has 460 requirements that require C-mode, for example if the message is so 461 large that fragmentation is required, this can only be used between 462 explicitly identified nodes. In such cases, GIST carries out the 463 three-way handshake initially in D-mode to identify the peer and then 464 sets up the necessary connections if they do not already exist. It 465 must also be understood that the signalling application does not make 466 the D-mode/C-mode selection directly; rather, this decision is made 467 by GIST on the basis of the message characteristics and the transfer 468 attributes stated by the application. The distinction is not visible 469 at the GIST service interface. 471 In general, the state associated with C-mode messaging to a 472 particular peer (signalling destination address, protocol and port 473 numbers, internal protocol configuration and state information) is 474 referred to as a messaging association (MA). MAs are totally 475 internal to GIST (they are not visible to signalling applications). 476 Although GIST may be using an MA to deliver messages about a 477 particular flow, there is no direct correspondence between them: the 478 GIST message routing algorithms consider each message in turn and 479 select an appropriate MA to transport it. There may be any number of 480 MAs between two GIST peers although the usual case is zero or one, 481 and they are set up and torn down by management actions within GIST 482 itself. 484 3.3. Message Routing Methods 486 The baseline message routing functionality in GIST is that signalling 487 messages follow a route defined by an existing flow in the network, 488 visiting a subset of the nodes through which it passes. This is the 489 appropriate behaviour for application scenarios where the purpose of 490 the signalling is to manipulate resources for that flow. However, 491 there are scenarios for which other behaviours are applicable. Two 492 examples are: 494 Predictive Routing: Here, the intent is to signal along a path that 495 the data flow may follow in the future. Possible cases are pre- 496 installation of state on the backup path that would be used in the 497 event of a link failure, and predictive installation of state on 498 the path that will be used after a mobile node handover. 500 NAT Address Reservations: This applies to the case where a node 501 behind a NAT wishes to reserve an address at which it can be 502 reached by a sender on the other side. This requires a message to 503 be sent outbound from what will be the flow receiver although no 504 reverse routing state for the flow yet exists. 506 Most of the details of GIST operation are independent of the routing 507 behaviour being used. Therefore, the GIST design encapsulates the 508 routing-dependent details as a message routing method (MRM), and 509 allows multiple MRMs to be defined. This specification defines the 510 path-coupled MRM, corresponding to the baseline functionality 511 described above, and a second ("Loose End") MRM for the NAT Address 512 Reservation case. The detailed specifications are given in 513 Section 5.8. 515 The content of an MRM definition is as follows, using the path- 516 coupled MRM as an example: 518 o The format of the information that describes the path that the 519 signalling should take, the Message Routing Information (MRI). 520 For the path-coupled MRM, this is just the Flow Identifier (see 521 Section 5.8.1.1) and some additional control information. 522 Specifically, the MRI always includes a flag to distinguish 523 between the two directions that signalling messages can take, 524 denoted 'upstream' and 'downstream'. 526 o A specification of the IP-level encapsulation of the messages 527 which probe the network to discover the adjacent peers. A 528 downstream encapsulation must be defined; an upstream 529 encapsulation is optional. For the path-coupled MRM, this 530 information is given in Section 5.8.1.2 and Section 5.8.1.3. 531 Current MRMs rely on the interception of probe messages in the 532 data plane, but other mechanisms are also possible within the 533 overall GIST design and would be appropriate for other types of 534 signalling pattern. 536 o A specification of what validation checks GIST should apply to the 537 probe messages, for example to protect against IP address spoofing 538 attacks. The checks may be dependent on the direction (upstream 539 or downstream) of the message. For the path-coupled MRM, the 540 downstream validity check is basically a form of ingress 541 filtering, also discussed in Section 5.8.1.2. 543 o The mechanism(s) available for route change detection, i.e. any 544 change in the neighbour relationships that the MRM discovers. The 545 default case for any MRM is soft-state refresh, but additional 546 supporting techniques may be possible; see Section 7.1.2. 548 In addition, it should be noted that NAT traversal may require 549 translation of fields in the MRI object carried in GIST messages (see 550 Section 7.2.2). The generic MRI format includes a flag that must be 551 given as part of the MRM definition, to indicate if some kind of 552 translation is necessary. Development of a new MRM therefore 553 includes updates to the GIST specification, and may include updates 554 to specifications of NAT behaviour. These updates may be done in 555 separate documents as is the case for NAT traversal for the MRMs of 556 the base GIST specification, as described in Section 7.2.3 and [41]. 558 The MRI is passed explicitly between signalling applications and 559 GIST; therefore, signalling application specifications must define 560 which MRMs they require. Signalling applications may use fields in 561 the MRI in their packet classifiers; if they use additional 562 information for packet classification, this would be carried at the 563 NSLP level and so would be invisible to GIST. Any node hosting a 564 particular signalling application needs to use a GIST implementation 565 that supports the corresponding MRMs. The GIST processing rules 566 allow nodes not hosting the signalling application to ignore messages 567 for it at the GIST level, so it does not matter if these nodes 568 support the MRM or not. 570 3.4. GIST Messages 572 GIST has six message types: Query, Response, Confirm, Data, Error, 573 and MA-Hello. Apart from the invocation of the messaging association 574 protocols used by C-mode, all GIST communication consists of these 575 messages. In addition, all signalling application data is carried as 576 additional payloads in these messages, alongside the GIST 577 information. 579 The Query, Response and Confirm messages implement the handshake that 580 GIST uses to set up routing state and messaging associations. The 581 handshake is initiated from the Querying node towards the Responding 582 node. The first message is the Query, which is encapsulated in a 583 special way depending on the message routing method, in order to 584 probe the network infrastructure so that the correct peer will 585 intercept it and become the Responding node. A Query always triggers 586 a Response in the reverse direction as the second message of the 587 handshake. The content of the Response controls whether a Confirm 588 message is sent: as part of the defence against denial of service 589 attacks, the Responding node can delay state installation until a 590 return routability check has been performed, and require the Querying 591 node to complete the handshake with the Confirm message. In 592 addition, if the handshake is being used to set up a new MA, the 593 Response is required to request a Confirm. All of these three 594 messages can optionally carry signalling application data. The 595 handshake is fully described in Section 4.4.1. 597 The Data message is used purely to encapsulate and deliver signalling 598 application data. Usually it is sent using pre-established routing 599 state. However, if there are no security or transport requirements 600 and no need for persistent reverse routing state, it can also be sent 601 in the same way as the Query. Finally, Error messages are used to 602 indicate error conditions at the GIST level, and the MA-Hello message 603 can be used as a diagnostic and keepalive for the messaging 604 association protocols. 606 3.5. GIST Peering Relationships 608 Peering is the process whereby two GIST nodes create message routing 609 states which point to each other. 611 A peering relationship can only be created by a GIST handshake. 612 Nodes become peers when one issues a Query and gets a Response from 613 another. Issuing the initial Query is a result of an NSLP request on 614 that node, and the Query itself is formatted according to the rules 615 of the message routing method. For current MRMs, the identity of the 616 Responding node is not known explicitly at the time the Query is 617 sent; instead, the message is examined by nodes along the path until 618 one decides to send a Response, thereby becoming the peer. If the 619 node hosts the NSLP, local GIST and signalling application policy 620 determine whether to peer; the details are given in Section 4.3.2. 621 Nodes not hosting the NSLP forward the Query transparently 622 (Section 4.3.4). 624 An existing peering relationship can only be changed by a new GIST 625 handshake; in other words, it can only change when routing state is 626 refreshed. On a refresh, if any of the factors in the original 627 peering process have changed, the peering relationship can also 628 change. As well as network level rerouting, changes could include 629 modifications to NSIS signalling functions deployed at a node, or 630 alterations to signalling application policy. A change could cause 631 an existing node to drop out of the signalling path, or a new node to 632 become part of it. All these possibilities are handled as rerouting 633 events by GIST; further details of the process are described in 634 Section 7.1. 636 3.6. Effect on Internet Transparency 638 GIST relies on routers inside the network to intercept and process 639 packets which would normally be transmitted end-to-end. This 640 processing may be non-transparent: messages may be forwarded with 641 modifications, or not forwarded at all. This interception applies 642 only to the encapsulation used for the Query messages which probe the 643 network, for example along a flow path; all other GIST messages are 644 handled only by the nodes to which they are directly addressed, i.e. 645 as normal Internet traffic. 647 Because this interception potentially breaks Internet transparency 648 for packets which have nothing to do with GIST, the encapsulation 649 used by GIST in this case (called Query-mode or Q-mode) has several 650 features to avoid accidental collisions with other traffic: 652 o Q-mode messages are always sent as UDP traffic, and to a specific 653 well-known port allocated by IANA. 655 o All GIST messages sent as UDP have a magic number as the first 32- 656 bit word of the datagram payload. 658 Even if a node intercepts a packet as potentially a GIST message, 659 unless it passes both these checks it will be ignored at the GIST 660 level and forwarded transparently. Further discussion of the 661 reception process is in Section 4.3.1 and the encapsulation in 662 Section 5.3. 664 3.7. Signalling Sessions 666 GIST requires signalling applications to associate each of their 667 messages with a signalling session. Informally, given an application 668 layer exchange of information for which some network control state 669 information is to be manipulated or monitored, the corresponding 670 signalling messages should be associated with the same session. 671 Signalling applications provide the session identifier (SID) whenever 672 they wish to send a message, and GIST reports the SID when a message 673 is received; on messages forwarded at the GIST level, the SID is 674 preserved unchanged. Usually, NSLPs will preserve the SID value 675 along the entire signalling path, but this is not enforced by or even 676 visible to GIST, which only sees the scope of the SID as the single 677 hop between adjacent NSLP peers. 679 Most GIST processing and state information is related to the flow 680 (defined by the MRI, see above) and signalling application (given by 681 the NSLP identifier, see below). There are several possible 682 relationships between flows and sessions, for example: 684 o The simplest case is that all signalling messages for the same 685 flow have the same SID. 687 o Messages for more than one flow may use the same SID, for example 688 because one flow is replacing another in a mobility or multihoming 689 scenario. 691 o A single flow may have messages for different SIDs, for example 692 from independently operating signalling applications. 694 Because of this range of options, GIST does not perform any 695 validation on how signalling applications map between flows and 696 sessions, nor does it perform any direct validation on the properties 697 of the SID itself, such as any enforcement of uniqueness. GIST only 698 defines the syntax of the SID as an opaque 128-bit identifier. 700 The SID assignment has the following impact on GIST processing: 702 o Messages with the same SID that are to be delivered reliably 703 between the same GIST peers are delivered in order. 705 o All other messages are handled independently. 707 o GIST identifies routing state (upstream and downstream peer) by 708 the triplet (MRI, NSLP, SID). 710 Strictly speaking, the routing state should not depend on the SID. 711 However, if the routing state is keyed only by (MRI, NSLP), there is 712 a trivial denial of service attack (see Section 8.3) where a 713 malicious off-path node asserts that it is the peer for a particular 714 flow. Such an attack would not redirect the traffic but would 715 reroute the signalling. Instead, the routing state is also 716 segregated between different SIDs, which means that the attacking 717 node can only disrupt a signalling session if it can guess the 718 corresponding SID. Normative rules on the selection of SIDs are 719 given in Section 4.1.3. 721 3.8. Signalling Applications and NSLPIDs 723 The functionality for signalling applications is supported by NSIS 724 signalling layer protocols (NSLPs). Each NSLP is identified by a 16 725 bit NSLP identifier (NSLPID), assigned by IANA (Section 9). A single 726 signalling application, such as resource reservation, may define a 727 family of NSLPs to implement its functionality, for example to carry 728 out signalling operations at different levels in a hierarchy (cf. 729 [22]). However, the interactions between the different NSLPs (for 730 example, to relate aggregation levels or aggregation region 731 boundaries in the resource management case) are handled at the 732 signalling application level; the NSLPID is the only information 733 visible to GIST about the signalling application being used. 735 3.9. GIST Security Services 737 GIST has two distinct security goals: 739 o to protect GIST state from corruption, and to protect the nodes on 740 which it runs from resource exhaustion attacks; and 742 o to provide secure transport for NSLP messages to the signalling 743 applications. 745 The protocol mechanisms to achieve the first goal are mainly internal 746 to GIST. They include a cookie exchange and return routability check 747 to protect the handshake which sets up routing state, and a random 748 SID is also used to prevent off-path session hijacking by SID 749 guessing. Further details are given in Section 4.1.3 and 750 Section 4.4.1, and the overall security aspects are discussed in 751 Section 8. 753 A second level of protection is provided by the use of a channel 754 security protocol in messaging associations (i.e. within C-mode). 755 This mechanism serves two purposes: to protect against on-path 756 attacks on GIST, and to provide a secure channel for NSLP messages. 757 For the mechanism to be effective, it must be able to provide the 758 following functions: 760 o mutual authentication of the GIST peer nodes; 762 o ability to verify the authenticated identity against a database of 763 nodes authorised to take part in GIST signalling; 765 o confidentiality and integrity protection for NSLP data, and 766 provision of the authenticated identities used to the signalling 767 application. 769 The authorised peer database is described in more detail in 770 Section 4.4.2, including the types of entries that it can contain and 771 the authorisation checking algorithm that is used. The only channel 772 security protocol defined by this specification is a basic use of 773 TLS, and Section 5.7.3 defines the TLS-specific aspects of how these 774 functions (for example, authentication and identity comparison) are 775 integrated with the rest of GIST operation. At a high level, there 776 are several alternative protocols with similar functionality, and the 777 handshake (Section 4.4.1) provides a mechanism within GIST to select 778 between them. However, they differ in their identity schemes and 779 authentication methods and dependencies on infrastructure support for 780 the authentication process, and any GIST extension to incorporate 781 them would need to define the details of the corresponding 782 interactions with GIST operation. 784 3.10. Example of Operation 786 This section presents an example of GIST usage in a relatively simple 787 (in particular, NAT-free) signalling scenario, to illustrate its main 788 features. 790 GN1 GN2 791 +------------+ +------------+ 792 NSLP | | | | 793 Level | >>>>>>>>>1 | | 5>>>>>>>>5 | 794 | ^ V | Intermediate | ^ V | 795 |-^--------2-| Routers |-^--------V-| 796 | ^ V | | ^ V | 797 | ^ V | +-----+ +-----+ | ^ V | 798 >>>>>>>>>>^ >3>>>>>>>>4>>>>>>>>>>>4>>>>>>>>>5 5>>>>>>>>> 799 | | | | | | | | 800 GIST | 6<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<6 | 801 Level +------------+ +-----+ +-----+ +------------+ 803 >>>>>, <<<<< = Signalling messages 804 1 - 6 = Stages in the example 805 (stages 7 and 8 are not shown) 807 Figure 3: Example of Operation 809 Consider the case of an RSVP-like signalling application which makes 810 receiver-based resource reservations for a single unicast flow. In 811 general, signalling can take place along the entire end-to-end path 812 (between flow source and destination), but the role of GIST is only 813 to transfer signalling messages over a single segment of the path, 814 between neighbouring resource-capable nodes. Basic GIST operation is 815 the same, whether it involves the endpoints or only interior nodes: 816 in either case, GIST is triggered by a request from a local 817 signalling application. The example here describes how GIST 818 transfers messages between two adjacent peers some distance along the 819 path, GN1 and GN2 (see Figure 3). We take up the story at the point 820 where a message is being processed above the GIST layer by the 821 signalling application in GN1. 823 1. The signalling application in GN1 determines that this message is 824 a simple description of resources that would be appropriate for 825 the flow. It determines that it has no special security or 826 transport requirements for the message, but simply that it should 827 be transferred to the next downstream signalling application peer 828 on the path that the flow will take. 830 2. The message payload is passed to the GIST layer in GN1, along 831 with a definition of the flow and description of the message 832 transfer attributes (in this case, requesting no reliable 833 transmission or channel security protection). GIST determines 834 that this particular message does not require fragmentation and 835 that it has no knowledge of the next peer for this flow and 836 signalling application; however, it also determines that this 837 application is likely to require secured upstream and downstream 838 transport of large messages in the future. This determination is 839 a function of node-internal policy interactions between GIST and 840 the signalling application. 842 3. GN1 therefore constructs a GIST Query carrying the NSLP payload, 843 and additional payloads at the GIST level which will be used to 844 initiate a messaging association. The Query is encapsulated in a 845 UDP datagram and injected into the network. At the IP level, the 846 destination address is the flow receiver, and an IP Router Alert 847 Option (RAO) is also included. 849 4. The Query passes through the network towards the flow receiver, 850 and is seen by each router in turn. GIST-unaware routers will 851 not recognise the RAO value and will forward the message 852 unchanged; GIST-aware routers which do not support the NSLP in 853 question will also forward the message basically unchanged, 854 although they may need to process more of the message to decide 855 this. 857 5. The message is intercepted at GN2. The GIST layer identifies the 858 message as relevant to a local signalling application, and passes 859 the NSLP payload and flow description upwards to it. This 860 signalling application in GN2 indicates to GIST that it will peer 861 with GN1 and so GIST should proceed to set up any routing state. 862 In addition, the signalling application continues to process the 863 message as in GN1 (compare step 1), passing the message back down 864 to GIST so that it is sent further downstream, and this will 865 eventually result in the message reaching the flow receiver. 866 GIST itself operates hop-by-hop, and the signalling application 867 joins these hops together to manage the end-to-end signalling 868 operations. 870 6. In parallel, the GIST instance in GN2 now knows that it should 871 maintain routing state and a messaging association for future 872 signalling with GN1. This is recognised because the message is a 873 Query, and because the local signalling application has indicated 874 that it will peer with GN1. There are two possible cases for 875 sending back the necessary GIST Response: 877 6.A - Association Exists: GN1 and GN2 already have an 878 appropriate MA. GN2 simply records the identity of GN1 as its 879 upstream peer for that flow and NSLP, and sends a Response 880 back to GN1 over the MA identifying itself as the peer for 881 this flow. 883 6.B - No Association: GN2 sends the Response in D-mode directly 884 to GN1, identifying itself and agreeing to the messaging 885 association setup. The protocol exchanges needed to complete 886 this will proceed in parallel with the following stages. 888 In each case, the result is that GN1 and GN2 are now in a peering 889 relationship for the flow. 891 7. Eventually, another NSLP message works its way upstream from the 892 receiver to GN2. This message contains a description of the 893 actual resources requested, along with authorisation and other 894 security information. The signalling application in GN2 passes 895 this payload to the GIST level, along with the flow definition 896 and transfer attributes; in this case, it could request reliable 897 transmission and use of a secure channel for integrity 898 protection. (Other combinations of attributes are possible). 900 8. The GIST layer in GN2 identifies the upstream peer for this flow 901 and NSLP as GN1, and determines that it has an MA with the 902 appropriate properties. The message is queued on the MA for 903 transmission; this may incur some delay if the procedures begun 904 in step 6.B have not yet completed. 906 Further messages can be passed in each direction in the same way. 907 The GIST layer in each node can in parallel carry out maintenance 908 operations such as route change detection (see Section 7.1). 910 It should be understood that several of these details of GIST 911 operations can be varied, either by local policy or according to 912 signalling application requirements. The authoritative details are 913 contained in the remainder of this document. 915 4. GIST Processing Overview 917 This section defines the basic structure and operation of GIST. 918 Section 4.1 describes the way in which GIST interacts with local 919 signalling applications in the form of an abstract service interface. 920 Section 4.2 describes the per-flow and per-peer state that GIST 921 maintains for the purpose of transferring messages. Section 4.3 922 describes how messages are processed in the case where any necessary 923 messaging associations and routing state already exist; this includes 924 the simple scenario of pure D-mode operation, where no messaging 925 associations are necessary. Finally, Section 4.4 describes how 926 routing state and messaging associations are created and managed. 928 4.1. GIST Service Interface 930 This section describes the interaction between GIST and signalling 931 applications in terms of an abstract service interface, including a 932 definition of the attributes of the message transfer that GIST can 933 offer. The service interface presented here is non-normative and 934 does not constrain actual implementations of any interface between 935 GIST and signalling applications; the interface is provided to aid 936 understanding of how GIST can be used. However, requirements on SID 937 selection and internal GIST behaviour to support message transfer 938 semantics (such as in-order delivery) are stated normatively here. 940 The same service interface is presented at every GIST node; however, 941 applications may invoke it differently at different nodes, depending 942 for example on local policy. In addition, the service interface is 943 defined independently of any specific transport protocol, or even the 944 distinction between D-mode and C-mode. The initial version of this 945 specification defines how to support the service interface using a 946 C-mode based on TCP; if additional protocol support is added, this 947 will support the same interface and so the change will be invisible 948 to applications, except as a possible performance improvement. A 949 more detailed description of this service interface is given in 950 Appendix B. 952 4.1.1. Message Handling 954 Fundamentally, GIST provides a simple message-by-message transfer 955 service for use by signalling applications: individual messages are 956 sent, and individual messages are received. At the service 957 interface, the NSLP payload, which is opaque to GIST, is accompanied 958 by control information expressing the application's requirements 959 about how the message should be routed (the MRI), and the application 960 also provides the session identifier (SID), see Section 4.1.3. 961 Additional message transfer attributes control the specific transport 962 and security properties that the signalling application desires. 964 The distinction between GIST D- and C-mode is not visible at the 965 service interface. In addition, the functionality to handle 966 fragmentation and reassembly, bundling together of small messages for 967 efficiency, and congestion control are not visible at the service 968 interface; GIST will take whatever action is necessary based on the 969 properties of the messages and local node state. 971 A signalling application is free to choose the rate at which it 972 processes inbound messages; an implementation MAY allow the 973 application to block accepting messages from GIST. In these 974 circumstances, GIST MAY discard unreliably delivered messages, but 975 for reliable messages MUST propagate flow-control condition back to 976 the sender. Therefore, applications must be aware that they may in 977 turn be blocked from sending outbound messages themselves. 979 4.1.2. Message Transfer Attributes 981 Message transfer attributes are used by NSLPs to define minimum 982 required levels of message processing. The attributes available are 983 as follows: 985 Reliability: This attribute may be 'true' or 'false'. When 'true', 986 messages MUST be delivered to the signalling application in the 987 peer exactly once or not at all; for messages with the same SID, 988 the delivery MUST be in order. If there is a chance that the 989 message was not delivered (e.g. in the case of a transport layer 990 error), an error MUST be indicated to the local signalling 991 application identifying the routing information for the message in 992 question. GIST implements reliability by using an appropriate 993 transport protocol within a messaging association, so mechanisms 994 for the detection of message loss depend on the protocol in 995 question; for the current specification, the case of TCP is 996 considered in Section 5.7.2. When 'false', a message may be 997 delivered, once, several times or not at all, with no error 998 indications in any case. 1000 Security: This attribute defines the set of security properties that 1001 the signalling application requires for the message, including the 1002 type of protection required, and what authenticated identities 1003 should be used for the signalling source and destination. This 1004 information maps onto the corresponding properties of the security 1005 associations established between the peers in C-mode. Keying 1006 material for the security associations is established by the 1007 authentication mechanisms within the messaging association 1008 protocols themselves; see Section 8.2. The attribute can be 1009 specified explicitly by the signalling application, or reported by 1010 GIST to the signalling application. The latter can take place 1011 either on receiving a message, or just before sending a message 1012 but after configuring or selecting the messaging association to be 1013 used for it. 1015 This attribute can also be used to convey information about any 1016 address validation carried out by GIST, such as whether a return 1017 routability check has been carried out. Further details are 1018 discussed in Appendix B. 1020 Local Processing: An NSLP may provide hints to GIST to enable more 1021 efficient or appropriate processing. For example, the NSLP may 1022 select a priority from a range of locally defined values to 1023 influence the sequence in which messages leave a node. Any 1024 priority mechanism MUST respect the ordering requirements for 1025 reliable messages within a session, and priority values are not 1026 carried in the protocol or available at the signalling peer or 1027 intermediate nodes. An NSLP may also indicate that upstream path 1028 routing state will not be needed for this flow, to inhibit the 1029 node requesting its downstream peer to create it; conversely, even 1030 if routing state exists, the NSLP may request that it is not used, 1031 which will lead to GIST Data messages being sent Q-mode 1032 encapsulated instead. 1034 A GIST implementation MAY deliver messages with better performance 1035 than strictly required by the attributes given. 1037 4.1.3. SID Selection 1039 The fact that SIDs index routing state (see Section 4.2.1 below) 1040 means that there are requirements for how they are selected. 1041 Specifically, signalling applications MUST choose SIDs so that they 1042 are cryptographically random, and SHOULD NOT use several SIDs for the 1043 same flow, to avoid additional load from routing state maintenance. 1044 Guidance on secure randomness generation can be found in [31]. 1046 4.2. GIST State 1048 4.2.1. Message Routing State 1050 For each flow, the GIST layer can maintain message routing state to 1051 manage the processing of outgoing messages. This state is 1052 conceptually organised into a table with the following structure. 1053 Each row in the table corresponds to a unique combination of the 1054 following three items: 1056 Message Routing Information (MRI): This defines the method to be 1057 used to route the message, the direction in which to send the 1058 message, and any associated addressing information; see 1059 Section 3.3. 1061 Session Identification (SID): The signalling session with which this 1062 message should be associated; see Section 3.7. 1064 NSLP Identification (NSLPID): This is an IANA-assigned identifier 1065 associated with the NSLP which is generating messages for this 1066 flow; see Section 3.8. The inclusion of this identifier allows 1067 the routing state to be different for different NSLPs. 1069 The information associated with a given {MRI,SID,NSLPID} triplet 1070 consists of the routing state to reach the peer in the direction 1071 given by the MRI. For any flow there will usually be two entries in 1072 the table, one each for the upstream and downstream MRI. The routing 1073 state includes information about the peer identity (see 1074 Section 4.4.3), and a UDP port number for D-mode, or a reference to 1075 one or more MAs for C-mode. Entries in the routing state table are 1076 created by the GIST handshake, which is described in more detail in 1077 Section 4.4. 1079 It is also possible for the state information for either direction to 1080 be empty. There are several possible cases: 1082 o The signalling application has indicated that no messages will 1083 actually be sent in that direction. 1085 o The node is the endpoint of the signalling path, for example 1086 because it is acting as a proxy, or because it has determined that 1087 there are no further signalling nodes in that direction. 1089 o The node is using other techniques to route the message. For 1090 example, it can send it in Q-mode and rely on the peer to 1091 intercept it. 1093 In particular, if the node is a flow endpoint, GIST will refuse to 1094 create routing state for the direction beyond the end of the flow 1095 (see Section 4.3.3). Each entry in the routing state table has an 1096 associated validity timer indicating for how long it can be 1097 considered accurate. When this timer expires, the entry MUST be 1098 purged if it has not been refreshed. Installation and maintenance of 1099 routing state is described in more detail in Section 4.4. 1101 4.2.2. Peer-Peer Messaging Association State 1103 The per-flow message routing state is not the only state stored by 1104 GIST. There is also the state required to manage the MAs. Since 1105 these are not per-flow, they are stored separately from the routing 1106 state, including the following per-MA information: 1108 o a queue of any messages that require the use of an MA, pending 1109 transmission while the MA is being established; 1111 o the time since the peer re-stated its desire to keep the MA open 1112 (see Section 4.4.5). 1114 In addition, per-MA state, such as TCP port numbers or timer 1115 information, is held in the messaging association protocols 1116 themselves. However, the details of this state are not directly 1117 visible to GIST, and they do not affect the rest of the protocol 1118 description. 1120 4.3. Basic GIST Message Processing 1122 This section describes how signalling application messages are 1123 processed in the case where any necessary messaging associations and 1124 routing state are already in place. The description is divided into 1125 several parts. Firstly, message reception, local processing and 1126 message transmission are described for the case where the node hosts 1127 the NSLPID identified in the message. Secondly, in Section 4.3.4, 1128 the case where the message is handled directly in the IP or GIST 1129 layer (because there is no matching signalling application on the 1130 node) is given. An overview is given in Figure 4. This section 1131 concentrates on the GIST level processing, with full details of IP 1132 and transport layer encapsulation in Section 5.3 and Section 5.4. 1134 +---------------------------------------------------------+ 1135 | >> Signalling Application Processing >> | 1136 | | 1137 +--------^---------------------------------------V--------+ 1138 ^ NSLP NSLP V 1139 ^ Payloads Payloads V 1140 +--------^---------------------------------------V--------+ 1141 | >> GIST >> | 1142 | ^ ^ ^ Processing V V V | 1143 +--x-----------N--Q---------------------Q--N-----------x--+ 1144 x N Q Q N x 1145 x N Q>>>>>>>>>>>>>>>>>>>>>Q N x 1146 x N Q Bypass at Q N x 1147 +--x-----+ +--N--Q--+ GIST level +--Q--N--+ +-----x--+ 1148 | C-mode | | D-mode | | D-mode | | C-mode | 1149 |Handling| |Handling| |Handling| |Handling| 1150 +--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+ 1151 x N Q Q N x 1152 x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x 1153 x N Q Bypass at Q N x 1154 +--x--N--+ +-----Q--+ IP (router +--Q-----+ +--N--x--+ 1155 |IP Host | | RAO | alert) level | RAO | |IP Host | 1156 |Handling| |Handling| |Handling| |Handling| 1157 +--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+ 1158 x N Q Q N x 1159 +--x--N-----------Q--+ +--Q-----------N--x--+ 1160 | IP Layer | | IP Layer | 1161 | (Receive Side) | | (Transmit Side) | 1162 +--x--N-----------Q--+ +--Q-----------N--x--+ 1163 x N Q Q N x 1164 x N Q Q N x 1166 NNNNNNNNNNNNNN = Normal D-mode messages 1167 QQQQQQQQQQQQQQ = D-mode messages which are Q-mode encapsulated 1168 xxxxxxxxxxxxxx = C-mode messages 1169 RAO = Router Alert Option 1171 Figure 4: Message Paths through a GIST Node 1173 4.3.1. Message Reception 1175 Messages can be received in C-mode or D-mode. 1177 Reception in C-mode is simple: incoming packets undergo the security 1178 and transport treatment associated with the MA, and the MA provides 1179 complete messages to the GIST layer for further processing. 1181 Reception in D-mode depends on the message type. 1183 Normal encapsulation: Normal messages arrive UDP-encapsulated and 1184 addressed directly to the receiving signalling node, at an address 1185 and port learned previously. Each datagram contains a single 1186 message which is passed to the GIST layer for further processing, 1187 just as in the C-mode case. 1189 Q-mode encapsulation: Where GIST is sending messages to be 1190 intercepted by the appropriate peer rather than directly addressed 1191 to it (in particular, Query messages), these are UDP encapsulated, 1192 and MAY include an IP router alert option (RAO) if required by the 1193 MRM. Each signalling node can therefore see every such message, 1194 but unless the message exactly matches the Q-mode encapsulation 1195 rules (Section 5.3.2) it MUST be forwarded transparently at the IP 1196 level. If it does match, GIST MUST check the NSLPID in the common 1197 header. The case where the NSLPID does not match a local 1198 signalling application at all is considered below in 1199 Section 4.3.4; otherwise, the message MUST be passed up to the 1200 GIST layer for further processing. 1202 Several different RAO values may be used by the NSIS protocol suite. 1203 GIST itself does not allocate any RAO values (for either IPv4 or 1204 IPv6); an assignment is made for each NSLP using MRMs that use the 1205 RAO in the Q-mode encapsulation. The assignment rationale is 1206 discussed in a separate document. The RAO value assigned for an 1207 NSLPID may be different for IPv4 and IPv6. Note the different 1208 significance between the RAO and the NSLPID values: the meaning of a 1209 message (which signalling application it refers to, whether it should 1210 be processed at a node) is determined only from the NSLPID; the role 1211 of the RAO value is simply to allow nodes to pre-filter which IP 1212 datagrams are analysed to see if they might be Q-mode GIST messages. 1214 For all assignments associated with NSIS, the RAO specific processing 1215 is the same and is as defined by this specification, here and in 1216 Section 4.3.4 and Section 5.3.2. 1218 Immediately after reception, the GIST hop count is checked. Any 1219 message with a GIST hop count of zero MUST be rejected with a "Hop 1220 Limit Exceeded" error message (Appendix A.4.4.2); note that a correct 1221 GIST implementation will never send such a message. Otherwise, the 1222 GIST hop count MUST be decremented by one before the next stage. 1224 4.3.2. Local Processing and Validation 1226 Once a message has been received, it is processed locally within the 1227 GIST layer. Further processing depends on the message type and 1228 payloads carried; most of the GIST payloads are associated with 1229 internal state maintenance, and details are covered in Section 4.4. 1230 This section concentrates on the interaction with the signalling 1231 application, in particular the decision to peer and how data is 1232 delivered to the NSLP. 1234 In the case of a Query, there is an interaction with the signalling 1235 application to determine which of two courses to follow. The first 1236 option (peering) MUST be chosen if the node is the final destination 1237 of the Query message, or if the GIST hop count has reached zero. 1239 1. The receiving signalling application wishes to become a 1240 signalling peer with the Querying node. GIST MUST continue with 1241 the handshake process to set up message routing state, as 1242 described in Section 4.4.1. The application MAY provide an NSLP 1243 payload for the same NSLPID, which GIST will transfer in the 1244 Response. 1246 2. The signalling application does not wish to set up state with the 1247 Querying node and become its peer. This includes the case where 1248 a node wishes to avoid taking part in the signalling for overload 1249 protection reasons. GIST MUST propagate the Query, similar to 1250 the case described in Section 4.3.4. No message is sent back to 1251 the Querying node. The application MAY provide an updated NSLP 1252 payload for the same NSLPID, which will be used in the Query 1253 forwarded by GIST. Note that if the node which finally processes 1254 the Query returns an Error message, this will be sent directly 1255 back to the originating node, bypassing any forwarders. For 1256 these diagnostics to be meaningful, any GIST node forwarding a 1257 Query MUST NOT modify it except in the NSLP payload and GIST hop 1258 count; in particular, it MUST NOT modify any other GIST payloads 1259 or their order. An implementation MAY choose to achieve this by 1260 retaining the original message, rather than reconstructing it 1261 from some parsed internal representation. 1263 This interaction with the signalling application, including the 1264 generation or update of an NSLP payload, SHOULD take place 1265 synchronously as part of the Query processing. In terms of the GIST 1266 service interface, this can be implemented by providing appropriate 1267 return values for the primitive that is triggered when such a message 1268 is received; see Appendix B.2 for further discussion. 1270 For all GIST message types other than Queries, if the message 1271 includes an NSLP payload, this MUST be delivered locally to the 1272 signalling application identified by the NSLPID. The format of the 1273 payload is not constrained by GIST, and the content is not 1274 interpreted. Delivery is subject to the following validation checks 1275 which MUST be applied in the sequence given: 1277 1. if the message was explicitly routed (see Section 7.1.5) or is a 1278 Data message delivered without routing state (see Section 5.3.2), 1279 the payload is delivered but flagged to the receiving NSLP to 1280 indicate that routing state was not validated; 1282 2. else, if the message arrived on an association which is not 1283 associated with the MRI/NSLPID/SID combination given in the 1284 message, the message MUST be rejected with an "Incorrectly 1285 Delivered Message" error message (Appendix A.4.4.4); 1287 3. else, if there is no routing state for this MRI/SID/NSLPID the 1288 message MUST either be dropped or be rejected with a error 1289 message (see Section 4.4.6 for further details); 1291 4. else, the payload is delivered as normal. 1293 4.3.3. Message Transmission 1295 Signalling applications can generate their messages for transmission, 1296 either asynchronously, or in reply to an input message delivered by 1297 GIST, and GIST can also generate messages autonomously. GIST MUST 1298 verify that it is not the direct destination of an outgoing message, 1299 and MUST reject such messages with an error indication to the 1300 signalling application. When the message is generated by a 1301 signalling application, it may be carried in a Query if local policy 1302 and the message transfer attributes allow it; otherwise this may 1303 trigger setup of an MA over which the NSLP payload is sent in a Data 1304 message. 1306 Signalling applications may specify a value to be used for the GIST 1307 hop count; otherwise, GIST selects a value itself. GIST MUST reject 1308 messages for which the signalling application has specified a value 1309 of zero. Although the GIST hop count is only intended to control 1310 message looping at the GIST level, the GIST API (Appendix B) provides 1311 the incoming hop count to the NSLPs, which can preserve it on 1312 outgoing messages as they are forwarded further along the path. This 1313 provides a lightweight loop-control mechanism for NSLPs which do not 1314 define anything more sophisticated. Note that the count will be 1315 decremented on forwarding through every GIST-aware node. Initial 1316 values for the GIST hop count are an implementation matter; one 1317 suitable approach is to use the same algorithm as for IP TTL setting 1318 [1]. 1320 When a message is available for transmission, GIST uses internal 1321 policy and the stored routing state to determine how to handle it. 1322 The following processing applies equally to locally generated 1323 messages and messages forwarded from within the GIST or signalling 1324 application levels. However, see Section 5.6 for special rules 1325 applying to the transmission of error messages by GIST. 1327 The main decision is whether the message must be sent in C-mode or 1328 D-mode. Reasons for using C-mode are: 1330 o message transfer attributes: for example, the signalling 1331 application has specified security attributes that require 1332 channel-secured delivery, or reliable delivery. 1334 o message size: a message whose size (including the GIST header, 1335 GIST objects and any NSLP payload, and an allowance for the IP and 1336 transport layer encapsulation required by D-mode) exceeds a 1337 fragmentation-related threshold MUST be sent over C-mode, using a 1338 messaging association that supports fragmentation and reassembly 1339 internally. The allowance for IP and transport layer 1340 encapsulation is 64 bytes. The message size MUST NOT exceed the 1341 Path MTU to the next peer, if this is known. If this is not 1342 known, the message size MUST NOT exceed the least of the first-hop 1343 MTU, and 576 bytes. The same limit applies to IPv4 and IPv6. 1345 o congestion control: D-mode SHOULD NOT be used for signalling where 1346 it is possible to set up routing state and use C-mode, unless the 1347 network can be engineered to guarantee capacity for D-mode traffic 1348 within the rate control limits imposed by GIST (see 1349 Section 5.3.3). 1351 In principle, as well as determining that some messaging association 1352 must be used, GIST MAY select between a set of alternatives, e.g. for 1353 load sharing or because different messaging associations provide 1354 different transport or security attributes. For the case of reliable 1355 delivery, GIST MUST NOT distribute messages for the same session over 1356 multiple messaging associations in parallel, but MUST use a single 1357 association at any given time. The case of moving over to a new 1358 association is covered in Section 4.4.5. 1360 If the use of a messaging association (i.e. C-mode) is selected, the 1361 message is queued on the association found from the routing state 1362 table, and further output processing is carried out according to the 1363 details of the protocol stacks used. If no appropriate association 1364 exists, the message is queued while one is created (see 1365 Section 4.4.1), which will trigger the exchange of additional GIST 1366 messages. If no association can be created, this is an error 1367 condition, and should be indicated back to the local signalling 1368 application. 1370 If a messaging association is not appropriate, the message is sent in 1371 D-mode. The processing in this case depends on the message type, 1372 local policy, and whether routing state exists or not. 1374 o If the message is not a Query, and local policy does not request 1375 the use of Q-mode for this message, and routing state exists, it 1376 is sent with the normal D-mode encapsulation directly to the 1377 address from the routing state table. 1379 o If the message is a Query, or the message is Data and local policy 1380 as given by the message transfer attributes request the use of 1381 Q-mode, then it is sent in Q-mode as defined in Section 5.3.2; the 1382 details depend on the message routing method. 1384 o If no routing state exists, GIST can attempt to use Q-mode as in 1385 the Query case: either sending a Data message with the Q-mode 1386 encapsulation, or using the event as a trigger for routing state 1387 setup (see Section 4.4). If this is not possible, e.g. because 1388 the encapsulation for the MRM is only defined for one message 1389 direction, then this is an error condition which is reported back 1390 to the local signalling application. 1392 4.3.4. Nodes not Hosting the NSLP 1394 A node may receive messages where it has no signalling application 1395 corresponding to the message NSLPID. There are several possible 1396 cases depending mainly on the encapsulation: 1398 1. A message contains an RAO value which is relevant to NSIS, but it 1399 does not exactly match the Q-mode encapsulation rules of 1400 Section 5.3.2. The message MUST be transparently forwarded at 1401 the IP layer. See Section 3.6. 1403 2. A Q-mode encapsulated message contains an RAO value which has 1404 been assigned to some NSIS signalling application but which is 1405 not used on this specific node, but the IP layer is unable to 1406 distinguish whether it needs to be passed to GIST for further 1407 processing or whether the packet should be forwarded just like a 1408 normal IP datagram. 1410 3. A Q-mode encapsulated message contains an RAO value which has 1411 been assigned to an NSIS signalling application which is used on 1412 this node, but the signalling application does not process the 1413 specific NSLPID in the message. (This covers the case where a 1414 signalling application uses a set of NSLPIDs.) 1416 4. A directly addressed message (in D-mode or C-mode) is delivered 1417 to a node for which there is no corresponding signalling 1418 application. With the current specification, this should not 1419 happen in normal operation. While future versions might find a 1420 use for such a feature, currently this MUST cause an "Unknown 1421 NSLPID" error message, Appendix A.4.4.6. 1423 5. A Q-mode encapsulated message arrives at the end-system which 1424 does not handle the signalling application. This is possible in 1425 normal operation, and MUST be indicated to the sender with an 1426 "Endpoint Found" informational message (Appendix A.4.4.7). The 1427 end-system includes the MRI and SID from the original message in 1428 the error message without interpreting them. 1430 6. The node is GIST-aware NAT. See Section 7.2. 1432 In cases (2) and (3), the role of GIST is to forward the message 1433 essentially as though it were a normal IP datagram, and it will not 1434 become a peer to the node sending the message. Forwarding with 1435 modified NSLP payloads is covered above in Section 4.3.2. However, a 1436 GIST implementation MUST ensure that the IP-layer TTL field and GIST 1437 hop count are managed correctly to prevent message looping, and this 1438 should be done consistently independently of whether the processing 1439 takes place on the fast path or in GIST-specific code. The rules are 1440 that in cases (2) and (3), the IP-layer TTL MUST be decremented just 1441 as if the message was a normal IP forwarded packet; in case (3) the 1442 GIST hop count MUST be decremented as in the case of normal input 1443 processing, which also applies to cases (4) and (5). 1445 A GIST node processing Q-mode encapsulated messages in this way 1446 SHOULD make the routing decision based on the full contents of the 1447 MRI and not only the IP destination address. It MAY also apply a 1448 restricted set of sanity checks and under certain conditions return 1449 an error message rather than forward the message. These conditions 1450 are: 1452 1. The message is so large that it would be fragmented on downstream 1453 links, for example because the downstream MTU is abnormally small 1454 (less than 576 bytes). The error "Message Too Large" 1455 (Appendix A.4.4.8) SHOULD be returned to the sender, which SHOULD 1456 begin messaging association setup. 1458 2. The GIST hop count has reached zero. The error "Hop Limit 1459 Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender, 1460 which MAY retry with a larger initial hop count. 1462 3. The MRI represents a flow definition which is too general to be 1463 forwarded along a unique path (e.g. the destination address 1464 prefix is too short). The error "MRI Validation Failure" 1465 (Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be 1466 returned to the sender, which MAY retry with restricted MRIs, 1467 possibly starting additional signalling sessions to do so. If 1468 the GIST node does not understand the MRM in question it MUST NOT 1469 apply this check, instead forwarding the message transparently. 1471 In the first two cases, only the common header of the GIST message is 1472 examined; in the third case, the MRI is also examined. The rest of 1473 the message MUST NOT be inspected in any case. Similar to the case 1474 of Section 4.3.2, the GIST payloads MUST NOT be modified or re- 1475 ordered; an implementation MAY choose to achieve this by retaining 1476 the original message, rather than reconstructing it from some parsed 1477 internal representation. 1479 4.4. Routing State and Messaging Association Maintenance 1481 The main responsibility of GIST is to manage the routing state and 1482 messaging associations which are used in the message processing 1483 described above. Routing state is installed and refreshed by GIST 1484 handshake messages. Messaging associations are set up by the normal 1485 procedures of the transport and security protocols that comprise 1486 them, using peer IP addresses from the routing state. Once a 1487 messaging association has been created, its refresh and expiration 1488 can be managed independently from the routing state. 1490 There are two different cases for state installation and refresh: 1492 1. Where routing state is being discovered or a new association is 1493 to be established; and 1495 2. Where a suitable association already exists, including the case 1496 where routing state for the flow is being refreshed. 1498 These cases are now considered in turn, followed by the case of 1499 background general management procedures. 1501 4.4.1. Routing State and Messaging Association Creation 1503 The complete sequence of possible messages for GIST state setup 1504 between adjacent peers is shown in Figure 5 and described in detail 1505 in the following text. The figure informally summarises the contents 1506 of each message, including optional elements in square brackets. An 1507 example is given in Appendix D. 1509 The initial message in any routing state maintenance operation is a 1510 Query, sent from the querying node and intercepted at the responding 1511 node. This message has addressing and other identifiers appropriate 1512 for the flow and signalling application that state maintenance is 1513 being done for, addressing information about the node that generated 1514 the Query itself, and it MAY contain an NSLP payload. It also 1515 includes a Query Cookie, and optionally capability information about 1516 messaging association protocol stacks. The role of the cookies in 1517 this and subsequent messages is to protect against certain denial of 1518 service attacks and to correlate the various events in the message 1519 sequence (see Section 8.5 for further details). 1521 Provided that the signalling application has indicated that message 1522 routing state should be set up (see Section 4.3.2), reception of a 1523 Query MUST elicit a Response. This is a normally encapsulated D-mode 1524 message with additional GIST payloads. It contains network layer 1525 information about the responding node, echoes the Query Cookie, and 1526 MAY contain an NSLP payload, possibly a reply to the NSLP payload in 1527 the initial message. In case a messaging association was requested, 1528 it MUST also contain a Responder Cookie and its own capability 1529 information about messaging association protocol stacks. Even if a 1530 messaging association is not requested, the Response MAY still 1531 include a Responder Cookie if the node's routing state setup policy 1532 requires it (see below). 1534 +----------+ +----------+ 1535 | Querying | |Responding| 1536 | Node(Q-N)| | Node(R-N)| 1537 +----------+ +----------+ 1538 Query 1539 ----------------------> ............. 1540 Router Alert Option . Routing . 1541 MRI/SID/NSLPID . state . 1542 Q-N Network Layer Info . installed . 1543 Query Cookie . at . 1544 [Q-N Stack-Proposal . Responding. 1545 Q-N Stack-Config-Data] . node . 1546 [NSLP Payload] . (case 1) . 1547 ............. 1548 ...................................... 1549 . The responder can use an existing . 1550 . messaging association if available . 1551 . from here onwards to short-circuit . 1552 . messaging association setup . 1553 ...................................... 1555 Response 1556 ............. <---------------------- 1557 . Routing . MRI/SID/NSLPID 1558 . state . R-N Network Layer Info 1559 . installed . Query cookie 1560 . at . [Responder Cookie 1561 . Querying . [R-N Stack-Proposal 1562 . node . R-N Stack-Config-Data]] 1563 ............. [NSLP Payload] 1565 .................................... 1566 . If a messaging association needs . 1567 . to be created, it is set up here . 1568 . and the Confirm uses it . 1569 .................................... 1571 Confirm ............. 1572 ----------------------> . Routing . 1573 MRI/SID/NSLPID . state . 1574 Q-N Network Layer Info . installed . 1575 [Responder Cookie . at . 1576 [R-N Stack-Proposal . Responding. 1577 [Q-N Stack-Config-Data]]] . node . 1578 [NSLP Payload] . (case 2) . 1579 ............. 1581 Figure 5: Message Sequence at State Setup 1583 Setup of a new messaging association begins when peer addressing 1584 information is available and a new messaging association is actually 1585 needed. Any setup MUST take place immediately after the specific 1586 Query/Response exchange, because the addressing information used may 1587 have a limited lifetime, either because it depends on limited 1588 lifetime NAT bindings or because it refers to agile destination ports 1589 for the transport protocols. The Stack-Proposal and Stack- 1590 Configuration-Data objects carried in the exchange carry capability 1591 information about what messaging association protocols can be used, 1592 and the processing of these objects is described in more detail in 1593 Section 5.7. With the protocol options currently defined, setup of 1594 the messaging association always starts from the Querying node, 1595 although more flexible configurations are possible within the overall 1596 GIST design. If the messaging association includes a channel 1597 security protocol, each GIST node MUST verify the authenticated 1598 identity of the peer against its authorised peer database, and if 1599 there is no match the messaging association MUST be torn down. The 1600 database and authorisation check are described in more detail in 1601 Section 4.4.2 below. Note that the verification can depend on what 1602 the MA is to be used for (e.g. for which MRI or session), so this 1603 step may not be possible immediately after authentication has 1604 completed but some time later. 1606 Finally, after any necessary messaging association setup has 1607 completed, a Confirm MUST be sent if the Response requested it. Once 1608 the Confirm has been sent, the Querying node assumes that routing 1609 state has been installed at the responder, and can send normal Data 1610 messages for the flow in question; recovery from a lost Confirm is 1611 discussed in Section 5.3.3. If a messaging association is being 1612 used, the Confirm MUST be sent over it before any other messages for 1613 the same flow, and it echoes the Responder Cookie and Stack-Proposal 1614 from the Response. The former is used to allow the receiver to 1615 validate the contents of the message (see Section 8.5), and the 1616 latter is to prevent certain bidding-down attacks on messaging 1617 association security (see Section 8.6). This first Confirm on a new 1618 association MUST also contain a Stack-Configuration-Data object 1619 carrying an MA-Hold-Time value, which supersedes the value given in 1620 the original Query. The association can be used in the upstream 1621 direction for the MRI and NSLPID carried in the Confirm, after the 1622 Confirm has been received. 1624 The querying node MUST install the responder address, derived from 1625 the R-Node Network Layer info, as routing state information after 1626 verifying the Query Cookie in the Response. The responding node MAY 1627 install the querying address as peer state information at two points 1628 in time: 1630 Case 1: after the receipt of the initial Query, or 1632 Case 2: after a Confirm containing the Responder Cookie. 1634 The responding node SHOULD derive the peer address from the Q-Node 1635 Network Layer Info if this was decoded successfully. Otherwise, it 1636 MAY be derived from the IP source address of the message if the 1637 common header flags this as being the signalling source address. The 1638 precise constraints on when state information is installed are a 1639 matter of security policy considerations on prevention of denial-of- 1640 service attacks and state poisoning attacks, which are discussed 1641 further in Section 8. Because the responding node MAY choose to 1642 delay state installation as in case (2), the Confirm must contain 1643 sufficient information to allow it to be processed in the same way as 1644 the original Query. This places some special requirements on NAT 1645 traversal and cookie functionality, which are discussed in 1646 Section 7.2 and Section 8 respectively. 1648 4.4.2. GIST Peer Authorisation 1650 When two GIST nodes authenticate using a messaging association, both 1651 ends have to decide whether to accept the creation of the MA and 1652 whether to trust the information sent over it. This can be seen as 1653 an authorisation decision: 1655 o Authorised peers are trusted to install correct routing state 1656 about themselves and not, for example, to claim that they are on- 1657 path for a flow when they are not. 1659 o Authorised peers are trusted to obey transport and application 1660 level flow control rules, and not to attempt to create overload 1661 situations. 1663 o Authorised peers are trusted not to send erroneous or malicious 1664 error messages, for example asserting that routing state has been 1665 lost when it has not. 1667 This specification models the decision as verification by the 1668 authorising node of the peer's identity against a local list of 1669 peers, the authorised peer database (APD). The APD is an abstract 1670 construct, similar to the security policy database of IPsec [36]. 1671 Implementations MAY provide the associated functionality in any way 1672 they choose. This section defines only the requirements for APD 1673 administration and the consequences of successfully validating a 1674 peer's identity against it. 1676 The APD consists of a list of entries. Each entry includes an 1677 identity, the namespace from which the identity comes (e.g. DNS 1678 domains), the scope within which the entry is applicable, and whether 1679 authorisation is allowed or denied. The following are example 1680 scopes: 1682 Peer Address Ownership: The scope is the IP address at which the 1683 peer for this MRI should be; the APD entry denotes the identity as 1684 the owner of address. If the authorising node can determine this 1685 address from local information (such as its own routing tables), 1686 matching this entry shows that the peer is the correct on-path 1687 node and so should be authorised. The determination is simple if 1688 the peer is one IP hop downstream, since the IP address can be 1689 derived from the router's forwarding tables. If the peer is more 1690 than one hop away or is upstream, the determination is harder but 1691 may still be possible in some circumstances. The authorising node 1692 may be able to determine a (small) set of possible peer addresses, 1693 and accept that any of these could be the correct peer. 1695 End-System Subnet: The scope is an address range within which the 1696 MRI source or destination lie; the APD entry denotes the identity 1697 as potentially being on-path between the authorising node and that 1698 address range. There may be different source and destination 1699 scopes, to account for asymmetric routing. 1701 The same identity may appear in multiple entries, and the order of 1702 entries in the APD is significant. When a messaging association is 1703 authenticated and associated with an MRI, the authorising node scans 1704 the APD to find the first entry where the identity matches that 1705 presented by the peer, and where the scope information matches the 1706 circumstances for which the MA is being set up. The identity 1707 matching process itself depends on the messaging association protocol 1708 that carries out the authentication, and details for TLS are given in 1709 Section 5.7.3. Whenever the full set of possible peers for a 1710 specific scope is known, deny entries SHOULD be added for the 1711 wildcard identity to reject signalling associations from unknown 1712 nodes. The ability of the authorising node to reject inappropriate 1713 MAs depends directly on the granularity of the APD and the precision 1714 of the scope matching process. 1716 If authorisation is allowed, the MA can be used as normal; otherwise 1717 it MUST be torn down without further GIST exchanges, and any routing 1718 state associated with the MA MUST also be deleted. An error 1719 condition MAY be logged locally. When an APD entry is modified or 1720 deleted, the node MUST re-validate existing MAs and the routing state 1721 table against the revised contents of the APD. This may result in 1722 MAs being torn down or routing state entries being deleted. These 1723 changes SHOULD be indicated to local signalling applications via the 1724 NetworkNotification API call (Appendix B.4). 1726 This specification does not define how the APD is populated. As a 1727 minimum, an implementation MUST provide an administrative interface 1728 through which entries can be added, modified, or deleted. More 1729 sophisticated mechanisms are possible in some scenarios. For 1730 example, the fact that a node is legitimately associated with a 1731 specific IP address could be established by direct embedding of the 1732 IP address as a particular identity type in a certificate, or by a 1733 mapping that address to another identifier type via an additional 1734 database lookup (such as relating IP addresses in in-addr.arpa to 1735 domain names). An enterprise network operator could generate a list 1736 of all the identities of its border nodes as authorised to be on the 1737 signalling path to external destinations, and this could be 1738 distributed to all hosts inside the network. Regardless of the 1739 technique, it MUST be ensured that the source data justify the 1740 authorisation decisions listed at the start of this section, and that 1741 the security of the chain of operations on which the APD entry 1742 depends cannot be compromised. 1744 4.4.3. Messaging Association Multiplexing 1746 It is a design goal of GIST that, as far as possible, a single 1747 messaging association should be used for multiple flows and sessions 1748 between two peers, rather than setting up a new MA for each. This 1749 re-use of existing MAs is referred to as messaging association 1750 multiplexing. Multiplexing ensures that the MA cost scales only with 1751 the number of peers, and avoids the latency of new MA setup where 1752 possible. 1754 However, multiplexing requires the identification of an existing MA 1755 which matches the same routing state and desired properties that 1756 would be the result of a normal handshake in D-mode, and this 1757 identification must be done as reliably and securely as continuing 1758 with this procedure. Note that this requirement is complicated by 1759 the fact that NATs may remap the node addresses in D-mode messages, 1760 and also interacts with the fact that some nodes may peer over 1761 multiple interfaces (and thus with different addresses). 1763 MA multiplexing is controlled by the Network-Layer-Information (NLI) 1764 object, which is carried in Query, Response and Confirm messages. 1765 The NLI object includes (among other elements): 1767 Peer-Identity: For a given node, this is an interface independent 1768 value with opaque syntax. It MUST be chosen so as to have a high 1769 probability of uniqueness across the set of all potential peers, 1770 and SHOULD be stable at least until the next node restart. Note 1771 that there is no cryptographic protection of this identity; 1772 attempting to provide this would essentially duplicate the 1773 functionality in the messaging association security protocols. 1775 For routers, the Router-ID [2], which is one of the router's IP 1776 addresses, MAY be used as one possible value for the Peer- 1777 Identity. In scenarios with nested NATs, the Router-ID alone may 1778 not satisfy the uniqueness requirements, in which case it MAY be 1779 extended with additional tokens, either chosen randomly or 1780 administratively coordinated. 1782 Interface-Address: This is an IP address through which the 1783 signalling node can be reached. There may be several choices 1784 available for the Interface-Address, and further discussion of 1785 this is contained in Section 5.2.2. 1787 A messaging association is associated with the NLI object that was 1788 provided by the peer in the Query/Response/Confirm at the time the 1789 association was first set up. There may be more than one MA for a 1790 given NLI object, for example with different security or transport 1791 properties. 1793 MA multiplexing is achieved by matching these two elements from the 1794 NLI provided in a new GIST message with one associated with an 1795 existing MA. The message can be either a Query or Response, although 1796 the former is more likely: 1798 o If there is a perfect match to an existing association, that 1799 association SHOULD be re-used, provided it meets the criteria on 1800 security and transport properties given at the end of 1801 Section 5.7.1. This is indicated by sending the remaining 1802 messages in the handshake over that association. This will lead 1803 to multiplexing on an association to the wrong node if signalling 1804 nodes have colliding Peer-Identities and one is reachable at the 1805 same Interface-Address as another. This could be caused by an on- 1806 path attacker; on-path attacks are discussed further in 1807 Section 8.7. When multiplexing is done, and the original MA 1808 authorisation was MRI-dependent, the verification steps of 1809 Section 4.4.2 MUST be repeated for the new flow. 1811 o In all other cases, the handshake MUST be executed in D-mode as 1812 usual. There are in fact four possibilities: 1814 1. Nothing matches: this is clearly a new peer. 1816 2. Only the Peer-Identity matches: this may be either a new 1817 interface on an existing peer, or a changed address mapping 1818 behind a NAT. These should be rare events, so the expense of 1819 a new association setup is acceptable. Another possibility is 1820 one node using another node's Peer-Identity, for example as 1821 some kind of attack. Because the Peer-Identity is used only 1822 for this multiplexing process, the only consequence this has 1823 is to require a new association setup, and this is considered 1824 in Section 8.4. 1826 3. Only the Interface-Address matches: this is probably a new 1827 peer behind the same NAT as an existing one. A new 1828 association setup is required. 1830 4. Both elements of the NLI object match: this is a degenerate 1831 case, where one node recognises an existing peer, but wishes 1832 to allow the option to set up a new association in any case, 1833 for example to create an association with different 1834 properties. 1836 4.4.4. Routing State Maintenance 1838 Each item of routing state expires after a lifetime which is 1839 negotiated during the Query/Response/Confirm handshake. The Network 1840 Layer Info (NLI) object in the Query contains a proposal for the 1841 lifetime value, and the NLI in the Response contains the value the 1842 Responding node requires. A default timer value of 30 seconds is 1843 RECOMMENDED. Nodes which can exploit alternative, more powerful, 1844 route change detection methods such as those described in 1845 Section 7.1.2 MAY choose to use much longer times. Nodes MAY use 1846 shorter times to provide more rapid change detection. If the number 1847 of active routing state items corresponds to a rate of Queries that 1848 will stress the rate limits applied to D-mode traffic 1849 (Section 5.3.3), nodes MUST increase the timer for new items and on 1850 the refresh of existing ones. A suitable value is 1851 2 * (number of routing states) / (rate limit in pkts/second) 1853 which leaves a factor of two headroom for new routing state creation 1854 and Query retransmissions. 1856 The Querying node MUST ensure that a Query is received before this 1857 timer expires, if it believes that the signalling session is still 1858 active; otherwise, the Responding node MAY delete the state. Receipt 1859 of the message at the Responding node will refresh peer addressing 1860 state for one direction, and receipt of a Response at the querying 1861 node will refresh it for the other. There is no mechanism at the 1862 GIST level for explicit teardown of routing state. However, GIST 1863 MUST NOT refresh routing state if a signalling session is known to be 1864 inactive, either because upstream state has expired, or because the 1865 signalling application has indicated via the GIST API (Appendix B.5) 1866 that the state is no longer required, because this would prevent 1867 correct state repair in the case of network rerouting at the IP 1868 layer. 1870 This specification defines precisely only the time at which routing 1871 state expires; it does not define when refresh handshakes should be 1872 initiated. Implementations MUST select timer settings which take at 1873 least the following into account: 1875 o The transmission latency between source and destination; 1877 o The need for retransmissions of Query messages; 1879 o The need to avoid network synchronisation of control traffic (cf. 1880 [39]). 1882 In most cases, a reasonable policy is to initiate the routing state 1883 refresh when between 1/2 and 3/4 of the validity time has elapsed 1884 since the last successful refresh. The actual moment MUST be chosen 1885 randomly within this interval to avoid synchronisation effects. 1887 4.4.5. Messaging Association Maintenance 1889 Unneeded MAs are torn down by GIST, using the teardown mechanisms of 1890 the underlying transport or security protocols if available, for 1891 example by simply closing a TCP connection. The teardown can be 1892 initiated by either end. Whether an MA is needed is a combination of 1893 two factors: 1895 o local policy, which could take into account the cost of keeping 1896 the messaging association open, the level of past activity on the 1897 association, and the likelihood of future activity, e.g. if there 1898 is routing state still in place which might generate messages to 1899 use it. 1901 o whether the peer still wants the MA to remain in place. During MA 1902 setup, as part of the Stack-Configuration-Data, each node 1903 advertises its own MA-Hold-Time, which is the time for which it 1904 will retain an MA which is not carrying signalling traffic. A 1905 node MUST NOT tear down an MA if it has received traffic from its 1906 peer over that period. A peer which has generated no traffic but 1907 still wants the MA retained can use a special null message (MA- 1908 Hello) to indicate the fact. A default value for MA-Hold-Time of 1909 30 seconds is RECOMMENDED. Nodes MAY use shorter times to achieve 1910 more rapid peer failure detection, but need to take into account 1911 the load on the network created by the MA-Hello messages. Nodes 1912 MAY use longer times, but need to take into account the cost of 1913 retaining idle MAs for extended periods. Nodes MAY take 1914 signalling application behaviour (e.g. NSLP refresh times) into 1915 account in choosing an appropriate value. 1917 Because the Responding node can choose not to create state until a 1918 Confirm, an abbreviated Stack-Configuration-Data object containing 1919 just this information from the initial Query MUST be repeated by 1920 the Querying node in the first Confirm sent on a new MA. If the 1921 object is missing in the Confirm, an "Object Type Error" message 1922 (Appendix A.4.4.9) with subcode 2 ("Missing Object") MUST be 1923 returned. 1925 Messaging associations can always be set up on demand, and messaging 1926 association status is not made directly visible outside the GIST 1927 layer. Therefore, even if GIST tears down and later re-establishes a 1928 messaging association, signalling applications cannot distinguish 1929 this from the case where the MA is kept permanently open. To 1930 maintain the transport semantics described in Section 4.1, GIST MUST 1931 close transport connections carrying reliable messages gracefully or 1932 report an error condition, and MUST NOT open a new association to be 1933 used for given session and peer while messages on a previous 1934 association could still be outstanding. GIST MAY use an MA-Hello 1935 request/reply exchange on an existing association to verify that 1936 messages sent on it have reached the peer. GIST MAY use the same 1937 technique to test the liveness of the underlying MA protocols 1938 themselves at arbitrary times. 1940 This specification defines precisely only the time at which messaging 1941 associations expires; it does not define when keepalives should be 1942 initiated. Implementations MUST select timer settings which take at 1943 least the following into account: 1945 o The transmission latency between source and destination; 1947 o The need for retransmissions within the messaging association 1948 protocols; 1950 o The need to avoid network synchronisation of control traffic (cf. 1951 [39]). 1953 In most cases, a reasonable policy is to initiate the MA refresh when 1954 between 1/2 and 3/4 of the validity time has elapsed since the last 1955 successful refresh. The actual moment MUST be chosen randomly within 1956 this interval to avoid synchronisation effects. 1958 4.4.6. Routing State Failures 1960 A GIST node can receive a message from a GIST peer, which can only be 1961 correctly processed in the context of some routing state, but where 1962 no corresponding routing state exists. Cases where this can arise 1963 include: 1965 o Where the message is random traffic from an attacker, or 1966 backscatter (replies to such traffic). 1968 o Where routing state has been correctly installed but the peer has 1969 since lost it, for example because of aggressive timeout settings 1970 at the peer, or because the node has crashed and restarted. 1972 o Where the routing state has never been correctly installed in the 1973 first place, but the sending node does not know this. This can 1974 happen if the Confirm message of the handshake is lost. 1976 It is important for GIST to recover from such situations promptly 1977 where they represent genuine errors (node restarts, or lost messages 1978 which would not otherwise be retransmitted). Note that only 1979 Response, Confirm, Error and Data messages ever require routing state 1980 to exist, and these are considered in turn: 1982 Response: A Response can be received at a node which never sent (or 1983 has forgotten) the corresponding Query. If the node wants routing 1984 state to exist, it will initiate it itself; a diagnostic error 1985 would not allow the sender of the Response to take any corrective 1986 action, and the diagnostic could itself be a form of backscatter. 1987 Therefore, an error message MUST NOT be generated, but the 1988 condition MAY be logged locally. 1990 Confirm: For a Responding node which implements delayed state 1991 installation, this is normal behaviour, and routing state will be 1992 created provided the Confirm is validated. Otherwise, this is a 1993 case of a non-existent or forgotten Response, and the node may not 1994 have sufficient information in the Confirm to create the correct 1995 state. The requirement is to notify the Querying node so that it 1996 can recover the routing state. 1998 Data: This arises when a node receives Data where routing state is 1999 required, but either it does not exist at all, or it has not been 2000 finalised (no Confirm message). To avoid Data being black-holed, 2001 a notification must be sent to the peer. 2003 Error: Some error messages can only be interpreted in the context of 2004 routing state. However, the only error messages which require a 2005 reply within the protocol are routing state error messages 2006 themselves. Therefore, this case should be treated the same as a 2007 Response: an error message MUST NOT be generated, but the 2008 condition MAY be logged locally. 2010 For the case of Confirm or Data messages, if the state is required 2011 but does not exist, the node MUST reject the incoming message with a 2012 "No Routing State" error message (Appendix A.4.4.5). There are then 2013 three cases at the receiver of the error message: 2015 No routing state: The condition MAY be logged but a reply MUST NOT 2016 be sent (see above). 2018 Querying node: The node MUST restart the GIST handshake from the 2019 beginning, with a new Query. 2021 Responding node: The node MUST delete its own routing state and 2022 SHOULD report an error condition to the local signalling 2023 application. 2025 The rules at the Querying or Responding node make GIST open to 2026 disruption by randomly injected error messages, similar to blind 2027 reset attacks on TCP (cf. [43]), although because routing state 2028 matching includes the SID this is mainly limited to on-path 2029 attackers. If a GIST node detects a significant rate of such 2030 attacks, it MAY adopt a policy of using secured messaging 2031 associations to communicate for the affected MRIs, and only accepting 2032 "No Routing State" error messages over such associations. 2034 5. Message Formats and Transport 2036 5.1. GIST Messages 2038 All GIST messages begin with a common header, followed by a sequence 2039 of type-length-value (TLV) objects. This subsection describes the 2040 various GIST messages and their contents at a high level in ABNF 2041 [12]; a more detailed description of the header and each object is 2042 given in Section 5.2 and bit formats in Appendix A. Note that the 2043 NAT traversal mechanism for GIST involves the insertion of an 2044 additional NAT-Traversal-Object in Query, Response, and some Data and 2045 Error messages; the rules for this are given in Section 7.2. 2047 GIST-Message: The primary messages are either part of the three-way 2048 handshake, or a simple message carrying NSLP data. Additional types 2049 are defined for errors and keeping messaging associations alive. 2050 GIST-Message = Query / Response / Confirm / 2051 Data / Error / MA-Hello 2053 The common header includes a version number, message type and size, 2054 and NSLPID. It also carries a hop count to prevent infinite message 2055 looping and various control flags, including one (the R flag) to 2056 indicate if a reply of some sort is requested. The objects following 2057 the common header MUST be carried in a fixed order, depending on 2058 message type. Messages with missing, duplicate or invalid objects 2059 for the message type MUST be rejected with an "Object Type Error" 2060 message with the appropriate subcode (Appendix A.4.4.9). 2062 Query: A Query MUST be sent in D-mode using the special Q-mode 2063 encapsulation. In addition to the common header, it contains certain 2064 mandatory control objects, and MAY contain a signalling application 2065 payload. A stack proposal and configuration data MUST be included if 2066 the message exchange relates to setup of a messaging association. 2067 The R flag MUST always be set (R=1) in a Query, since this message 2068 always elicits a Response. 2069 Query = Common-Header 2070 [ NAT-Traversal-Object ] 2071 Message-Routing-Information 2072 Session-Identification 2073 Network-Layer-Information 2074 Query-Cookie 2075 [ Stack-Proposal Stack-Configuration-Data ] 2076 [ NSLP-Data ] 2078 Response: A Response MAY be sent in D-mode, or MAY be sent in C-mode 2079 if an existing messaging association is being re-used. It MUST echo 2080 the MRI, SID and Query-Cookie of the Query, and carries its own 2081 Network-Layer-Information. If the message exchange relates to setup 2082 of a new messaging association, which MUST involve a D-mode Response, 2083 a Responder cookie MUST be included, as well as the Responder's own 2084 stack proposal and configuration data. The R flag MUST be set (R=1) 2085 if a Responder cookie is present but otherwise is optional; if the R 2086 flag is set, a Confirm MUST be sent as a reply. Therefore, in 2087 particular, a Confirm will always be required if a new MA is being 2088 set up. Note that the direction of this MRI will be inverted 2089 compared to that in the Query, that is, an upstream MRI becomes 2090 downstream and vice versa (see Section 3.3). 2091 Response = Common-Header 2092 [ NAT-Traversal-Object ] 2093 Message-Routing-Information 2094 Session-Identification 2095 Network-Layer-Information 2096 Query-Cookie 2097 [ Responder-Cookie 2098 [ Stack-Proposal Stack-Configuration-Data ] ] 2099 [ NSLP-Data ] 2101 Confirm: A Confirm MUST be sent in C-mode if a messaging association 2102 is being used for this routing state, and MUST be sent before other 2103 messages for this routing state. If no messaging association is 2104 being used, the Confirm MUST be sent in D-mode. The Confirm MUST 2105 include the MRI (with inverted direction) and SID, and echo the 2106 Responder-Cookie if the Response carried one. In C-mode, the Confirm 2107 MUST also echo the Stack-Proposal from the Response (if present) so 2108 it can be verified that this has not been tampered with. The first 2109 Confirm on a new association MUST also repeat the Stack- 2110 Configuration-Data from the original Query in an abbreviated form, 2111 just containing the MA-Hold-Time. 2112 Confirm = Common-Header 2113 Message-Routing-Information 2114 Session-Identification 2115 Network-Layer-Information 2116 [ Responder-Cookie 2117 [ Stack-Proposal 2118 [ Stack-Configuration-Data ] ] ] 2119 [ NSLP-Data ] 2121 Data: The Data message is used to transport NSLP data without 2122 modifying GIST state. It contains no control objects, but only the 2123 MRI and SID associated with the NSLP data being transferred. 2124 Network-Layer-Information (NLI) MUST be carried in the D-mode case, 2125 but MUST NOT be included otherwise. 2127 Data = Common-Header 2128 [ NAT-Traversal-Object ] 2129 Message-Routing-Information 2130 Session-Identification 2131 [ Network-Layer-Information ] 2132 NSLP-Data 2134 Error: An Error message reports a problem determined at the GIST 2135 level. (Errors generated by signalling applications are reported in 2136 NSLP-Data payloads and are not treated specially by GIST.) If the 2137 message is being sent in D-mode, the originator of the error message 2138 MUST include its own Network-Layer-Information object. All other 2139 information related to the error is carried in a GIST-Error-Data 2140 object. 2141 Error = Common-Header 2142 [ NAT-Traversal-Object ] 2143 [ Network-Layer-Information ] 2144 GIST-Error-Data 2146 MA-Hello: This message MUST be sent only in C-mode. It contains the 2147 common header, with a NSLPID of zero, and a message identifier, the 2148 Hello-ID. It always indicates that a node wishes to keep a messaging 2149 association open, and if sent with R=0 and zero Hello-ID this is its 2150 only function. A node MAY also invoke a diagnostic request/reply 2151 exchange by setting R=1 and providing a non-zero Hello-ID; if this 2152 case, the peer MUST send another MA-Hello back along the messaging 2153 association echoing the same Hello-ID and with R=0. Use of this 2154 diagnostic is entirely at the discretion of the initiating node. 2155 MA-Hello = Common-Header 2156 Hello-ID 2158 5.2. Information Elements 2160 This section describes the content of the various objects that can be 2161 present in each GIST message, both the common header, and the 2162 individual TLVs. The bit formats are provided in Appendix A. 2164 5.2.1. The Common Header 2166 Each message begins with a fixed format common header, which contains 2167 the following information: 2169 Version: The version number of the GIST protocol. This 2170 specification defines GIST version 1. 2172 GIST hop count: A hop count to prevent a message from looping 2173 indefinitely. 2175 Length: The number of 32 bit words in the message following the 2176 common header. 2178 Upper layer identifier (NSLPID): This gives the specific NSLP that 2179 this message is used for. 2181 Message type: The message type (Query, Response, etc.) 2183 Source addressing mode: If set (S=1), this indicates that the IP 2184 source address of the message is the same as the IP address of the 2185 signalling peer, so replies to this message can be sent safely to 2186 this address. S is always set in C-mode. It is cleared (S=0) if 2187 the IP source address was derived from the message routing 2188 information in the payload and this is different from the 2189 signalling source address. 2191 Response requested: A flag which if set (R=1) indicates that a GIST 2192 message should be sent in reply to this message. The appropriate 2193 message type for the reply depends on the type of the initial 2194 message. 2196 Explicit routing: A flag which if set (E=1) indicates that the 2197 message was explicitly routed (see Section 7.1.5). 2199 Note that in D-mode, Section 5.3, there is a 32-bit magic number 2200 before the header. However, this is regarded as part of the 2201 encapsulation rather than part of the message itself. 2203 5.2.2. TLV Objects 2205 All data following the common header is encoded as a sequence of 2206 type-length-value objects. Currently, each object can occur at most 2207 once; the set of required and permitted objects is determined by the 2208 message type and encapsulation (D-mode or C-mode). 2210 Message-Routing-Information (MRI): Information sufficient to define 2211 how the signalling message should be routed through the network. 2213 Message-Routing-Information = message-routing-method 2214 method-specific-information 2216 The format of the method-specific-information depends on the 2217 message-routing-method requested by the signalling application. 2218 Note that it always includes a flag defining the direction as 2219 either 'upstream' or 'downstream' (see Section 3.3). It is 2220 provided by the NSLP in the message sender and used by GIST to 2221 select the message routing. 2223 Session-Identification (SID): The GIST session identifier is a 128 2224 bit, cryptographically random identifier chosen by the node which 2225 originates the signalling exchange. See Section 3.7. 2227 Network-Layer-Information (NLI): This object carries information 2228 about the network layer attributes of the node sending the 2229 message, including data related to the management of routing 2230 state. This includes a peer identity and IP address for the 2231 sending node. It also includes IP-TTL information to allow the IP 2232 hop count between GIST peers to be measured and reported, and a 2233 validity time (RS-validity-time) for the routing state. 2235 Network-Layer-Information = peer-identity 2236 interface-address 2237 RS-validity-time 2238 IP-TTL 2240 The use of the RS-validity-time field is described in 2241 Section 4.4.4. The peer-identity and interface-address are used 2242 for matching existing associations, as discussed in Section 4.4.3. 2244 The interface-address must be routable, i.e. it MUST be usable as 2245 a destination IP address for packets to be sent back to the node 2246 generating the signalling message, whether in D-mode or C-mode. 2247 If this object is carried in a message with the source addressing 2248 mode flag S=1, the interface-address MUST match the source address 2249 used in the IP encapsulation, to assist in legacy NAT detection 2250 (Section 7.2.1). If this object is carried in a Query or Confirm, 2251 the interface-address MUST specifically be set to an address bound 2252 to an interface associated with the MRI, to allow its use in route 2253 change handling as discussed in Section 7.1. A suitable choice is 2254 the interface that is carrying the outbound flow. A node may have 2255 several choices for which of its addresses to use as the 2256 interface-address. For example, there may be a choice of IP 2257 versions, or addresses of limited scope (e.g. link-local), or 2258 addresses bound to different interfaces in the case of a router or 2259 multi-homed host. However, some of these interface addresses may 2260 not be usable by the peer. A node MUST follow a policy of using a 2261 global address of the same IP version as in the MRI, unless it can 2262 establish that an alternative address would also be usable. 2264 The setting and interpretation of the IP-TTL field depends on the 2265 message direction (upstream/downstream as determined from the MRI 2266 as described above) and encapsulation. 2268 * If the message is sent downstream, if the TTL that will be set 2269 in the IP header for the message can be determined, the IP-TTL 2270 value MUST be set to this value, or else set to 0. 2272 * On receiving a downstream message in D-mode, a non-zero IP-TTL 2273 is compared to the TTL in the IP header, and the difference is 2274 stored as the IP-hop-count-to-peer for the upstream peer in the 2275 routing state table for that flow. Otherwise, the field is 2276 ignored. 2278 * If the message is sent upstream, the IP-TTL MUST be set to the 2279 value of the IP-hop-count-to-peer stored in the routing state 2280 table, or 0 if there is no value yet stored. 2282 * On receiving an upstream message, the IP-TTL is stored as the 2283 IP-hop-count-to-peer for the downstream peer. 2285 In all cases, the IP-TTL value reported to signalling applications 2286 is the one stored with the routing state for that flow, after it 2287 has been updated if necessary from processing the message in 2288 question. 2290 Stack-Proposal: This field contains information about which 2291 combinations of transport and security protocols are available for 2292 use in messaging associations, and is also discussed further in 2293 Section 5.7. 2295 Stack-Proposal = 1*stack-profile 2297 stack-profile = 1*protocol-layer 2299 Each protocol-layer field identifies a protocol with a unique tag; 2300 any additional data, such as higher-layer addressing or other 2301 options data associated with the protocol, will be carried in a 2302 MA-protocol-options field in the Stack-Configuration-Data TLV (see 2303 below). 2305 Stack-Configuration-Data (SCD): This object carries information 2306 about the overall configuration of a messaging association. 2308 Stack-Configuration-Data = MA-Hold-Time 2309 0*MA-protocol-options 2311 The MA-Hold-Time field indicates how long a node will hold open an 2312 inactive association; see Section 4.4.5 for more discussion. The 2313 MA-protocol-options fields give the configuration of the protocols 2314 (e.g. TCP, TLS) to be used for new messaging associations, and 2315 they are described in more detail in Section 5.7. 2317 Query-Cookie/Responder-Cookie: A Query-Cookie is contained in a 2318 Query and MUST be echoed in a Response; a Responder-Cookie MAY be 2319 sent in a Response, and if present MUST be echoed in the following 2320 Confirm. Cookies are variable length bit strings, chosen by the 2321 cookie generator. See Section 8.5 for further details on 2322 requirements and mechanisms for cookie generation. 2324 Hello-ID: The Hello-ID is a 32-bit quantity that is used to 2325 correlate messages in an MA-Hello request/reply exchange. A non- 2326 zero value MUST be used in a request (messages sent with R=1) and 2327 the same value must be returned in the reply (which has R=0). The 2328 value zero MUST be used for all other messages; if a message is 2329 received with R=1 and Hello-ID=0, an "Object Value Error" message 2330 (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") MUST be 2331 returned and the message dropped. Nodes MAY use any algorithm to 2332 generate the Hello-ID; a suitable approach is a local sequence 2333 number with a random starting point. 2335 NSLP-Data: The NSLP payload to be delivered to the signalling 2336 application. GIST does not interpret the payload content. 2338 GIST-Error-Data: This contains the information to report the cause 2339 and context of an error. 2341 GIST-Error-Data = error-class error-code error-subcode 2342 common-error-header 2343 [ Message-Routing-Information-content ] 2344 [ Session-Identification-content ] 2345 0*additional-information 2346 [ comment ] 2348 The error-class indicates the severity level, and the error-code 2349 and error-subcode identify the specific error itself. A full list 2350 of GIST errors and their severity levels is given in Appendix A.4. 2351 The common-error-header carries the Common-Header from the 2352 original message, and contents of the Message-Routing-Information 2353 (MRI) and Session-Identification (SID) objects are also included 2354 if they were successfully decoded. For some errors, additional 2355 information fields can be included, and these fields themselves 2356 have a simple TLV format. Finally, an optional free-text comment 2357 may be added. 2359 5.3. D-mode Transport 2361 This section describes the various encapsulation options for D-mode 2362 messages. Although there are several possibilities, depending on 2363 message type, MRM, and local policy, the general design principle is 2364 that the sole purpose of the encapsulation is to ensure that the 2365 message is delivered to or intercepted at the correct peer. Beyond 2366 that, minimal significance is attached to the type of encapsulation 2367 or the values of addresses or ports used for it. This allows new 2368 options to be developed in the future to handle particular deployment 2369 requirements without modifying the overall protocol specification. 2371 5.3.1. Normal Encapsulation 2373 Normal encapsulation MUST be used for all D-mode messages where the 2374 signalling peer is already known from previous signalling. This 2375 includes Response and Confirm messages, and Data messages except if 2376 these are being sent without using local routing state. Normal 2377 encapsulation is simple: the message is carried in a single UDP 2378 datagram. UDP checksums MUST be enabled. The UDP payload MUST 2379 always begin with a 32 bit magic number with value 0x4e04 bda5 in 2380 network byte order; this is followed by the GIST common header and 2381 the complete set of payloads. If the magic number is not present, 2382 the message MUST be silently dropped. The normal encapsulation is 2383 shown in outline in Figure 6. 2385 0 1 2 3 2386 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 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 // IP Header // 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 // UDP Header // 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | GIST Magic Number (0x4e04bda5) | 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 // GIST Common Header // 2395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2396 // GIST Payloads // 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 Figure 6: Normal Encapsulation Packet Format 2401 The message is IP addressed directly to the adjacent peer as given by 2402 the routing state table. Where the message is a direct reply to a 2403 Query and no routing state exists, the destination address is derived 2404 from the input message using the same rules as in Section 4.4.1. The 2405 UDP port numbering MUST be compatible with that used on Query 2406 messages (see below), that is, the same for messages in the same 2407 direction and with source and destination port numbers swapped for 2408 messages in the opposite direction. Normally encapsulated messages 2409 MUST be sent with source addressing mode flag S=1 unless the message 2410 is a reply to a message which is known to have passed through a NAT, 2411 and the receiver MUST check the IP source address with the interface- 2412 address given in the NLI as part of legacy NAT detection. Both these 2413 aspects of message processing are discussed further in Section 7.2.1. 2415 5.3.2. Q-mode Encapsulation 2417 Q-mode encapsulation MUST be used for messages where no routing state 2418 is available or where the routing state is being refreshed, in 2419 particular for Query messages. Q-mode can also be used when 2420 requested by local policy. Q-mode encapsulation is similar to normal 2421 encapsulation, with changes in IP address selection, IP options, and 2422 a defined method for selecting UDP ports. 2424 5.3.2.1. Encapsulation and Interception in IPv4 2426 In general, the IP addresses are derived from information in the MRI; 2427 the exact rules depend on the MRM. For the case of messages with 2428 source addressing mode flag S=1, the receiver MUST check the IP 2429 source address with the interface-address given in the NLI as part of 2430 legacy NAT detection, see Section 7.2.1. 2432 Current MRMs define the use of a Router Alert Option [3] to assist 2433 the peer in intercepting the message depending on the NSLPID. If the 2434 MRM defines the use of RAO, the sender MUST include it unless it has 2435 been specifically configured not to (see below). A node MAY make the 2436 initial interception decision based purely on IP-Protocol number 2437 transport header analysis. Implementations MAY provide an option to 2438 disable the setting of RAO on Q-mode packets on a per-destination 2439 prefix basis; however, the option MUST be disabled by default and 2440 MUST only be enabled when it has been separately verified that the 2441 the next GIST node along the path to the destination is capable of 2442 intercepting packets without RAO. The purpose of this option is to 2443 allow operation across networks which do not properly support RAO; 2444 further details are discussed in Appendix C. 2446 It is possible that fragmented datagrams including an RAO will not be 2447 correctly handled in the network; furthermore, some of the checks 2448 that a datagram is a Q-mode packet depend on data beyond the IP 2449 header. Therefore the sender MUST set the Don't Fragment (DF) bit in 2450 the IPv4 header. Note that ICMP "packet too large" messages will be 2451 sent to the source address of the original IP datagram, and since all 2452 MRM definitions recommend S=1 for at least some retransmissions, ICMP 2453 errors related to fragmentation will be seen at the Querying node. 2455 The upper layer protocol, identified by the IP-Protocol field in the 2456 IP header, MUST be UDP. 2458 5.3.2.2. Encapsulation and Interception in IPv6 2460 As for IPv4, the IP addresses are derived from information in the 2461 MRI; the exact rules depend on the MRM. For the case of messages 2462 with source addressing mode flag S=1, the receiver MUST check the IP 2463 source address with the interface-address given in the NLI as part of 2464 legacy NAT detection, see Section 7.2.1. 2466 For all current MRMs, the IP header is given a Router Alert Option 2467 [8] to assist the peer in intercepting the message depending on the 2468 NSLPID. If the MRM defines the use of RAO, the sender MUST include 2469 it without exception. It is RECOMMENDED that a node bases its 2470 initial interception decision purely on the presence of a hop-by-hop 2471 option header containing the RAO, which will be at the start of the 2472 header chain. 2474 The upper layer protocol MUST be UDP without intervening 2475 encapsulation layers. Following the hop-by-hop option header, the IP 2476 header MUST NOT include any extension headers other than routing 2477 options or destination options, and for the last extension header 2478 MUST have a next-header field of UDP. 2480 5.3.2.3. Upper Layer Encapsulation and Overall Interception 2481 Requirements 2483 For both IP versions, the above rules require that the upper layer 2484 protocol identified by the IP header MUST be UDP. Other packets MUST 2485 NOT be identified as GIST Q-mode packets; this includes IP-in-IP 2486 tunnelled packets, other tunnelled packets (tunnel mode AH/ESP), or 2487 packets which have undergone some additional transport layer 2488 processing (transport mode AH/ESP). If IP output processing at the 2489 originating node or an intermediate router causes such additional 2490 encapsulations to be added to a GIST Q-mode packet, this packet will 2491 not be identified as GIST until the encapsulation is terminated. If 2492 the node wishes to signal for data over the network region where the 2493 encapsulation applies, it MUST generate additional signalling with an 2494 MRI matching the encapsulated traffic, and the outbound GIST Q-mode 2495 messages for it MUST bypass the encapsulation processing. 2497 Therefore, the final stage of the interception process and the final 2498 part of encapsulation is at the UDP level. The source UDP port is 2499 selected by the message sender as the port at which it is prepared to 2500 receive UDP messages in reply, and the sender MUST use the 2501 destination UDP port allocated for GIST by IANA (see Section 9). 2502 Note that for some MRMs, GIST nodes anywhere along the path can 2503 generate GIST packets with source addresses that spoof the source 2504 address of the data flow. Therefore, destinations cannot distinguish 2505 these packets from genuine end-to-end data purely on address 2506 analysis. Instead, it must be possible to distinguish such GIST 2507 packets by port analysis; furthermore, the mechanism to do so must 2508 remain valid even if the destination is GIST-unaware. GIST solves 2509 this problem by using a fixed destination UDP port from the "well 2510 known" space for the Q-mode encapsulation. This port should never be 2511 allocated on a GIST-unaware host, and therefore Q-mode encapsulated 2512 messages should always be rejected with an ICMP error. 2514 Within the network, there may be packets using the GIST UDP port but 2515 which are not in fact GIST traffic. Q-mode packets carry the same 2516 magic number as other D-mode packets (see Section 5.3.1). A Q-mode 2517 packet intercepted within the network which does not match both the 2518 UDP destination port and the magic number MUST be forwarded 2519 transparently at the IP layer, regardless of any RAO value it 2520 contains. Regardless of the IP level encapsulation, if either the 2521 destination port is not the GIST port, or the payload start does not 2522 match the magic number, the packet MUST NOT be identified as a GIST 2523 Q-mode packet and MUST be processed as a normal IP datagram. If a 2524 Q-mode packet is received at an end system (i.e. the at the 2525 destination address of the IP datagram), if it does not start with 2526 the correct magic number it MUST be silently dropped as in the D-mode 2527 case. 2529 5.3.2.4. IP Option Processing 2531 For both IPv4 and IPv6, for Q-mode packets with IP options allowed by 2532 the above requirements, IP options processing is intended to be 2533 carried out independently of GIST processing. Note that for the 2534 options allowed by the above rules, the option semantics are 2535 independent of the payload: UDP payload modifications are not 2536 prevented by the options and do not affect the option content, and 2537 conversely the presence of the options does not affect the UDP 2538 payload. 2540 On packets originated by GIST, IP options MAY be added according to 2541 node-local policies on outgoing IP data. On packets forwarded by 2542 GIST without NSLP processing, IP options MUST be processed as for a 2543 normally forwarded IP packet. On packets locally delivered to the 2544 NSLP, the IP options MAY be passed to the NSLP and equivalent options 2545 used on subsequently generated outgoing Q-mode packets. In this 2546 case, routing related options SHOULD be processed identically as they 2547 would be for a normally forwarded IP packet. 2549 5.3.3. Retransmission and Rate Control 2551 D-mode uses UDP, and hence has no automatic reliability or congestion 2552 control capabilities. Signalling applications requiring reliability 2553 should be serviced using C-mode, which should also carry the bulk of 2554 signalling traffic. However, some form of messaging reliability is 2555 required for the GIST control messages themselves, as is rate control 2556 to handle retransmissions and also bursts of unreliable signalling or 2557 state setup requests from the signalling applications. 2559 Query messages which do not receive Responses MAY be retransmitted; 2560 retransmissions MUST use a binary exponential backoff. The initial 2561 timer value is T1, which the backoff process can increase up to a 2562 maximum value of T2 seconds. The default value for T1 is 500 ms. T1 2563 is an estimate of the round-trip time between the querying and 2564 responding nodes. Nodes MAY use smaller values of T1 if it is known 2565 that the Query should be answered within the local network. T1 MAY 2566 be chosen larger, and this is RECOMMENDED if it is known in advance 2567 (such as on high latency access links) that the round-trip time is 2568 larger. The default value of T2 is 64*T1. Note that Queries may go 2569 unanswered either because of message loss (in either direction), or 2570 because there is no reachable GIST peer. Therefore, implementations 2571 MAY trade off reliability (large T2) against promptness of error 2572 feedback to applications (small T2). If the NSLP has indicated a 2573 timeout on the validity of this payload (see Appendix B.1), T2 MUST 2574 be chosen so that the process terminates within this timeout. 2575 Retransmitted Queries MUST use different Query-Cookie values. If the 2576 Query carries NSLP data, it may be delivered multiple times to the 2577 signalling application. These rules apply equally to the message 2578 that first creates routing state, and those that refresh it. In all 2579 cases, Responses MUST be sent promptly to avoid spurious 2580 retransmissions. Nodes generating any type of retransmission MUST be 2581 prepared to receive and match a reply to any of them, not just the 2582 one most recently sent. Although a node SHOULD terminate its 2583 retransmission process when any reply is received, it MUST continue 2584 to process further replies as normal. 2586 This algorithm is sufficient to handle lost Queries and Responses. 2587 The case of a lost Confirm is more subtle. The Responding node MAY 2588 run a retransmission timer to resend the Response until a Confirm is 2589 received; the timer MUST use the same backoff mechanism and 2590 parameters as for Responses. The problem of an amplification attack 2591 stimulated by a malicious Query is handled by requiring the cookie 2592 mechanism to enable the node receiving the Response to discard it 2593 efficiently if it does not match a previously sent Query. This 2594 approach is only appropriate if the Responding node is prepared to 2595 store per-flow state after receiving a single (Query) message, which 2596 includes the case where the node has queued NSLP data. If the 2597 Responding node has delayed state installation, the error condition 2598 will only be detected when a Data message arrives. This is handled 2599 as a routing state error (see Section 4.4.6) which causes the 2600 Querying node to restart the handshake. 2602 The basic rate-control requirements for D-mode traffic are 2603 deliberately minimal. A single rate limiter applies to all traffic, 2604 for all interfaces and message types. It applies to retransmissions 2605 as well as new messages, although an implementation MAY choose to 2606 prioritise one over the other. Rate-control applies only to locally 2607 generated D-mode messages, not to messages which are being forwarded. 2608 When the rate limiter is in effect, D-mode messages MUST be queued 2609 until transmission is re-enabled, or they MAY be dropped with an 2610 error condition indicated back to local signalling applications. In 2611 either case, the effect of this will be to reduce the rate at which 2612 new transactions can be initiated by signalling applications, thereby 2613 reducing the load on the network. 2615 The rate limiting mechanism is implementation-defined, but it is 2616 RECOMMENDED that a token bucket limiter as described in [33] be used. 2617 The token bucket MUST be sized to ensure that a node cannot saturate 2618 the network with D-mode traffic, for example when re-probing the 2619 network for multiple flows after a route change. A suitable approach 2620 is to restrict the token bucket parameters so that the mean output 2621 rate is a small fraction, such as 5%, of the node's lowest-speed 2622 interface. Note that, according to the rules of Section 4.3.3, in 2623 general D-mode SHOULD only be used for Queries and Responses rather 2624 than normal signalling traffic unless capacity for normal signalling 2625 traffic can be engineered. 2627 5.4. C-mode Transport 2629 It is a requirement of the NTLP defined in [29] that it should be 2630 able to support bundling of small messages, fragmentation of large 2631 messages, and message boundary delineation. TCP provides both 2632 bundling and fragmentation, but not message boundaries. However, the 2633 length information in the GIST common header allows the message 2634 boundary to be discovered during parsing. The bundling together of 2635 small messages can either be done within the transport protocol or 2636 can be carried out by GIST during message construction. Either way, 2637 two approaches can be distinguished: 2639 1. As messages arrive for transmission they are gathered into a 2640 bundle until a size limit is reached or a timeout expires (cf. 2641 the Nagle algorithm of TCP). This provides maximal efficiency at 2642 the cost of some latency. 2644 2. Messages awaiting transmission are gathered together while the 2645 node is not allowed to send them, for example because it is 2646 congestion controlled. 2648 The second type of bundling is always appropriate. For GIST, the 2649 first type MUST NOT be used for trigger messages (i.e. messages that 2650 update GIST or signalling application state), but may be appropriate 2651 for refresh messages (i.e. messages that just extend timers). These 2652 distinctions are known only to the signalling applications, but MAY 2653 be indicated (as an implementation issue) by setting the priority 2654 transfer attribute (Section 4.1.2). 2656 It can be seen that all of these transport protocol options can be 2657 supported by the basic GIST message format already presented. The 2658 GIST message, consisting of common header and TLVs, is carried 2659 directly in the transport protocol, possibly incorporating transport 2660 layer security protection. Further messages can be carried in a 2661 continuous stream. This specification defines only the use of TCP, 2662 but other possibilities could be included without additional work on 2663 message formatting. 2665 5.5. Message Type/Encapsulation Relationships 2667 GIST has four primary message types (Query, Response, Confirm, and 2668 Data) and three possible encapsulation methods (normal D-mode, 2669 Q-mode, and C-mode). The combinations of message type and 2670 encapsulation which are allowed for message transmission are given in 2671 the table below. In some cases there are several possible choices, 2672 depending on the existence of routing state or messaging 2673 associations. The rules governing GIST policy, including whether or 2674 not to create such state to handle a message, are described 2675 normatively in the other sections of this specification. If a 2676 message which can only be sent in Q/D-mode arrives in C-mode or vice 2677 versa, this MUST be rejected with an "Incorrect Encapsulation" error 2678 message (Appendix A.4.4.3). However, it should be noted that the 2679 processing of the message at the receiver is not otherwise affected 2680 by the encapsulation method used, except that the decapsulation 2681 process may provide additional information, such as translated 2682 addresses or IP hop count to be used in the subsequent message 2683 processing. 2685 +----------+---------------+-------------------------+--------------+ 2686 | Message | Normal D-mode | Query D-mode (Q-mode) | C-mode | 2687 +----------+---------------+-------------------------+--------------+ 2688 | Query | Never | Always | Never | 2689 | | | | | 2690 | Response | Unless a | Never | If a | 2691 | | messaging | | messaging | 2692 | | association | | association | 2693 | | is being | | is being | 2694 | | re-used | | re-used | 2695 | | | | | 2696 | Confirm | Only if no | Never | If a | 2697 | | messaging | | messaging | 2698 | | association | | association | 2699 | | has been set | | has been set | 2700 | | up or is | | up or is | 2701 | | being re-used | | being | 2702 | | | | re-used | 2703 | | | | | 2704 | Data | If routing | If the MRI can be used | If a | 2705 | | state exists | to derive the Q-mode | messaging | 2706 | | for the flow | encapsulation, and | association | 2707 | | but no | either no routing state | exists | 2708 | | messaging | exists or local policy | | 2709 | | association | requires Q-mode | | 2710 +----------+---------------+-------------------------+--------------+ 2712 5.6. Error Message Processing 2714 Special rules apply to the encapsulation and transmission of error 2715 messages. 2717 GIST only generates error messages in reaction to incoming messages. 2718 Error messages MUST NOT be generated in reaction to incoming error 2719 messages. The routing and encapsulation of the error message is 2720 derived from that of the message that caused the error; in 2721 particular, local routing state is not consulted. Routing state and 2722 messaging association state MUST NOT be created to handle the error, 2723 and error messages MUST NOT be retransmitted explicitly by GIST, 2724 although they are subject to the same rate control as other messages. 2726 o If the incoming message was received in D-mode, the error MUST be 2727 sent in D-mode using the normal encapsulation, using the 2728 addressing information from the NLI object in the incoming 2729 message. If the NLI could not be determined, the error MUST be 2730 sent to the IP source of the incoming message if the S flag was 2731 set in it. The NLI object in the Error message reports 2732 information about the originator of the error. 2734 o If the incoming message was received over a messaging association, 2735 the error MUST be sent back over the same messaging association. 2737 The NSLPID in the common header of the Error message has the value 2738 zero. If for any reason the message cannot be sent (for example, 2739 because it is too large to send in D-mode, or because the MA over 2740 which the original message arrived has since been closed) an error 2741 SHOULD be logged locally. The receiver of the Error message can 2742 infer the NSLPID for the message that caused the error from the 2743 Common Header that is embedded in the Error object. 2745 5.7. Messaging Association Setup 2747 5.7.1. Overview 2749 A key attribute of GIST is that it is flexible in its ability to use 2750 existing transport and security protocols. Different transport 2751 protocols may have performance attributes appropriate to different 2752 environments; different security protocols may fit appropriately with 2753 different authentication infrastructures. Even given an initial 2754 default mandatory protocol set for GIST, the need to support new 2755 protocols in the future cannot be ruled out, and secure feature 2756 negotiation cannot be added to an existing protocol in a backwards- 2757 compatible way. Therefore, some sort of capability discovery is 2758 required. 2760 Capability discovery is carried out in Query and Response messages, 2761 using Stack-Proposal and Stack-Configuration-Data (SCD) objects. If 2762 a new messaging association is required it is then set up, followed 2763 by a Confirm. Messaging association multiplexing is achieved by 2764 short-circuiting this exchange by sending the Response or Confirm 2765 messages on an existing association (Section 4.4.3); whether to do 2766 this is a matter of local policy. The end result of this process is 2767 a messaging association which is a stack of protocols. If multiple 2768 associations exist, it is a matter of local policy how to distribute 2769 messages over them, subject to respecting the transfer attributes 2770 requested for each message. 2772 Every possible protocol for a messaging association has the following 2773 attributes: 2775 o MA-Protocol-ID, a 1-byte IANA assigned value (see Section 9). 2777 o A specification of the (non-negotiable) policies about how the 2778 protocol should be used; for example, in which direction a 2779 connection should be opened. 2781 o [Depending on the specific protocol:] Formats for an MA-protocol- 2782 options field to carry the protocol addressing and other 2783 configuration information in the SCD object. The format may 2784 differ depending on whether the field is present in the Query or 2785 Response. Some protocols do not require the definition of such 2786 additional data, in which case no corresponding MA-protocol- 2787 options field will occur in the SCD object. 2789 A Stack-Proposal object is simply a list of profiles; each profile is 2790 a sequence of MA-Protocol-IDs. A profile lists the protocols in 'top 2791 to bottom' order (e.g. TLS over TCP). A Stack-Proposal is generally 2792 accompanied by a SCD object which carries an MA-protocol-options 2793 field for any protocol listed in the Stack-Proposal which needs it. 2794 An MA-protocol-options field may apply globally, to all instances of 2795 the protocol in the Stack-Proposal; or it can be tagged as applying 2796 to a specific instance. The latter approach can for example be used 2797 to carry different port numbers for TCP depending on whether it is to 2798 be used with or without TLS. An message flow which shows several of 2799 the features of Stack-Proposal and Stack-Configuration-Data formats 2800 can be found in Appendix D. 2802 An MA-protocol-options field may also be flagged as not usable; for 2803 example, a NAT which could not handle SCTP would set this in an MA- 2804 protocol-options field about SCTP. A protocol flagged this way MUST 2805 NOT be used for a messaging association. If the Stack-Proposal and 2806 SCD are both present but not consistent, for example, if they refer 2807 to different protocols, or an MA-protocol-options field refers to a 2808 non-existent profile, an "Object Value Error" message 2809 (Appendix A.4.4.10) with subcode 5 ("Stack-Proposal - Stack- 2810 Configuration-Data Mismatch") MUST be returned and the message 2811 dropped. 2813 A node generating a SCD object MUST honour the implied protocol 2814 configurations for the period during which a messaging association 2815 might be set up; in particular, it MUST be immediately prepared to 2816 accept incoming datagrams or connections at the protocol/port 2817 combinations advertised. This MAY require the creation of listening 2818 endpoints for the transport and security protocols in question, or a 2819 node MAY keep a pool of such endpoints open for extended periods. 2820 However, the received object contents MUST be retained only for the 2821 duration of the Query/Response exchange and to allow any necessary 2822 association setup to complete. They may become invalid because of 2823 expired bindings at intermediate NATs, or because the advertising 2824 node is using agile ports. Once the setup is complete, or if it is 2825 not necessary, or fails for some reason, the object contents MUST be 2826 discarded. A default time of 30 seconds to keep the contents is 2827 RECOMMENDED. 2829 A Query requesting messaging association setup always contains a 2830 Stack-Proposal and SCD object. The Stack-Proposal MUST only include 2831 protocol configurations that are suitable for the transfer attributes 2832 of the messages that the Querying node wishes to use the messaging 2833 association for. For example, it should not simply include all 2834 configurations that the Querying node is capable of supporting. 2836 The Response always contains a Stack-Proposal and SCD object, unless 2837 multiplexing (where the Responder decides to use an existing 2838 association) occurs. For such a Response, the security protocols 2839 listed in the Stack-Proposal MUST NOT depend on the Query. A node 2840 MAY make different proposals depending on the combination of 2841 interface and NSLPID. If multiplexing does occur, which is indicated 2842 by sending the Response over an existing messaging association, the 2843 following rules apply: 2845 o The re-used messaging association MUST NOT have weaker security 2846 properties than all of the options that would have been offered in 2847 the full Response that would have been sent without re-use. 2849 o The re-used messaging association MUST have equivalent or better 2850 transport and security characteristics as at least one of the 2851 protocol configurations that was offered in the Query. 2853 Once the messaging association is set up, the Querying node repeats 2854 the responder's Stack-Proposal over it in the Confirm. The 2855 responding node MUST verify that this has not been changed as part of 2856 bidding-down attack prevention, as well as verifying the Responder 2857 cookie (Section 8.5). If either check fails, the responding node 2858 MUST NOT NOT create the message routing state (or MUST delete it if 2859 it already exists) and SHOULD log an error condition locally. If 2860 this is the first message on a new MA, the MA MUST be torn down. See 2861 Section 8.6 for further discussion. 2863 5.7.2. Protocol Definition: Forwards-TCP 2865 This MA-Protocol-ID denotes a basic use of TCP between peers. 2866 Support for this protocol is REQUIRED. If this protocol is offered, 2867 MA-protocol-options data MUST also be carried in the SCD object. The 2868 MA-protocol-options field formats are: 2870 o in a Query: no information apart from the field header. 2872 o in a Response: 2 byte port number at which the connection will be 2873 accepted, followed by 2 pad bytes. 2875 The connection is opened in the forwards direction, from the Querying 2876 node towards the responder. The Querying node MAY use any source 2877 address and source port. The destination information MUST be derived 2878 from information in the Response: the address from the interface- 2879 address from the Network-Layer-Information object and the port from 2880 the SCD object as described above. 2882 Associations using Forwards-TCP can carry messages with the transfer 2883 attribute Reliable=True. If an error occurs on the TCP connection 2884 such as a reset, as can be detected for example by a socket exception 2885 condition, GIST MUST report this to NSLPs as discussed in 2886 Section 4.1.2. 2888 5.7.3. Protocol Definition: Transport Layer Security 2890 This MA-Protocol-ID denotes a basic use of transport layer channel 2891 security, initially in conjunction with TCP. Support for this 2892 protocol in conjunction with TCP is REQUIRED; associations using it 2893 can carry messages with transfer attributes requesting 2894 confidentiality or integrity protection. The specific TLS version 2895 will be negotiated within the TLS layer itself, but implementations 2896 MUST NOT negotiate to protocol versions prior to TLS1.0 [15] and MUST 2897 use the highest protocol version supported by both peers. 2898 Implementation of TLS1.1 [13] is RECOMMENDED. GIST nodes supporting 2899 TLS1.0 or TLS1.1 MUST- be able to negotiate the TLS ciphersuite 2900 TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD+ be able to negotiate the 2901 TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. They MAY negotiate any 2902 mutually acceptable ciphersuite that provides authentication, 2903 integrity, and confidentiality. 2905 The default mode of TLS authentication, which applies in particular 2906 to the above ciphersuites, uses a client/server X.509 certificate 2907 exchange. The Querying node acts as a TLS client, and the Responding 2908 node acts as a TLS server. Where one of the above ciphersuites is 2909 negotiated, the GIST node acting as a server MUST provide a 2910 certificate, and MUST request one from the GIST node acting as a TLS 2911 client. This allows either server-only or mutual authentication, 2912 depending on the certificates available to the client and the policy 2913 applied at the server. 2915 GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the 2916 negotiation of alternative ciphersuites is used to trigger 2917 alternative authentication procedures, such as the use of pre-shared 2918 keys [32]. The use of other authentication procedures may require 2919 additional specification work to define how they can be used as part 2920 of TLS within the GIST framework, and may or may not require the 2921 definition of additional MA-Protocol-IDs. 2923 No MA-protocol-options field is required for this TLS protocol 2924 definition. The configuration information for the transport protocol 2925 over which TLS is running (e.g. TCP port number) is provided by the 2926 MA-protocol-options for that protocol. 2928 5.7.3.1. Identity Checking in TLS 2930 After TLS authentication, a node MUST check the identity presented by 2931 the peer in order to avoid man-in-the-middle attacks, and verify that 2932 the peer is authorised to take part in signalling at the GIST layer. 2933 The authorisation check is carried out by comparing the presented 2934 identity with each Authorised Peer Database (APD) entry in turn, as 2935 discussed in Section 4.4.2. This section defines the identity 2936 comparison algorithm for a single APD entry. 2938 For TLS authentication with X.509 certificates, an identity from the 2939 DNS namespace MUST be checked against each subjectAltName extension 2940 of type dNSName present in the certificate. If no such extension is 2941 present, then the identity MUST be compared to the (most specific) 2942 Common Name in the Subject field of the certificate. When matching 2943 DNS names against dNSName or Common Name fields, matching is case- 2944 insensitive. Also, a "*" wildcard character MAY be used as the left- 2945 most name component in the certificate or identity in the APD. For 2946 example, *.example.com in the APD would match certificates for 2947 a.example.com, foo.example.com, *.example.com, etc., but would not 2948 match example.com. Similarly, a certificate for *.example.com would 2949 be valid for APD identities of a.example.com, foo.example.com, 2950 *.example.com, etc., but not example.com. 2952 Additionally, a node MUST verify the binding between the identity of 2953 the peer to which it connects and the public key presented by that 2954 peer. Nodes SHOULD implement the algorithm in Section 6 of [10] for 2955 general certificate validation, but MAY supplement that algorithm 2956 with other validation methods that achieve equivalent levels of 2957 verification (such as comparing the server certificate against a 2958 local store of already-verified certificates and identity bindings). 2960 For TLS authentication with pre-shared keys, the identity in the 2961 psk_identity_hint (for the server identity, i.e. the Responding node) 2962 or psk_identity (for the client identity, i.e. the Querying node) 2963 MUST be compared to the identities in the APD. 2965 5.8. Specific Message Routing Methods 2967 Each message routing method (see Section 3.3) requires the definition 2968 of the format of the message routing information (MRI) and Q-mode 2969 encapsulation rules. These are given in the following subsections 2970 for the MRMs currently defined. A GIST implementation on a node MUST 2971 support whatever MRMs are required by the NSLPs on that node; GIST 2972 implementations SHOULD provide support for both the MRMs defined 2973 here, in order to minimise deployment barriers for new signalling 2974 applications that need them. 2976 5.8.1. The Path-Coupled MRM 2978 5.8.1.1. Message Routing Information 2980 For the path-coupled MRM, this is conceptually the Flow Identifier as 2981 in the NSIS Framework [29]. Minimally, this could just be the flow 2982 destination address; however, to account for policy based forwarding 2983 and other issues a more complete set of header fields SHOULD be 2984 specified if possible (see Section 4.3.4 and Section 7.2 for further 2985 discussion). 2987 MRI = network-layer-version 2988 source-address prefix-length 2989 destination-address prefix-length 2990 IP-protocol 2991 diffserv-codepoint 2992 [ flow-label ] 2993 [ ipsec-SPI / L4-ports] 2995 Additional control information defines whether the flow-label, IPsec 2996 Security Parameters Index (SPI), and port information are present, 2997 and whether the IP-protocol and diffserv-codepoint fields should be 2998 interpreted as significant. The source and destination addresses 2999 MUST be real node addresses, but prefix lengths other than 32/128 3000 (for IPv4/6) MAY be used to implement address wildcarding, allowing 3001 the MRI to refer to traffic to or from a wider address range. 3003 The MRI format allows a potentially very large number of different 3004 flag and field combinations. A GIST implementation that cannot 3005 interpret the MRI in a message MUST return an "Object Value Error" 3006 message (Appendix A.4.4.10) with subcodes 1 ("Value Not Supported") 3007 or 2 ("Invalid Flag-Field Combination") and drop the message. 3009 5.8.1.2. Downstream Q-mode Encapsulation 3011 Where the signalling message is travelling in the same ('downstream') 3012 direction as the flow defined by the MRI, the IP addressing for 3013 Q-mode encapsulated messages is as follows. Support for this 3014 encapsulation is REQUIRED. 3016 o The destination IP address MUST be the flow destination address as 3017 given in the MRI of the message payload. 3019 o By default, the source address is the flow source address, again 3020 from the MRI; therefore, the source addressing mode flag in the 3021 common header S=0. This provides the best likelihood that the 3022 message will be correctly routed through any region performing 3023 per-packet policy-based forwarding or load balancing which takes 3024 the source address into account. However, there may be 3025 circumstances where the use of the signalling source address (S=1) 3026 is preferable, such as: 3028 * In order to receive ICMP error messages about the signalling 3029 message, such as unreachable port or address. If these are 3030 delivered to the flow source rather than the signalling source, 3031 it will be very difficult for the querying node to detect that 3032 it is the last GIST node on the path. Another case is where 3033 there is an abnormally low MTU along the path, in which case 3034 the querying node needs to see the ICMP error (recall that 3035 Q-mode packets are sent with DF set). 3037 * In order to receive GIST Error messages where the error message 3038 sender could not interpret the NLI in the original message. 3040 * In order to attempt to run GIST through an unmodified NAT, 3041 which will only process and translate IP addresses in the IP 3042 header (see Section 7.2.1). 3044 Because of these considerations, use of the signalling source 3045 address is allowed as an option, with use based on local policy. 3046 A node SHOULD use the flow source address for initial Query 3047 messages, but SHOULD transition to the signalling source address 3048 for some retransmissions or as a matter of static configuration, 3049 for example if a NAT is known to be in the path out of a certain 3050 interface. The S-flag in the common header tells the message 3051 receiver which option was used. 3053 A router alert option is also included in the IP header. The option 3054 value depends on the NSLP being signalled for. In addition, it is 3055 essential that the Query mimics the actual data flow as closely as 3056 possible, since this is the basis of how the signalling message is 3057 attached to the data path. To this end, GIST SHOULD set the DiffServ 3058 codepoint and (for IPv6) flow label to match the values in the MRI. 3060 A GIST implementation SHOULD apply validation checks to the MRI, to 3061 reject Query messages that are being injected by nodes with no 3062 legitimate interest in the flow being signalled for. In general, if 3063 the GIST node can detect that no flow could arrive over the same 3064 interface as the Query, it MUST be rejected with an appropriate error 3065 message. Such checks apply only to messages with the Q-mode 3066 encapsulation, since only those messages are required to track the 3067 flow path. The main checks are that the IP version used in the 3068 encapsulation should match that of the MRI and the version(s) used on 3069 that interface, and that the full range of source addresses (the 3070 source-address masked with its prefix-length) would pass ingress 3071 filtering checks. For these cases, the error message is "MRI 3072 Validation Failure" (Appendix A.4.4.12) with subcodes 1 or 2 ("IP 3073 Version Mismatch" or "Ingress Filter Failure") respectively. 3075 5.8.1.3. Upstream Q-mode Encapsulation 3077 In some deployment scenarios it is desirable to set up routing state 3078 in the upstream direction, (i.e. from flow receiver towards the 3079 sender). This could be used to support firewall signalling to 3080 control traffic from an un-cooperative sender, or signalling in 3081 general where the flow sender was not NSIS-capable. This capability 3082 is incorporated into GIST by defining an encapsulation and processing 3083 rules for sending Query messages upstream. 3085 In general, it is not possible to determine the hop-by-hop route 3086 upstream because of asymmetric IP routing. However, in particular 3087 cases, the upstream peer can be discovered with a high degree of 3088 confidence, for example: 3090 o The upstream GIST peer is 1 IP hop away, and can be reached by 3091 tracing back through the interface on which the flow arrives. 3093 o The upstream peer is a border router of a single-homed (stub) 3094 network. 3096 This section defines an upstream Q-mode encapsulation and validation 3097 checks for when it can be used. The functionality to generate 3098 upstream Queries is OPTIONAL, but if received they MUST be processed 3099 in the normal way with some additional IP TTL checks. No special 3100 functionality is needed for this. 3102 It is possible for routing state at a given node, for a specific MRI 3103 and NSLPID, to be created by both an upstream Query exchange 3104 (initiated by the node itself), and a downstream Query exchange 3105 (where the node is the responder). If the SIDs are different, these 3106 items of routing state MUST be considered as independent; if the SIDs 3107 match, the routing state installed by the downstream exchange MUST 3108 take precedence, provided that the downstream Query passed ingress 3109 filtering checks. The rationale for this is that the downstream 3110 Query is in general a more reliable way to install state, since it 3111 directly probes the IP routing infrastructure along the flow path, 3112 whereas use of the upstream Query depends on the correctness of the 3113 Querying node's understanding of the topology. 3115 The details of the encapsulation are as follows: 3117 o The destination address SHOULD be the flow source address as given 3118 in the MRI of the message payload. An implementation with more 3119 detailed knowledge of local IP routing MAY use an alternative 3120 destination address (e.g. the address of its default router). 3122 o The source address SHOULD be the signalling node address, so in 3123 the common header S=1. 3125 o A router alert option is included as in the downstream case. 3127 o The DiffServ codepoint and (for IPv6) flow label MAY be set to 3128 match the values from the MRI as in the downstream case, and the 3129 UDP port selection is also the same. 3131 o The IP layer TTL of the message MUST be set to 255. 3133 The sending GIST implementation SHOULD attempt to send the Query via 3134 the same interface and to the same link layer neighbour from which 3135 the data packets of the flow are arriving. 3137 The receiving GIST node MAY apply validation checks to the message 3138 and MRI, to reject Query messages which have reached a node at which 3139 they can no longer be trusted. In particular, a node SHOULD reject a 3140 message which has been propagated more than one IP hop, with an 3141 "Invalid IP layer TTL" error message (Appendix A.4.4.11). This can 3142 be determined by examining the received IP layer TTL, similar to the 3143 generalised IP TTL security mechanism described in [27]. 3144 Alternatively, receipt of an upstream Query at the flow source MAY be 3145 used to trigger setup of GIST state in the downstream direction. 3146 These restrictions may be relaxed in a future version. 3148 5.8.2. The Loose-End MRM 3150 The Loose-End MRM is used to discover GIST nodes with particular 3151 properties in the direction of a given address, for example to 3152 discover a NAT along the upstream data path as in [34]. 3154 5.8.2.1. Message Routing Information 3156 For the loose-end MRM, only a simplified version of the Flow 3157 Identifier is needed. 3159 MRI = network-layer-version 3160 source-address 3161 destination-address 3163 The source address is the address of the node initiating the 3164 discovery process, for example the node that will be the data 3165 receiver in the NAT discovery case. The destination address is the 3166 address of a node which is expected to be the other side of the node 3167 to be discovered. Additional control information defines the 3168 direction of the message relative to this flow as in the path-coupled 3169 case. 3171 5.8.2.2. Downstream Q-mode Encapsulation 3173 Only one encapsulation is defined for the loose-end MRM; by 3174 convention, this is referred to as the downstream encapsulation, and 3175 is defined as follows: 3177 o The IP destination address MUST be the destination address as 3178 given in the MRI of the message payload. 3180 o By default, the IP source address is the source address from the 3181 MRI (S=0). However, the use of the signalling source address 3182 (S=1) is allowed as in the case of the path-coupled MRM. 3184 A router alert option is included in the IP header. The option value 3185 depends on the NSLP being signalled for. There are no special 3186 requirements on the setting of the DiffServ codepoint, IP layer TTL, 3187 or (for IPv6) the flow label. Nor are any special validation checks 3188 applied. 3190 6. Formal Protocol Specification 3192 This section provides a more formal specification of the operation of 3193 GIST processing, in terms of rules for transitions between states of 3194 a set of communicating state machines within a node. The following 3195 description captures only the basic protocol specification; 3196 additional mechanisms can be used by an implementation to accelerate 3197 route change processing, and these are captured in Section 7.1. A 3198 more detailed description of the GIST protocol operation in state 3199 machine syntax can be found in [42]. 3201 Conceptually, GIST processing at a node may be seen in terms of four 3202 types of cooperating state machine: 3204 1. There is a top-level state machine which represents the node 3205 itself (Node-SM). It is responsible for the processing of events 3206 which cannot be directed towards a more specific state machine, 3207 for example, inbound messages for which no routing state 3208 currently exists. This machine exists permanently, and is 3209 responsible for creating per-MRI state machines to manage the 3210 GIST handshake and routing state maintenance procedures. 3212 2. For each flow and signalling direction where the node is 3213 responsible for the creation of routing state, there is an 3214 instance of a Query-Node state machine (Querying-SM). This 3215 machine sends Query and Confirm messages and waits for Responses, 3216 according to the requirements from local API commands or timer 3217 processing, such as message repetition or routing state refresh. 3219 3. For each flow and signalling direction where the node has 3220 accepted the creation of routing state by a peer, there is an 3221 instance of a Responding-Node state machine (Responding-SM). 3222 This machine is responsible for managing the status of the 3223 routing state for that flow. Depending on policy, it MAY be 3224 responsible for [re]transmission of Response messages, or this 3225 MAY be handled by the Node-SM, and a Responding-SM is not even 3226 created for a flow until a properly formatted Confirm has been 3227 accepted. 3229 4. Messaging associations have their own lifecycle, represented by 3230 an MA-SM, from when they are first created (in an incomplete 3231 state, listening for an inbound connection or waiting for 3232 outbound connections to complete), to when they are active and 3233 available for use. 3235 Apart from the fact that the various machines can be created and 3236 destroyed by each other, there is almost no interaction between them. 3237 The machines for different flows do not interact; the Querying-SM and 3238 Responding-SM for a single flow and signalling direction do not 3239 interact. That is, the Responding-SM which accepts the creation of 3240 routing state for a flow on one interface has no direct interaction 3241 with the Querying-SM which sets up routing state on the next 3242 interface along the path. This interaction is mediated instead 3243 through the NSLP. 3245 The state machine descriptions use the terminology rx_MMMM, tg_TTTT 3246 and er_EEEE for incoming messages, API/lower layer triggers and error 3247 conditions respectively. The possible events of these types are 3248 given in the table below. In addition, timeout events denoted 3249 to_TTTT may also occur; the various timers are listed independently 3250 for each type of state machine in the following subsections. 3252 +---------------------+---------------------------------------------+ 3253 | Name | Meaning | 3254 +---------------------+---------------------------------------------+ 3255 | rx_Query | A Query has been received. | 3256 | | | 3257 | rx_Response | A Response has been received. | 3258 | | | 3259 | rx_Confirm | A Confirm has been received. | 3260 | | | 3261 | rx_Data | A Data message has been received. | 3262 | | | 3263 | rx_Message | rx_Query||rx_Response||rx_Confirm||rx_Data. | 3264 | | | 3265 | rx_MA-Hello | A MA-Hello message has been received. | 3266 | | | 3267 | tg_NSLPData | A signalling application has requested data | 3268 | | transfer (via API SendMessage). | 3269 | | | 3270 | tg_Connected | The protocol stack for a messaging | 3271 | | association has completed connecting. | 3272 | | | 3273 | tg_RawData | GIST wishes to transfer data over a | 3274 | | particular messaging association. | 3275 | | | 3276 | tg_MAIdle | GIST decides that it is no longer necessary | 3277 | | to keep an MA open for itself. | 3278 | | | 3279 | er_NoRSM | A "No Routing State" error was received. | 3280 | | | 3281 | er_MAConnect | A messaging association protocol failed to | 3282 | | complete a connection. | 3283 | | | 3284 | er_MAFailure | A messaging association failed. | 3285 +---------------------+---------------------------------------------+ 3286 Incoming Events 3288 6.1. Node Processing 3290 The Node level state machine is responsible for processing events for 3291 which no more appropriate messaging association state or routing 3292 state exists. Its structure is trivial: there is a single state 3293 ('Idle'); all events cause a transition back to Idle. Some events 3294 cause the creation of other state machines. The only events that are 3295 processed by this state machine are incoming GIST messages (Query/ 3296 Response/Confirm/Data) and API requests to send data; no other events 3297 are possible. In addition to this event processing, the Node level 3298 machine is responsible for managing listening endpoints for messaging 3299 associations. Although these relate to Responding node operation, 3300 they cannot be handled by the Responder state machine since they are 3301 not created per flow. The processing rules for each event are as 3302 follows: 3304 Rule 1 (rx_Query): 3305 use the GIST service interface to determine the signalling 3306 application policy relating to this peer 3307 // note that this interaction delivers any NSLP-Data to 3308 // the NSLP as a side effect 3309 if (the signalling application indicates that routing state should 3310 be created) then 3311 if (routing state can be created without a 3-way handshake) then 3312 create Responding-SM and transfer control to it 3313 else 3314 send Response with R=1 3315 else 3316 propagate the Query with any updated NSLP payload provided 3318 Rule 2 (rx_Response): 3319 // a routing state error 3320 discard message 3322 Rule 3 (rx_Confirm): 3323 if (routing state can be created before receiving a Confirm) then 3324 // we should already have Responding-SM for it, 3325 // which would handle this message 3326 discard message 3327 send "No Routing State" error message 3328 else 3329 create Responding-SM and pass message to it 3331 Rule 4 (rx_Data): 3332 if (node policy will only process Data messages with matching 3333 routing state) then 3334 send "No Routing State" error message 3335 else 3336 pass directly to NSLP 3338 Rule 4 (er_NoRSM): 3339 discard the message 3341 Rule 5 (tg_NSLPData): 3342 if Q-mode encapsulation is not possible for this MRI 3343 reject message with an error 3344 else 3345 if (local policy & transfer attributes say routing 3346 state is not needed) then 3347 send message statelessly 3348 else 3349 create Querying-SM and pass message to it 3351 6.2. Query Node Processing 3353 The Querying-Node state machine (Querying-SM) has three states: 3355 o Awaiting Response 3357 o Established 3359 o Awaiting Refresh 3361 The Querying-SM is created by the Node-SM machine as a result of a 3362 request to send a message for a flow in a signalling direction where 3363 the appropriate state does not exist. The Query is generated 3364 immediately and the No_Response timer is started. The NSLP data MAY 3365 be carried in the Query if local policy and the transfer attributes 3366 allow it, otherwise it MUST be queued locally pending MA 3367 establishment. Then the machine transitions to the Awaiting Response 3368 state, in which timeout-based retransmissions are handled. Data 3369 messages (rx_Data events) should not occur in this state; if they do, 3370 this may indicate a lost Response and a node MAY retransmit a Query 3371 for this reason. 3373 Once a Response has been successfully received and routing state 3374 created, the machine transitions to Established, during which NSLP 3375 data can be sent and received normally. Further Responses received 3376 in this state (which may be the result of a lost Confirm) MUST be 3377 treated the same way. The Awaiting Refresh state can be considered 3378 as a substate of Established, where a new Query has been generated to 3379 refresh the routing state (as in Awaiting Response) but NSLP data can 3380 be handled normally. 3382 The timers relevant to this state machine are as follows: 3384 Refresh_QNode: Indicates when the routing state stored by this state 3385 machine must be refreshed. It is reset whenever a Response is 3386 received indicating that the routing state is still valid. 3387 Implementations MUST set the period of this timer based on the 3388 value in the RS-validity-time field of a Response to ensure that a 3389 Query is generated before the peer's routing state expires (see 3390 Section 4.4.4). 3392 No_Response: Indicates that a Response has not been received in 3393 answer to a Query. This is started whenever a Query is sent and 3394 stopped when a Response is received. 3396 Inactive_QNode: Indicates that no NSLP traffic is currently being 3397 handled by this state machine. This is reset whenever the state 3398 machine handles NSLP data, in either direction. When it expires, 3399 the state machine MAY be deleted. The period of the timer can be 3400 set at any time via the API (SetStateLifetime), and if the period 3401 is reset in this way the timer itself MUST be restarted. 3403 The main events (including all those that cause state transitions) 3404 are shown in the figure below, tagged with the number of the 3405 processing rule that is used to handle the event. These rules are 3406 listed after the diagram. All events not shown or described in the 3407 text above are assumed to be impossible in a correct implementation 3408 and MUST be ignored. 3410 [Initialisation] +-----+ 3411 -------------------------|Birth| 3412 | +-----+ 3413 | er_NoRSM[3](from all states) rx_Response[4] 3414 | || tg_NSLPData[5] 3415 | tg_NSLPData[1] || rx_Data[7] 3416 | -------- ------- 3417 | | V | V 3418 | | V | V 3419 | +----------+ +-----------+ 3420 ---->>| Awaiting | |Established| 3421 ------| Response |---------------------------->> | | 3422 | +----------+ rx_Response[4] +-----------+ 3423 | ^ | ^ | 3424 | ^ | ^ | 3425 | -------- | | 3426 | to_No_Response[2] | | 3427 | [!nResp_reached] tg_NSLPData[5] | | 3428 | || rx_Data[7] | | 3429 | -------- | | 3430 | | V | | 3431 | to_No_Response[2] | V | | 3432 | [nResp_reached] +-----------+ rx_Response[4] | | 3433 ---------- -----------| Awaiting |----------------- | 3434 | | | Refresh |<<------------------- 3435 | | +-----------+ to_Refresh_QNode[8] 3436 | | ^ | 3437 V V ^ | to_No_Response[2] 3438 V V -------- [!nResp_reached] 3439 +-----+ 3440 |Death|<<--------------- 3441 +-----+ to_Inactive_QNode[6] 3442 (from all states) 3444 Figure 7: Query Node State Machine 3446 The processing rules are as follows: 3448 Rule 1: Store the message for later transmission 3450 Rule 2: 3451 if number of Queries sent has reached the threshold 3452 // nQuery_isMax is true 3453 indicate No Response error to NSLP 3454 destroy self 3455 else 3456 send Query 3457 start No_Response timer with new value 3459 Rule 3: 3460 // Assume the Confirm was lost in transit or the peer has reset; 3461 // restart the handshake 3462 send Query 3463 (re)start No_Response timer 3465 Rule 4: 3466 if a new MA-SM is needed create one 3467 if the R flag was set send a Confirm 3468 send any stored Data messages 3469 stop No_Response timer 3470 start Refresh_QNode timer 3471 start Inactive_QNode timer if it was not running 3472 if there was piggybacked NSLP-Data 3473 pass it to the NSLP 3474 restart Inactive_QNOde timer 3476 Rule 5: 3477 send Data message 3478 restart Inactive_QNode timer 3480 Rule 6: Terminate 3482 Rule 7: 3483 pass any data to the NSLP 3484 restart Inactive_QNode timer 3486 Rule 8: 3487 send Query 3488 start No_Response timer 3489 stop Refresh_QNode timer 3491 6.3. Responder Node Processing 3493 The Responding-Node state machine (Responding-SM) has three states: 3495 o Awaiting Confirm 3497 o Established 3499 o Awaiting Refresh 3501 The policy governing the handling of Query messages and the creation 3502 of the Responding-SM has three cases: 3504 1. No Confirm is required for a Query, and the state machine can be 3505 created immediately. 3507 2. A Confirm is required for a Query, but the state machine can 3508 still be created immediately. A timer is used to retransmit 3509 Response messages and the Responding-SM is destroyed if no valid 3510 Confirm is received. 3512 3. A Confirm is required for a Query, and the state machine can only 3513 be created when it is received; the initial Query will have been 3514 handled by the Node level machine. 3516 In case 2 the Responding-SM is created in the Awaiting Confirm state, 3517 and remains there until a Confirm is received, at which point it 3518 transitions to Established. In cases 1 and 3 the Responding-SM is 3519 created directly in the Established state. Note that if the machine 3520 is created on receiving a Query, some of the message processing will 3521 already have been performed in the Node state machine. In principle, 3522 an implementation MAY change its policy on handling a Query message 3523 at any time; however, the state machine descriptions here cover only 3524 the case where the policy is fixed while waiting for a Confirm 3525 message. 3527 In the Established state the NSLP can send and receive data normally, 3528 and any additional rx_Confirm events MUST be silently ignored. The 3529 Awaiting Refresh state can be considered a substate of Established, 3530 where a Query has been received to begin the routing state refresh. 3531 In the Awaiting Refresh state the Responding-SM behaves as in the 3532 Awaiting Confirm state, except that the NSLP can still send and 3533 receive data. In particular, in both states there is timer-based 3534 retransmission of Response messages until a Confirm is received; 3535 additional rx_Query events in these states MUST also generate a reply 3536 and restart the no_Confirm timer. 3538 The timers relevant to the operation of this state machine are as 3539 follows: 3541 Expire_RNode: Indicates when the routing state stored by this state 3542 machine needs to be expired. It is reset whenever a Query or 3543 Confirm (depending on local policy) is received indicating that 3544 the routing state is still valid. Note that state cannot be 3545 refreshed from the R-Node. If this timer fires, the routing state 3546 machine is deleted, regardless of whether a No_Confirm timer is 3547 running. 3549 No_Confirm: Indicates that a Confirm has not been received in answer 3550 to a Response. This is started/reset whenever a Response is sent 3551 and stopped when a Confirm is received. 3553 The detailed state transitions and processing rules are described 3554 below as in the Query node case. 3556 rx_Query[1] rx_Query[5] 3557 [confirmRequired] +-----+ [!confirmRequired] 3558 -------------------------|Birth|---------------------------- 3559 | +-----+ | 3560 | | rx_Confirm[2] | 3561 | ---------------------------- | 3562 | | | 3563 | rx_Query[5] | | 3564 | tg_NSLPData[7] || rx_Confirm[10] | | 3565 | || rx_Query[1] || rx_Data[4] | | 3566 | || rx_Data[6] || tg_NSLPData[3] | | 3567 | -------- -------------- | | 3568 | | V | V V V 3569 | | V | V V V 3570 | +----------+ | +-----------+ 3571 ---->>| Awaiting | rx_Confirm[8] -----------|Established| 3572 ------| Confirm |------------------------------>> | | 3573 | +----------+ +-----------+ 3574 | ^ | ^ | 3575 | ^ | tg_NSLPData[3] ^ | 3576 | -------- || rx_Query[1] | | 3577 | to_No_Confirm[9] || rx_Data[4] | | 3578 | [!nConf_reached] -------- | | 3579 | | V | | 3580 | to_No_Confirm[9] | V | | 3581 | [nConf_reached] +-----------+ rx_Confirm[8] | | 3582 ---------- ------------| Awaiting |----------------- | 3583 | | | Refresh |<<------------------- 3584 | | +-----------+ rx_Query[1] 3585 | | ^ | [confirmRequired] 3586 | | ^ | 3587 | | -------- 3588 V V to_No_Confirm[9] 3589 V V [!nConf_reached] 3590 +-----+ 3591 |Death|<<--------------------- 3592 +-----+ er_NoRSM[11] 3593 to_Expire_RNode[11] 3594 (from Established/Awaiting Refresh) 3596 Figure 8: Responder Node State Machine 3598 The processing rules are as follows: 3600 Rule 1: 3601 // a Confirm is required 3602 send Response with R=1 3603 (re)start No_Confirm timer with the initial timer value 3604 Rule 2: 3605 pass any NSLP-Data object to the NSLP 3606 start Expire_RNode timer 3608 Rule 3: send the Data message 3610 Rule 4: pass data to NSLP 3612 Rule 5: 3613 // no Confirm is required 3614 send Response with R=0 3615 start Expire_RNode timer 3617 Rule 6: 3618 drop incoming data 3619 send "No Routing State" error message 3621 Rule 7: store Data message 3623 Rule 8: 3624 pass any NSLP-Data object to the NSLP 3625 send any stored Data messages 3626 stop No_Confirm timer 3627 start Expire_RNode timer 3629 Rule 9: 3630 if number of Responses sent has reached threshold 3631 // nResp_isMax is true 3632 destroy self 3633 else 3634 send Response 3635 start No_Response timer 3637 Rule 10: 3638 // can happen e.g. a retransmitted Response causes a duplicate Confirm 3639 silently ignore 3641 Rule 11: destroy self 3643 6.4. Messaging Association Processing 3645 Messaging associations (MAs) are modelled for use within GIST with a 3646 simple three-state process. The Awaiting Connection state indicates 3647 that the MA is waiting for the connection process(es) for every 3648 protocol in the messaging association to complete; this might involve 3649 creating listening endpoints or attempting active connects. Timers 3650 may also be necessary to detect connection failure (e.g. no incoming 3651 connection within a certain period), but these are not modelled 3652 explicitly. 3654 The Connected state indicates that the MA is open and ready to use, 3655 and that the node wishes it to remain open. In this state, the node 3656 operates a timer (SendHello) to ensure that messages are regularly 3657 sent to the peer, to ensure that the peer does not tear the MA down. 3658 The node transitions from Connected to Idle (indicating that it no 3659 longer needs the association) as a matter of local policy; one way to 3660 manage the policy is to use an activity timer but this is not 3661 specified explicitly by the state machine (see also Section 4.4.5). 3663 In the Idle state, the node no longer requires the messaging 3664 association but the peer still requires it and is indicating this by 3665 sending periodic MA-Hello messages. A different timer (NoHello) 3666 operates to purge the MA when these messages stop arriving. If real 3667 data is transferred over the MA, the state machine transitions back 3668 to Connected. 3670 At any time in the Connected or Idle states, a node MAY test the 3671 connectivity to its peer and the liveness of the GIST instance at 3672 that peer by sending a MA-Hello request with R=1. Failure to receive 3673 a reply with a matching Hello-ID within a timeout MAY be taken as a 3674 reason to trigger er_MAFailure. Initiation of such a test and the 3675 timeout setting are left to the discretion of the implementaion. 3676 Note that er_MAFailure may also be signalled by indications from the 3677 underlying messaging association protocols. If a messaging 3678 association fails, this MUST be indicated back to the routing state 3679 machines which use it, and these MAY generate indications to 3680 signalling applications. In particular, if the messaging association 3681 was being used to deliver messages reliably, this MUST be reported as 3682 a NetworkNotification error (Appendix B.4). 3684 Clearly, many internal details of the messaging association protocols 3685 are hidden in this model, especially where the messaging association 3686 uses multiple protocol layers. Note also that although the existence 3687 of messaging associations is not directly visible to signalling 3688 applications, there is some interaction between the two because 3689 security-related information becomes available during the open 3690 process, and this may be indicated to signalling applications if they 3691 have requested it. 3693 The timers relevant to the operation of this state machine are as 3694 follows: 3696 SendHello: Indicates that an MA-Hello message should be sent to the 3697 remote node. The period of this timer is determined by the MA- 3698 Hold-Time sent by the remote node during the Query/Response/ 3699 Confirm exchange. 3701 NoHello: Indicates that no MA-Hello has been received from the 3702 remote node for a period of time. The period of this timer is 3703 sent to the remote node as the MA-Hold-Time during the Query/ 3704 Response exchange. 3706 The detailed state transitions and processing rules are described 3707 below as in the Query node case. 3708 [Initialisation] +-----+ 3709 ----------------------------|Birth| 3710 | +-----+ tg_RawData[1] 3711 | || rx_Message[2] 3712 | || rx_MA-Hello[3] 3713 | tg_RawData[5] || to_SendHello[4] 3714 | -------- -------- 3715 | | V | V 3716 | | V | V 3717 | +----------+ +-----------+ 3718 ---->>| Awaiting | tg_Connected[6] | Connected | 3719 ------|Connection|----------------------->>| | 3720 | +----------+ +-----------+ 3721 | ^ | 3722 | tg_RawData[1] ^ | 3723 | || rx_Message[2] | | tg_MAIdle[7] 3724 | | V 3725 | | V 3726 | er_MAConnect[8] +-----+ to_NoHello[8] +-----------+ 3727 ---------------->>|Death|<<----------------| Idle | 3728 +-----+ +-----------+ 3729 ^ ^ | 3730 ^ ^ | 3731 --------------- -------- 3732 er_MAFailure[8] rx_MA-Hello[9] 3733 (from Connected/Idle) 3735 Figure 9: Messaging Association State Machine 3737 The processing rules are as follows: 3739 Rule 1: 3740 pass message to transport layer 3741 if the NoHello timer was running, stop it 3742 (re)start SendHello 3744 Rule 2: 3745 pass message to Node-SM, or R-SM (for a Confirm), 3746 or Q-SM (for a Response) 3747 if the NoHello timer was running, stop it 3748 Rule 3: 3749 if reply requested 3750 send MA-Hello 3751 restart SendHello timer 3753 Rule 4: 3754 send MA-Hello message 3755 restart SendHello timer 3757 Rule 5: queue message for later transmission 3759 Rule 6: 3760 pass outstanding queued messages to transport layer 3761 stop any timers controlling connection establishment 3762 start SendHello timer 3764 Rule 7: 3765 stop SendHello timer 3766 start NoHello timer 3768 Rule 8: 3769 report failure to routing state machines and signalling applications 3770 destroy self 3772 Rule 9: 3773 if reply requested 3774 send MA-Hello 3775 restart NoHello timer 3777 7. Additional Protocol Features 3779 7.1. Route Changes and Local Repair 3781 7.1.1. Introduction 3783 When IP layer re-routing takes place in the network, GIST and 3784 signalling application state need to be updated for all flows whose 3785 paths have changed. The updates to signalling application state 3786 depend mainly on the signalling application: for example, if the path 3787 characteristics have actually changed, simply moving state from the 3788 old to the new path is not sufficient. Therefore, GIST cannot carry 3789 out the complete path update processing. Its responsibilities are to 3790 detect the route change, update its local routing state consistently, 3791 and inform interested signalling applications at affected nodes. 3793 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 3794 x +--+ +--+ +--+ x Initial 3795 x .|C1|_.....|D1|_.....|E1| x Configuration 3796 x . +--+. .+--+. .+--+\. x 3797 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 3798 +-+ +-+ . .. .. . +-+ 3799 ...|A|_......|B|/ .. .. .|F|_.... 3800 +-+ +-+ . . . . . . +-+ 3801 . . . . . . 3802 . +--+ +--+ +--+ . 3803 .|C2|_.....|D2|_.....|E2|/ 3804 +--+ +--+ +--+ 3806 +--+ +--+ +--+ Configuration 3807 .|C1|......|D1|......|E1| after failure 3808 . +--+ .+--+ +--+ of E1-F link 3809 . \. . \. ./ 3810 +-+ +-+ . .. .. +-+ 3811 ...|A|_......|B|. .. .. .|F|_.... 3812 +-+ +-+\ . . . . . +-+ 3813 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 3814 x . +--+ +--+ +--+ . x 3815 x .|C2|_.....|D2|_.....|E2|/ x 3816 x +--+ +--+ +--+ x 3817 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 3819 ........... = physical link topology 3820 >>xxxxxxx>> = flow direction 3821 _.......... = outgoing link for flow xxxxxx given 3822 by local forwarding table 3824 Figure 10: A Re-Routing Event 3826 Route change management is complicated by the distributed nature of 3827 the problem. Consider the re-routing event shown in Figure 10. An 3828 external observer can tell that the main responsibility for 3829 controlling the updates will probably lie with nodes B and F; 3830 however, E1 is best placed to detect the event quickly at the GIST 3831 level, and C1 and D1 could also attempt to initiate the repair. 3833 The NSIS framework [29] makes the assumption that signalling 3834 applications are soft-state based and operate end to end. In this 3835 case, because GIST also periodically updates its picture of routing 3836 state, route changes will eventually be repaired automatically. The 3837 specification as already given includes this functionality. However, 3838 especially if upper layer refresh times are extended to reduce 3839 signalling load, the duration of inconsistent state may be very long 3840 indeed. Therefore, GIST includes logic to exchange prompt 3841 notifications with signalling applications, to allow local repair if 3842 possible. The additional mechanisms to achieve this are described in 3843 the following subsections. To a large extent, these additions can be 3844 seen as implementation issues; the protocol messages and their 3845 significance are not changed, but there are extra interactions 3846 through the API between GIST and signalling applications, and 3847 additional triggers for transitions between the various GIST states. 3849 7.1.2. Route Change Detection Mechanisms 3851 There are two aspects to detecting a route change at a single node: 3853 o Detecting that the outgoing path, in the direction of the Query, 3854 has or may have changed. 3856 o Detecting that the incoming path, in the direction of the 3857 Response, has (or may have) changed, in which case the node may no 3858 longer be on the path at all. 3860 At a single node, these processes are largely independent, although 3861 clearly a change in one direction at a node corresponds to a change 3862 in the opposite direction at its peer. Note that there are two 3863 possible forms for a route change: the interface through which a flow 3864 leaves or enters a node may change, and the adjacent peer may change. 3865 In general, a route change can include one or the other or both (or 3866 indeed neither, although such changes are very hard to detect). 3868 The route change detection mechanisms available to a node depend on 3869 the MRM in use and the role the node played in setting up the routing 3870 state in the first place (i.e. as Querying or Responding node). The 3871 following discussion is specific to the case of the path-coupled MRM 3872 using downstream Queries only; other scenarios may require other 3873 methods. However, the repair logic described in the subsequent 3874 subsections is intended to be universal. 3876 There are five mechanisms for a node to detect that a route change 3877 has occurred, which are listed below. They apply differently 3878 depending on whether the change is in the Query or Response 3879 direction, and these differences are summarised in the following 3880 table. 3882 Local Trigger: In local trigger mode, GIST finds out from the local 3883 forwarding table that the next hop has changed. This only works 3884 if the routing change is local, not if it happens a few IP routing 3885 hops away, including the case that it happens at a GIST-unaware 3886 node. 3888 Extended Trigger: Here, GIST checks a link-state topology database 3889 to discover that the path has changed. This makes certain 3890 assumptions on consistency of IP route computation and only works 3891 within a single area for OSPF [16] and similar link-state 3892 protocols. Where available, this offers the most accurate and 3893 rapid indication of route changes, but requires more access to the 3894 routing internals than a typical operating system may provide. 3896 GIST C-mode Monitoring: GIST may find that C-mode packets are 3897 arriving (from either peer) with a different IP layer TTL or on a 3898 different interface. This provides no direct information about 3899 the new flow path, but indicates that routing has changed and that 3900 rediscovery may be required. 3902 Data Plane Monitoring: The signalling application on a node may 3903 detect a change in behaviour of the flow, such as IP layer TTL 3904 change, arrival on a different interface, or loss of the flow 3905 altogether. The signalling application on the node is allowed to 3906 notify this information locally to GIST (Appendix B.6). 3908 GIST Probing: According to the specification, each GIST node MUST 3909 periodically repeat the discovery (Query/Response) operation. 3910 Values for the probe frequency are discussed in Section 4.4.4. 3911 The querying node will discover the route change by a modification 3912 in the Network-Layer-Information in the Response. The period can 3913 be negotiated independently for each GIST hop, so nodes that have 3914 access to the other techniques listed above MAY use long periods 3915 between probes. 3917 +-------------+--------------------------+--------------------------+ 3918 | Method | Query direction | Response direction | 3919 +-------------+--------------------------+--------------------------+ 3920 | Local | Discovers new interface | Not applicable | 3921 | Trigger | (and peer if local) | | 3922 | | | | 3923 | Extended | Discovers new interface | May determine that route | 3924 | Trigger | and may determine new | from peer will have | 3925 | | peer | changed | 3926 | | | | 3927 | C-mode | Provides hint that | Provides hint that | 3928 | Monitoring | change has occurred | change has occurred | 3929 | | | | 3930 | Data Plane | Not applicable | NSLP informs GIST that a | 3931 | Monitoring | | change may have occurred | 3932 | | | | 3933 | Probing | Discovers changed NLI in | Discovers changed NLI in | 3934 | | Response | Query | 3935 +-------------+--------------------------+--------------------------+ 3937 7.1.3. GIST Behaviour Supporting Re-Routing 3939 The basic GIST behaviour necessary to support re-routing can be 3940 modelled using a 3-level classification of the validity of each item 3941 of current routing state. (In addition to current routing state, 3942 NSIS can maintain past routing state, described in Section 7.1.4 3943 below.) This classification applies separately to the Querying and 3944 Responding node for each pair of GIST peers. The levels are: 3946 Bad: The routing state is either missing altogether, or not safe to 3947 use to send data. 3949 Tentative: The routing state may have changed, but it is still 3950 usable for sending NSLP data pending verification. 3952 Good: The routing state has been established and no events affecting 3953 it have since been detected. 3955 These classifications are not identical to the states described in 3956 Section 6, but there are dependencies between them. Specifically, 3957 routing state is considered Bad until the state machine first enters 3958 the Established state, at which point it becomes Good. Thereafter, 3959 the status may be invalidated for any of the reasons discussed above; 3960 it is an implementation issue to decide which techniques to implement 3961 in any given node, and how to reclassify routing state (as Bad or 3962 Tentative) for each. The status returns to Good, either when the 3963 state machine re-enters the Established state, or if GIST can 3964 determine from direct examination of the IP routing or forwarding 3965 tables that the peer has not changed. When the status returns to 3966 Good, GIST MUST if necessary update its routing state table so that 3967 the relationships between MRI/SID/NSLPID tuples and messaging 3968 associations are up to date. 3970 When classification of the routing state for the downstream direction 3971 changes to Bad/Tentative because of local IP routing indications, 3972 GIST MAY automatically change the classification in the upstream 3973 direction to Tentative unless local routing indicates that this is 3974 not necessary. This SHOULD NOT be done in the case where the initial 3975 change was indicated by the signalling application. This mechanism 3976 accounts for the fact that a routing change may affect several nodes, 3977 and so can be an indication that upstream routing may also have 3978 changed. In any case, whenever GIST updates the routing status, it 3979 informs the signalling application with the NetworkNotification API 3980 (Appendix B.4), unless the change was caused via the API in the first 3981 place. 3983 The GIST behaviour for state repair is different for the Querying and 3984 Responding node. At the Responding node, there is no additional 3985 behaviour, since the Responding node cannot initiate protocol 3986 transitions autonomously, it can only react to the Querying node. 3987 The Querying node has three options, depending on how the transition 3988 from 'Good' was initially caused: 3990 1. To inspect the IP routing/forwarding table and verifying that the 3991 next peer has not changed. This technique MUST NOT be used if 3992 the transition was caused by a signalling application, but SHOULD 3993 be used otherwise if available. 3995 2. To move to the 'Awaiting Refresh' state. This technique MUST NOT 3996 be used if the current status is 'Bad', since data is being 3997 incorrectly delivered. 3999 3. To move to the 'Awaiting Response' state. This technique may be 4000 used at any time, but has the effect of freezing NSLP 4001 communication while GIST state is being repaired. 4003 The second and third techniques trigger the execution of a GIST 4004 handshake to carry out the repair. It may be desirable to delay the 4005 start of the handshake process, either to wait for the network to 4006 stabilise, to avoid flooding the network with Query traffic for a 4007 large number of affected flows, or to wait for confirmation that the 4008 node is still on the path from the upstream peer. One approach is to 4009 delay the handshake until there is NSLP data to be transmitted. 4010 Implementation of such delays is a matter of local policy; however, 4011 GIST MUST begin the handshake immediately if the status change was 4012 caused by an InvalidateRoutingState API call marked as 'Urgent', and 4013 SHOULD begin it if the upstream routing state is still known to be 4014 Good. 4016 7.1.4. Load Splitting and Route Flapping 4018 The Q-mode encapsulation rules of Section 5.8 try to ensure that the 4019 Query messages discovering the path mimic the flow as accurately as 4020 possible. However, in environments where there is load balancing 4021 over multiple routes, and this is based on header fields differing 4022 between flow and Q-mode packets or done on a round-robin basis, the 4023 path discovered by the Query may vary from one handshake to the next 4024 even though the underlying network is stable. This will appear to 4025 GIST as a route flap; route flapping can also be caused by problems 4026 in the basic network connectivity or routing protocol operation. For 4027 example, a mobile node might be switching back and forth between two 4028 links, or might appear to have disappeared even though it is still 4029 attached to the network via a different route. 4031 This specification does not define mechanisms for GIST to manage 4032 multiple parallel routes or an unstable route; instead, GIST MAY 4033 expose this to the NSLP, which can then manage it according to 4034 signalling application requirements. The algorithms already 4035 described always maintain the concept of the current route, i.e. the 4036 latest peer discovered for a particular flow. Instead, GIST allows 4037 the use of prior signalling paths for some period while the 4038 signalling applications still need them. Since NSLP peers are a 4039 single GIST hop apart, the necessary information to represent a path 4040 can be just an entry in the node's routing state table for that flow 4041 (more generally, anything that uniquely identifies the peer, such as 4042 the NLI, could be used). Rather than requiring GIST to maintain 4043 multiple generations of this information, it is provided to the 4044 signalling application in the same node in an opaque form for each 4045 message that is received from the peer. The signalling application 4046 can store it if necessary and provide it back to the GIST layer in 4047 case it needs to be used. Because this is a reference to information 4048 about the source of a prior signalling message, it is denoted 'SII- 4049 Handle' (for Source Identification Information) in the abstract API 4050 of Appendix B. 4052 Note that GIST if possible SHOULD use the same SII-Handle for 4053 multiple sessions to the same peer, since this then allows signalling 4054 applications to aggregate some signalling, such as summary refreshes 4055 or bulk teardowns. Messages sent using the SII-Handle MUST bypass 4056 the routing state tables at the sender, and this MUST be indicated by 4057 setting the E flag in the common header (Appendix A.1). Messages 4058 other than Data messages MUST NOT be sent in this way. At the 4059 receiver, GIST MUST NOT validate the MRI/SID/NSLPID against local 4060 routing state and instead indicates the mode of reception to 4061 signalling applications through the API (Appendix B.2). Signalling 4062 applications should validate the source and effect of the message 4063 themselves, and if appropriate should in particular indicate to GIST 4064 (see Appendix B.5) that routing state is no longer required for this 4065 flow. This is necessary to prevent GIST in nodes on the old path 4066 initiating routing state refresh and thus causing state conflicts at 4067 the crossover router. 4069 GIST notifies signalling applications about route modifications as 4070 two types of event, additions and deletions. An addition is notified 4071 as a change of the current routing state according to the Bad/ 4072 Tentative/Good classification above, while deletion is expressed as a 4073 statement that an SII-Handle no longer lies on the path. Both can be 4074 reported through the NetworkNotification API call (Appendix B.4). A 4075 minimal implementation MAY notify a route change as a single (add, 4076 delete) operation; however, a more sophisticated implementation MAY 4077 delay the delete notification, for example if it knows that the old 4078 route continues to be used in parallel, or that the true route is 4079 flapping between the two. It is then a matter of signalling 4080 application design whether to tear down state on the old path, leave 4081 it unchanged, or modify it in some signalling application specific 4082 way to reflect the fact that multiple paths are operating in 4083 parallel. 4085 7.1.5. Signalling Application Operation 4087 Signalling applications can use these functions as provided by GIST 4088 to carry out rapid local repair following re-routing events. The 4089 signalling application instances carry out the multi-hop aspects of 4090 the procedure, including crossover node detection, and tear-down/ 4091 reinstallation of signalling application state; they also trigger 4092 GIST to carry out the local routing state maintenance operations over 4093 each individual hop. The local repair procedures depend heavily on 4094 the fact that stateful NSLP nodes are a single GIST hop apart; this 4095 is enforced by the details of the GIST peer discovery process. 4097 The following outline description of a possible set of NSLP actions 4098 takes the scenario of Figure 10 as an example. 4100 1. The signalling application at node E1 is notified by GIST of 4101 route changes affecting the downstream and upstream directions. 4102 The downstream status was updated to Bad because of a trigger 4103 from the local forwarding tables, and the upstream status changed 4104 automatically to Tentative as a consequence. The signalling 4105 application at E1 MAY begin local repair immediately, or MAY 4106 propagate a notification upstream to D1 that re-routing has 4107 occurred. 4109 2. The signalling application at node D1 is notified of the route 4110 change, either by signalling application notifications or from 4111 the GIST level (e.g. by a trigger from a link-state topology 4112 database). If the information propagates faster within the IP 4113 routing protocol, GIST will change the upstream/downstream 4114 routing state to Tentative/Bad automatically, and this will cause 4115 the signalling application to propagate the notification further 4116 upstream. 4118 3. This process continues until the notification reaches node A. 4119 Here, there is no downstream routing change, so GIST only learns 4120 of the update via the signalling application trigger. Since the 4121 upstream status is still Good, it therefore begins the repair 4122 handshake immediately. 4124 4. The handshake initiated by node A causes its downstream routing 4125 state to be confirmed as Good and unchanged there; it also 4126 confirms the (Tentative) upstream routing state at B as Good. 4127 This is enough to identify B as the crossover router, and the 4128 signalling application and GIST can begin the local repair 4129 process. 4131 An alternative way to reach step (4) is that node B is able to 4132 determine autonomously that there is no likelihood of an upstream 4133 route change. For example, it could be an area border router and the 4134 route change is only intra-area. In this case, the signalling 4135 application and GIST will see that the upstream state is Good and can 4136 begin the local repair directly. 4138 After a route deletion, a signalling application may wish to remove 4139 state at another node which is no longer on the path. However, since 4140 it is no longer on the path, in principle GIST can no longer send 4141 messages to it. In general, provided this state is soft, it will 4142 time out anyway; however, the timeouts involved may have been set to 4143 be very long to reduce signalling load. Instead, signalling 4144 applications MAY use the SII-Handle described above to route explicit 4145 teardown messages. 4147 7.2. NAT Traversal 4149 GIST messages, for example for the path-coupled MRM, must carry 4150 addressing and higher layer information as payload data in order to 4151 define the flow signalled for. (This applies to all GIST messages, 4152 regardless of how they are encapsulated or which direction they are 4153 travelling in.) At an addressing boundary the data flow packets will 4154 have their headers translated; if the signalling payloads are not 4155 translated consistently, the signalling messages will refer to 4156 incorrect (and probably meaningless) flows after passing through the 4157 boundary. In addition, GIST handshake messages carry additional 4158 addressing information about the GIST nodes themselves, and this must 4159 also be processed appropriately when traversing a NAT. 4161 There is a dual problem of whether the GIST peers either side of the 4162 boundary can work out how to address each other, and whether they can 4163 work out what translation to apply to the signalling packet payloads. 4164 Existing generic NAT traversal techniques such as STUN [25] or TURN 4165 [26] can operate only on the two addresses visible in the IP header. 4166 It is therefore intrinsically difficult to use these techniques to 4167 discover a consistent translation of the three or four interdependent 4168 addresses for the flow and signalling source and destination. 4170 For legacy NATs and MRMs that carry addressing information, the base 4171 GIST specification is therefore limited to detecting the situation 4172 and triggering the appropriate error conditions to terminate the 4173 signalling path. (MRMs that do not contain addressing information 4174 could traverse such NATs safely, with some modifications to the GIST 4175 processing rules. Such modifications could be described in the 4176 documents defining such MRMs.) Legacy NAT handling is covered in 4177 Section 7.2.1 below. A more general solution can be constructed 4178 using GIST-awareness in the NATs themselves; this solution is 4179 outlined in Section 7.2.2 with processing rules in Section 7.2.3. 4181 In all cases, GIST interaction with the NAT is determined by the way 4182 the NAT handles the Query/Response messages in the initial GIST 4183 handshake; these messages are UDP datagrams. Best current practice 4184 for NAT treatment of UDP traffic is defined in [38], and the legacy 4185 NAT handling defined in this specification is fully consistent with 4186 that document. The GIST-aware NAT traversal technique is equivalent 4187 to requiring an Application Layer Gateway in the NAT for a specific 4188 class of UDP transactions, namely those where the destination UDP 4189 port for the initial message is the GIST port (see Section 9). 4191 7.2.1. Legacy NAT Handling 4193 Legacy NAT detection during the GIST handshake depends on analysis of 4194 the IP header and S flag in the GIST common header, and the NLI 4195 object included in the handshake messages. The message sequence 4196 proceeds differently depending on whether the Querying node is on the 4197 internal or external side of the NAT. 4199 For the case of the Querying node on the internal side of the NAT, if 4200 the S flag is not set in the Query (S=0), a legacy NAT cannot be 4201 detected. The receiver will generate a normal Response to the 4202 interface-address given in the NLI in the Query, but the interface- 4203 address will not be routable and the Response will not be delivered. 4204 If retransmitted Queries keep S=0, this behaviour will persist until 4205 the Querying node times out. The signalling path will thus terminate 4206 at this point, not traversing the NAT. 4208 The situation changes once S=1 in a Query; note the Q-mode 4209 encapsulation rules recommend that S=1 is used at least for some 4210 retransmissions (see Section 5.8). If S=1, the receiver MUST check 4211 the source address in the IP header against the interface-address in 4212 the NLI, and if these addresses do not match this indicates that a 4213 legacy NAT has been found. For MRMs which contain addressing 4214 information that needs translation, legacy NAT traversal is not 4215 possible. The receiver MUST return an "Object Type Error" message 4216 (Appendix A.4.4.9) with subcode 4 ("Untranslated Object") indicating 4217 the MRI as the object in question. The error message MUST be 4218 addressed to the source address from the IP header of the incoming 4219 message. The Responding node SHOULD use the destination IP address 4220 of the original datagram as the source address for IP header of the 4221 Response; this makes it more likely that the NAT will accept the 4222 incoming message, since it looks like a normal UDP/IP request/reply 4223 exchange. If this message is able to traverse back through the NAT, 4224 the Querying node will terminate the handshake immediately; 4225 otherwise, this reduces to the previous case of a lost Response and 4226 the Querying node will give up on reaching its retransmission limit. 4228 When the Querying node is on the external side of the NAT, the Query 4229 will only traverse the NAT if some static configuration has been 4230 carried out on the NAT to forward GIST Q-mode traffic to a node on 4231 the internal network. Regardless of the S-flag in the Query, the 4232 Responding node cannot directly detect the presence of the NAT. It 4233 MUST send a normal Response with S=1 to an address derived from the 4234 Querying node's NLI which will traverse the NAT as normal UDP 4235 traffic. The Querying node MUST check the source address in the IP 4236 header with the NLI in the Response, and when it finds a mismatch it 4237 MUST terminate the handshake. 4239 Note that in either of the error cases (internal or external Querying 4240 node), an alternative to terminating the handshake could be to invoke 4241 some legacy NAT traversal procedure. This specification does not 4242 define any such procedure, although one possible approach is 4243 described in [40]. Any such traversal procedure MUST be incorporated 4244 into GIST using the existing GIST extensibility capabilities. Note 4245 also that this detection process only functions with the handshake 4246 exchange; it cannot operate on simple Data messages, whether they are 4247 Q-mode or normally encapsulated. Nodes SHOULD NOT send Data messages 4248 outside a messaging association if they cannot ensure that they are 4249 operating in an environment free of legacy NATs. 4251 7.2.2. GIST-aware NAT Traversal 4253 The most robust solution to the NAT traversal problem is to require 4254 that a NAT is GIST-aware, and to allow it to modify messages based on 4255 the contents of the MRI. This makes the assumption that NATs only 4256 rewrite the header fields included in the MRI, and not other higher 4257 layer identifiers. Provided this is done consistently with the data 4258 flow header translation, signalling messages will be valid each side 4259 of the boundary, without requiring the NAT to be signalling 4260 application aware. Note, however, that if the NAT does not 4261 understand the MRI, and the N-flag in the MRI is clear (see 4262 Appendix A.3.1), it should reject the message with an "Object Type 4263 Error" message (Appendix A.4.4.9) with subcode 4 ("Untranslated 4264 Object"). 4266 This specification defines an additional object that a NAT inserts 4267 into all Q-mode encapsulated messages and which is echoed back in any 4268 replies, i.e. Response or Error messages. NATs apply GIST-specific 4269 processing only to Q-mode encapsulated messages or replies carrying 4270 the NAT traversal object. All other GIST messages, either in C-mode, 4271 or D-mode messages with no NAT-Traversal object, should be treated as 4272 normal data traffic by the NAT, i.e. with IP and transport layer 4273 header translation but no GIST-specific processing. 4275 The new object, the NAT-Traversal object (Appendix A.3.9), carries 4276 the translation between the MRIs which are appropriate for the 4277 internal and external sides of the NAT. It also carries a list of 4278 which other objects in the message have been translated. This should 4279 always include the NLI, and the Stack-Configuration-Data if present; 4280 if GIST is extended with further objects that carry addressing data, 4281 this list allows a message receiver to know if the new objects were 4282 supported by the NAT. Finally, the NAT-Traversal object MAY be used 4283 to carry data to assist the NAT in back-translating D-mode responses; 4284 this could be the original NLI or SCD, or opaque equivalents in the 4285 case of topology hiding. 4287 A consequence of this approach is that the routing state tables at 4288 the signalling application peers each side of the NAT are no longer 4289 directly compatible. In particular, they use different MRI values to 4290 refer to the same flow. However, subsequent messages after the 4291 Query/Response (Data messages and the initial Confirm) need to use a 4292 common MRI, since the NAT does not rewrite these, and this is chosen 4293 to be the MRI of the Querying node. It is the responsibility of the 4294 Responding node to translate between the two MRIs on inbound and 4295 outbound messages, which is why the unmodified MRI is propagated in 4296 the NAT-Traversal object. 4298 7.2.3. Message Processing Rules 4300 This specification normatively defines the behaviour of a GIST node 4301 receiving a message containing a NAT-Traversal object. However, it 4302 does not define normative behaviour for a NAT translating GIST 4303 messages, since much of this will depend on NAT implementation and 4304 policy about allocating bindings. In addition, it is not necessary 4305 for a GIST implementation itself. Therefore, those aspects of the 4306 following description are informative; full details of NAT behaviour 4307 for handling GIST messages can be found in [41]. 4309 A possible set of operations for a NAT to process a Q-mode 4310 encapsulated message is as follows. Note that for a Data message, 4311 only a subset of the operations is applicable. 4313 1. Verify that bindings for any data flow are actually in place. 4315 2. Create a new Message-Routing-Information object with fields 4316 modified according to the data flow bindings. 4318 3. Create bindings for subsequent C-mode signalling based on the 4319 information in the Network-Layer-Information and Stack- 4320 Configuration-Data objects. 4322 4. Create new Network-Layer-Information and if necessary Stack- 4323 Configuration-Data objects with fields to force D-mode response 4324 messages through the NAT, and to allow C-mode exchanges using the 4325 C-mode signalling bindings. 4327 5. Add a NAT-Traversal object, listing the objects which have been 4328 modified and including the unmodified MRI and any other data 4329 needed to interpret the response. If a NAT-Traversal object is 4330 already present, in the case of a sequence of NATs, the list of 4331 modified objects may be updated and further opaque data added, 4332 but the MRI contained in it is left unchanged. 4334 6. Encapsulate the message according to the normal rules of this 4335 specification for the Q-mode encapsulation. If the S-flag was 4336 set in the original message, the same IP source address selection 4337 policy should be applied to the forwarded message. 4339 7. Forward the message with these new payloads. 4341 A GIST node receiving such a message MUST verify that all mandatory 4342 objects containing addressing have been translated correctly, or else 4343 reject the message with an "Object Type Error" message 4344 (Appendix A.4.4.9) with subcode 4 ("Untranslated Object"). The error 4345 message MUST include the NAT-Traversal object as the first TLV after 4346 the common header, and this is also true for any other error message 4347 generated as a reply. Otherwise, the message is processed 4348 essentially as normal. If no state needs to be updated for the 4349 message, the NAT-Traversal object can be effectively ignored. The 4350 other possibility is that a Response must be returned, either because 4351 the message is the beginning of a handshake for a new flow, or it is 4352 a refresh for existing state. In both cases, the GIST node MUST 4353 create the Response in the normal way using the local form of the 4354 MRI, and its own NLI and (if necessary) SCD. It MUST also include 4355 the NAT-Traversal object as the first object in the Response after 4356 the common header. 4358 A NAT will intercept D-mode messages with the normal encapsulation 4359 containing such echoed NAT-Traversal objects. The NAT processing is 4360 a subset of the processing for the Q-mode encapsulated case: 4362 1. Verify the existence of bindings for the data flow. 4364 2. Leave the Message-Routing-Information object unchanged. 4366 3. Modify the NLI and SCD objects for the Responding node if 4367 necessary, and create or update any bindings for C-mode 4368 signalling traffic. 4370 4. Forward the message. 4372 A GIST node receiving such a message (Response or Error) MUST use the 4373 MRI from the NAT-Traversal object as the key to index its internal 4374 routing state; it MAY also store the translated MRI for additional 4375 (e.g. diagnostic) information, but this is not used in the GIST 4376 processing. The remainder of GIST processing is unchanged. 4378 Note that Confirm messages are not given GIST-specific processing by 4379 the NAT. Thus, a Responding node which has delayed state 4380 installation until receiving the Confirm, only has available the 4381 untranslated MRI describing the flow, and the untranslated NLI as 4382 peer routing state. This would prevent the correct interpretation of 4383 the signalling messages; also, subsequent Query (refresh) messages 4384 would always be seen as route changes because of the NLI change. 4385 Therefore, a Responding node that wishes to delay state installation 4386 until receiving a Confirm must somehow reconstruct the translations 4387 when the Confirm arrives. How to do this is an implementation issue; 4388 one approach is to carry the translated objects as part of the 4389 Responder cookie which is echoed in the Confirm. Indeed, for one of 4390 the cookie constructions in Section 8.5 this is automatic. 4392 7.3. Interaction with IP Tunnelling 4394 The interaction between GIST and IP tunnelling is very simple. An IP 4395 packet carrying a GIST message is treated exactly the same as any 4396 other packet with the same source and destination addresses: in other 4397 words, it is given the tunnel encapsulation and forwarded with the 4398 other data packets. 4400 Tunnelled packets will not be identifiable as GIST messages until 4401 they leave the tunnel, since any router alert option and the standard 4402 GIST protocol encapsulation (e.g. port numbers) will be hidden within 4403 the standard tunnel encapsulation. If signalling is needed for the 4404 tunnel itself, this has to be initiated as a separate signalling 4405 session by one of the tunnel endpoints - that is, the tunnel counts 4406 as a new flow. Because the relationship between signalling for the 4407 microflow and signalling for the tunnel as a whole will depend on the 4408 signalling application in question, it is a signalling application 4409 responsibility to be aware of the fact that tunnelling is taking 4410 place and to carry out additional signalling if necessary; in other 4411 words, at least one tunnel endpoint must be signalling application 4412 aware. 4414 In some cases, it is the tunnel exit point (i.e. the node where 4415 tunnelled data and downstream signalling packets leave the tunnel) 4416 that will wish to carry out the tunnel signalling, but this node will 4417 not have knowledge or control of how the tunnel entry point is 4418 carrying out the data flow encapsulation. The information about how 4419 the inner MRI/SID relate to the tunnel MRI/SID needs to be carried in 4420 the signalling data from the tunnel entry point; this functionality 4421 is the equivalent to the RSVP SESSION_ASSOC object of [17]. In the 4422 NSIS protocol suite, these bindings are managed by the signalling 4423 applications, either implicitly (e.g. by SID re-use) or explicitly by 4424 carrying objects that bind the inner and outer SIDs as part of the 4425 NSLP payload. 4427 7.4. IPv4-IPv6 Transition and Interworking 4429 GIST itself is essentially IP version neutral: version dependencies 4430 are isolated in the formats of the Message-Routing-Information, 4431 Network-Layer-Information and Stack-Configuration-Data objects, and 4432 GIST also depends on the version independence of the protocols that 4433 support messaging associations. In mixed environments, GIST 4434 operation will be influenced by the IP transition mechanisms in use. 4435 This section provides a high level overview of how GIST is affected, 4436 considering only the currently predominant mechanisms. 4438 Dual Stack: (As described in [35].) In mixed environments, GIST 4439 MUST use the same IP version for Q-mode encapsulated messages as 4440 given by the MRI of the flow it is signalling for, and SHOULD do 4441 so for other signalling also (see Section 5.2.2). Messages with 4442 mismatching versions MUST be rejected with an "MRI Validation 4443 Failure" error message (Appendix A.4.4.12) with subcode 1 ("IP 4444 Version Mismatch"). The IP version used in D-mode is closely tied 4445 to the IP version used by the data flow, so it is intrinsically 4446 impossible for an IPv4-only or IPv6-only GIST node to support 4447 signalling for flows using the other IP version. Hosts which are 4448 dual stack for applications and routers which are dual stack for 4449 forwarding need GIST implementations which can support both IP 4450 versions. Applications with a choice of IP versions might select 4451 a version based on which could be supported in the network by 4452 GIST, which could be established by invoking parallel discovery 4453 procedures. 4455 Packet Translation: (Applicable to SIIT [9] and NAT-PT [18].) Some 4456 transition mechanisms allow IPv4 and IPv6 nodes to communicate by 4457 placing packet translators between them. From the GIST 4458 perspective, this should be treated essentially the same way as 4459 any other NAT operation (e.g. between internal and external 4460 addresses) as described in Section 7.2. The translating node 4461 needs to be GIST-aware; it will have to translate the addressing 4462 payloads between IPv4 and IPv6 formats for flows which cross 4463 between the two. The translation rules for the fields in the MRI 4464 payload (including e.g. DiffServ-codepoint and flow-label) are as 4465 defined in [9]. 4467 Tunnelling: (Applicable to 6to4 [20].) Many transition mechanisms 4468 handle the problem of how an end to end IPv6 (or IPv4) flow can be 4469 carried over intermediate IPv4 (or IPv6) regions by tunnelling; 4470 the methods tend to focus on minimising the tunnel administration 4471 overhead. 4473 From the GIST perspective, the treatment should be similar to any 4474 other IP tunnelling mechanism, as described in Section 7.3. In 4475 particular, the end to end flow signalling will pass transparently 4476 through the tunnel, and signalling for the tunnel itself will have 4477 to be managed by the tunnel endpoints. However, additional 4478 considerations may arise because of special features of the tunnel 4479 management procedures. In particular, [21] is based on using an 4480 anycast address as the destination tunnel endpoint. GIST MAY use 4481 anycast destination addresses in the Q-mode encapsulation of 4482 D-mode messages if necessary, but MUST NOT use them in the 4483 Network-Layer-Information addressing field; unicast addresses MUST 4484 be used instead. Note that the addresses from the IP header are 4485 not used by GIST in matching requests and replies, so there is no 4486 requirement to use anycast source addresses. 4488 8. Security Considerations 4490 The security requirement for GIST is to protect the signalling plane 4491 against identified security threats. For the signalling problem as a 4492 whole, these threats have been outlined in [30]; the NSIS framework 4493 [29] assigns a subset of the responsibilities to the NTLP. The main 4494 issues to be handled can be summarised as: 4496 Message Protection: Signalling message content can be protected 4497 against eavesdropping, modification, injection and replay while in 4498 transit. This applies both to GIST payloads, and GIST should also 4499 provide such protection as a service to signalling applications 4500 between adjacent peers. 4502 Routing State Integrity Protection: It is important that signalling 4503 messages are delivered to the correct nodes, and nowhere else. 4504 Here, 'correct' is defined as 'the appropriate nodes for the 4505 signalling given the Message-Routing-Information'. In the case 4506 where the MRI is based on the Flow Identification for path-coupled 4507 signalling, 'appropriate' means 'the same nodes that the 4508 infrastructure will route data flow packets through'. GIST has no 4509 role in deciding whether the data flow itself is being routed 4510 correctly; all it can do is ensure the signalling is routed 4511 consistently with it. GIST uses internal state to decide how to 4512 route signalling messages, and this state needs to be protected 4513 against corruption. 4515 Prevention of Denial of Service Attacks: GIST nodes and the network 4516 have finite resources (state storage, processing power, 4517 bandwidth). The protocol tries to minimise exhaustion attacks 4518 against these resources and not allow GIST nodes to be used to 4519 launch attacks on other network elements. 4521 The main additional issue is handling authorisation for executing 4522 signalling operations (e.g. allocating resources). This is assumed 4523 to be done in each signalling application. 4525 In many cases, GIST relies on the security mechanisms available in 4526 messaging associations to handle these issues, rather than 4527 introducing new security measures. Obviously, this requires the 4528 interaction of these mechanisms with the rest of the GIST protocol to 4529 be understood and verified, and some aspects of this are discussed in 4530 Section 5.7. 4532 8.1. Message Confidentiality and Integrity 4534 GIST can use messaging association functionality, specifically in 4535 this version TLS (Section 5.7.3), to ensure message confidentiality 4536 and integrity. Implementation of this functionality is REQUIRED but 4537 its use for any given flow or signalling application is OPTIONAL. In 4538 some cases, confidentiality of GIST information itself is not likely 4539 to be a prime concern, in particular since messages are often sent to 4540 parties which are unknown ahead of time, although the content visible 4541 even at the GIST level gives significant opportunities for traffic 4542 analysis. Signalling applications may have their own mechanism for 4543 securing content as necessary; however, they may find it convenient 4544 to rely on protection provided by messaging associations, since it 4545 runs unbroken between signalling application peers. 4547 8.2. Peer Node Authentication 4549 Cryptographic protection (of confidentiality or integrity) requires a 4550 security association with session keys. These can be established by 4551 an authentication and key exchange protocol based on shared secrets, 4552 public key techniques or a combination of both. Authentication and 4553 key agreement is possible using the protocols associated with the 4554 messaging association being secured. TLS incorporates this 4555 functionality directly. GIST nodes rely on the messaging association 4556 protocol to authenticate the identity of the next hop, and GIST has 4557 no authentication capability of its own. 4559 With routing state discovery, there are few effective ways to know 4560 what is the legitimate next or previous hop as opposed to an 4561 impostor. In other words, cryptographic authentication here only 4562 provides assurance that a node is 'who' it is (i.e. the legitimate 4563 owner of identity in some namespace), not 'what' it is (i.e. a node 4564 which is genuinely on the flow path and therefore can carry out 4565 signalling for a particular flow). Authentication provides only 4566 limited protection, in that a known peer is unlikely to lie about its 4567 role. Additional methods of protection against this type of attack 4568 are considered in Section 8.3 below. 4570 It is an implementation issue whether peer node authentication should 4571 be made signalling application dependent; for example, whether 4572 successful authentication could be made dependent on presenting 4573 credentials related to a particular signalling role (e.g. signalling 4574 for QoS). The abstract API of Appendix B leaves open such policy and 4575 authentication interactions between GIST and the NSLP it is serving. 4576 However, it does allow applications to inspect the authenticated 4577 identity of the peer to which a message will be sent before 4578 transmission. 4580 8.3. Routing State Integrity 4582 Internal state in a node (see Section 4.2) is used to route messages. 4583 If this state is corrupted, signalling messages may be misdirected. 4585 In the case where the MRM is path-coupled, the messages need to be 4586 routed identically to the data flow described by the MRI, and the 4587 routing state table is the GIST view of how these flows are being 4588 routed through the network in the immediate neighbourhood of the 4589 node. Routes are only weakly secured (e.g. there is no cryptographic 4590 binding of a flow to a route), and there is no authoritative 4591 information about flow routes other than the current state of the 4592 network itself. Therefore, consistency between GIST and network 4593 routing state has to be ensured by directly interacting with the IP 4594 routing mechanisms to ensure that the signalling peers are the 4595 appropriate ones for any given flow. An overview of security issues 4596 and techniques in this context is provided in [37]. 4598 In one direction, peer identification is installed and refreshed only 4599 on receiving a Response (compare Figure 5). This MUST echo the 4600 cookie from a previous Query, which will have been sent along the 4601 flow path with the Q-mode encapsulation, i.e. end-to-end addressed. 4602 Hence, only the true next peer or an on-path attacker will be able to 4603 generate such a message, provided freshness of the cookie can be 4604 checked at the querying node. 4606 In the other direction, peer identification MAY be installed directly 4607 on receiving a Query containing addressing information for the 4608 signalling source. However, any node in the network could generate 4609 such a message; indeed, many nodes in the network could be the 4610 genuine upstream peer for a given flow. To protect against this, 4611 four strategies are used: 4613 Filtering: the receiving node MAY reject signalling messages which 4614 claim to be for flows with flow source addresses which could be 4615 ruled out by ingress filtering. An extension of this technique 4616 would be for the receiving node to monitor the data plane and to 4617 check explicitly that the flow packets are arriving over the same 4618 interface and if possible from the same link layer neighbour as 4619 the D-mode signalling packets. If they are not, it is likely that 4620 at least one of the signalling or flow packets is being spoofed. 4622 Return routability checking: the receiving node MAY refuse to 4623 install upstream state until it has completed a Confirm handshake 4624 with the peer. This echoes the Response cookie of the Response, 4625 and discourages nodes from using forged source addresses. This 4626 also plays a role in denial of service prevention, see below. 4628 Authorisation: a stronger approach is to carry out a peer 4629 authorisation check (see Section 4.4.2) as part of messaging 4630 association setup. The ideal situation is that the receiving node 4631 can determine the correct upstream node address from routing table 4632 analysis or knowledge of local topology constraints, and then 4633 verify from the authorised peer database (APD) that the peer has 4634 this IP address. This is only technically feasible in a limited 4635 set of deployment environments. The APD can also be used to list 4636 the subsets of nodes which are feasible peers for particular 4637 source or destination subnets, or to blacklist nodes which have 4638 previously originated attacks or exist in untrustworthy networks, 4639 which provide weaker levels of authorisation checking. 4641 SID segregation: The routing state lookup for a given MRI and NSLPID 4642 MUST also take the SID into account. A malicious node can only 4643 overwrite existing GIST routing state if it can guess the 4644 corresponding SID; it can insert state with random SID values, but 4645 generally this will not be used to route signalling messages for 4646 which state has already been legitimately established. 4648 8.4. Denial of Service Prevention and Overload Protection 4650 GIST is designed so that in general each Query only generates at most 4651 one Response which is at most only slightly larger than the Query, so 4652 that a GIST node cannot become the source of a denial of service 4653 amplification attack. (There is a special case of retransmitted 4654 Response messages, see Section 5.3.3.) 4656 However, GIST can still be subjected to denial-of-service attacks 4657 where an attacker using forged source addresses forces a node to 4658 establish state without return routability, causing a problem similar 4659 to TCP SYN flood attacks. Furthermore, an adversary might use 4660 modified or replayed unprotected signalling messages as part of such 4661 an attack. There are two types of state attacks and one 4662 computational resource attack. In the first state attack, an 4663 attacker floods a node with messages that the node has to store until 4664 it can determine the next hop. If the destination address is chosen 4665 so that there is no GIST-capable next hop, the node would accumulate 4666 messages for several seconds until the discovery retransmission 4667 attempt times out. The second type of state-based attack causes GIST 4668 state to be established by bogus messages. A related computational/ 4669 network-resource attack uses unverified messages to cause a node 4670 query an authentication or authorisation infrastructure, or attempt 4671 to cryptographically verify a digital signature. 4673 We use a combination of two defences against these attacks: 4675 1. The responding node need not establish a session or discover its 4676 next hop on receiving the Query, but MAY wait for a Confirm, 4677 possibly on a secure channel. If the channel exists, the 4678 additional delay is one one-way delay and the total is no more 4679 than the minimal theoretically possible delay of a three-way 4680 handshake, i.e., 1.5 node-to-node round-trip times. The delay 4681 gets significantly larger if a new connection needs to be 4682 established first. 4684 2. The Response to the Query contains a cookie, which is repeated in 4685 the Confirm. State is only established for messages that contain 4686 a valid cookie. The setup delay is also 1.5 round-trip times. 4687 This mechanism is similar to that in SCTP [19] and other modern 4688 protocols. 4690 There is a potential overload condition if a node is flooded with 4691 Query or Confirm messages. One option is for the node to bypass 4692 these messages altogether as described in Section 4.3.2, effectively 4693 falling back to being a non-NSIS node. If this is not possible, a 4694 node MAY still choose to limit the rate at which it processes Query 4695 messages and discard the excess, although it SHOULD first adapt its 4696 policy to one of sending Responses statelessly if it is not already 4697 doing so. A conformant GIST node will automatically decrease the 4698 load by retransmitting Queries with an exponential backoff. A non- 4699 conformant node (launching a DoS attack) can generate uncorrelated 4700 Queries at an arbitrary rate, which makes it hard to apply rate- 4701 limiting without also affecting genuine handshake attempts. However, 4702 if Confirm messages are requested, the cookie binds the message to a 4703 Querying node address which has been validated by a return 4704 routability check and rate-limits can be applied per-source. 4706 Once a node has decided to establish routing state, there may still 4707 be transport and security state to be established between peers. 4708 This state setup is also vulnerable to denial of service attacks. 4709 GIST relies on the implementations of the lower layer protocols that 4710 make up messaging associations to mitigate such attacks. In the 4711 current specification, the querying node is always the one wishing to 4712 establish a messaging association, so it is the responding node that 4713 needs to be protected. It is possible for an attacking node to 4714 execute these protocols legally to set up large numbers of 4715 associations that were never used, and responding node 4716 implementations MAY use rate-limiting or other techniques to control 4717 the load in such cases. 4719 Signalling applications can use the services provided by GIST to 4720 defend against certain (e.g. flooding) denial of service attacks. In 4721 particular, they can elect to process only messages from peers that 4722 have passed a return routability check or been authenticated at the 4723 messaging association level (see Appendix B.2). Signalling 4724 applications that accept messages under other circumstances (in 4725 particular, before routing state has been fully established at the 4726 GIST level) need to take this into account when designing their 4727 denial of service prevention mechanisms, for example by not creating 4728 local state as a result of processing such messages. Signalling 4729 applications can also manage overload by invoking flow control, as 4730 described in Section 4.1.1. 4732 8.5. Requirements on Cookie Mechanisms 4734 The requirements on the Query cookie can be summarised as follows: 4736 Liveness: The cookie must be live, that is, it must change from one 4737 handshake to the next. To prevent replay attacks. 4739 Unpredictability: The cookie must not be guessable e.g. from a 4740 sequence or timestamp. To prevent direct forgery based on seeing 4741 a history of captured messages. 4743 Easily validated: It must be efficient for the Q-Node to validate 4744 that a particular cookie matches an in-progress handshake, for a 4745 routing state machine which already exists. To discard responses 4746 which have been randomly generated by an adversary, or to discard 4747 responses to queries which were generated with forged source 4748 addresses or an incorrect address in the included NLI object. 4750 Uniqueness: The cookie must be unique to a given handshake since it 4751 is actually used to match the Response to a handshake anyway, e.g. 4752 because of messaging association multiplexing. 4754 Likewise, the requirements on the Responder cookie can be summarised 4755 as follows: 4757 Liveness: The cookie must be live as above, to prevent replay 4758 attacks. 4760 Creation simplicity: The cookie must be lightweight to generatem, to 4761 avoid resource exhaustion at the responding node. 4763 Validation simplicity: It must be simple for the R-node to validate 4764 that an R-cookie was generated by itself and no-one else, without 4765 storing state about the handshake it was generated for. 4767 Binding: The cookie must be bound to the routing state that will be 4768 installed, to prevent use with different routing state e.g. in a 4769 modified Confirm. The routing state here includes the Peer- 4770 Identity and Interface-Address given in the NLI of the Query, and 4771 the MRI/NSLPID for the messaging. It also includes the interface 4772 on which the Query was received (since a Q-mode encapsulated 4773 message is the one that will best follow the data path and so 4774 arrive on the correct interface). 4776 A suitable implementation for the Q-Cookie is a cryptographically 4777 strong random number which is unique for this routing state machine 4778 handshake. A node MUST implement this or an equivalently strong 4779 mechanism. Guidance on random number generation can be found in 4780 [31]. 4782 A suitable basic implementation for the R-Cookie is as follows: 4784 R-Cookie = liveness data + reception interface 4785 + hash (locally known secret, 4786 Q-Node NLI identity and address, MRI, NSLPID, 4787 liveness data) 4789 A node MUST implement this or an equivalently strong mechanism. 4790 There are several alternatives for the liveness data. One is to use 4791 a timestamp like SCTP. Another is to give the local secret a (rapid) 4792 rollover, with the liveness data as the generation number of the 4793 secret, like IKEv2. In both cases, the liveness data has to be 4794 carried outside the hash, to allow the hash to be verified at the 4795 Responder. Another approach is to replace the hash with encryption 4796 under a locally known secret, in which case the liveness data does 4797 not need to be carried in the clear. Any symmetric cipher immune to 4798 known plaintext attacks can be used. In the case of GIST-aware NAT 4799 traversal with delayed state installation it is necessary to carry 4800 additional data in the cookie; appropriate constructions are 4801 described in [41]. 4803 To support the validation simplicity requirement, the Responder can 4804 check the liveness data to filter out some blind (flooding) attacks 4805 before beginning any cryptographic cookie verification. To support 4806 this usage, the liveness data must be carried in the clear and not be 4807 easily guessable; this rules out the timestamp approach, and suggests 4808 the use of sequence of secrets with the liveness data identifying the 4809 position in the sequence. The secret strength and rollover frequency 4810 must be high enough that the secret cannot be brute-forced during its 4811 lifetime. Note that any node can use a Query to discover the current 4812 liveness data, so it remains hard to defend against sophisticated 4813 attacks which disguise such probes within a flood of Queries from 4814 forged source addresses. Therefore, it remains important to use an 4815 efficient hashing mechanism or equivalent. 4817 If a node receives a message for which cookie validation fails, it 4818 MAY return an "Object Value Error" message (Appendix A.4.4.10) with 4819 subcode 4 ("Invalid Cookie") to the sender and SHOULD log an error 4820 condition locally, as well as dropping the message. However, sending 4821 the error in general makes a node a source of backscatter. 4822 Therefore, this MUST only be enabled selectively, e.g. during initial 4823 deployment or debugging. 4825 8.6. Security Protocol Selection Policy 4827 This specification defines a single mandatory-to-implement security 4828 protocol (TLS, Section 5.7.3). However, it is possible to define 4829 additional security protocols in the future, for example to allow re- 4830 use with other types of credentials, or migrate towards protocols 4831 with stronger security properties. In addition, use of any security 4832 protocol for a messaging association is optional. Security protocol 4833 selection is carried out as part of the GIST handshake mechanism 4834 (Section 4.4.1). 4836 The selection process may be vulnerable to downgrade attacks, where a 4837 man in the middle modifies the capabilities offered in the Query or 4838 Response to mislead the peers into accepting a lower level of 4839 protection than is achievable. There is a two part defence against 4840 such attacks (the following is based the same concepts as [24]): 4842 1. The Response does not depend on the Stack-Proposal in the Query 4843 (see Section 5.7.1). Therefore, tampering with the Query has no 4844 effect on the resulting messaging association configuration. 4846 2. The Responding node's Stack-Proposal is echoed in the Confirm. 4847 The Responding node checks this to validate that the proposal it 4848 made in the Response is the same as the one received by the 4849 Querying node. Note that as a consequence of the previous point, 4850 the Responding node does not have to remember the proposal 4851 explicitly, since it is a static function of local policy. 4853 The validity of the second part depends on the strength of the 4854 security protection provided for the Confirm. If the Querying node 4855 is prepared to create messaging associations with null security 4856 properties (e.g. TCP only), the defence is ineffective, since the 4857 man in the middle can re-insert the original Responder's Stack- 4858 Proposal, and the Responding node will assume that the minimal 4859 protection is a consequence of Querying node limitations. However, 4860 if the messaging association provides at least integrity protection 4861 that cannot be broken in real-time, the Confirm cannot be modified in 4862 this way. Therefore, if the Querying node does not apply a security 4863 policy to the messaging association protocols to be created that 4864 ensures at least this minimal level of protection is met, it remains 4865 open to the threat that a downgrade has occurred. Applying such a 4866 policy ensures capability discovery process will result in the setup 4867 of a messaging association with the correct security properties as 4868 appropriate for the two peers involved. 4870 8.7. Residual Threats 4872 Taking the above security mechanisms into account, the main residual 4873 threats against NSIS are three types of on-path attack, as well as 4874 implementation-related weaknesses. 4876 An on-path attacker who can intercept the initial Query can do most 4877 things it wants to the subsequent signalling. It is very hard to 4878 protect against this at the GIST level; the only defence is to use 4879 strong messaging association security to see whether the Responding 4880 node is authorised to take part in NSLP signalling exchanges. To 4881 some extent, this behaviour is logically indistinguishable from 4882 correct operation, so it is easy to see why defence is difficult. 4883 Note that an on-path attacker of this sort can do anything to the 4884 traffic as well as the signalling. Therefore, the additional threat 4885 induced by the signalling weakness seems tolerable. 4887 At the NSLP level, there is a concern about transitivity of trust of 4888 correctness of routing along the signalling chain. The NSLP at the 4889 querying node can have good assurance that it is communicating with 4890 an on-path peer or a node delegated by the on-path node by depending 4891 on the security protection provided by GIST. However, it has no 4892 assurance that the node beyond the responder is also on-path, or that 4893 the MRI (in particular) is not being modified by the responder to 4894 refer to a different flow. Therefore, if it sends signalling 4895 messages with payloads (e.g. authorisation tokens) which are valuable 4896 to nodes beyond the adjacent hop, it is up to the NSLP to ensure that 4897 the appropriate chain of trust exists. This could be achieved using 4898 higher layer security protection such as CMS [28]. 4900 There is a further residual attack by a node which is not on the path 4901 of the Query, but is on the path of the Response, or is able to use a 4902 Response from one handshake to interfere with another. The attacker 4903 modifies the Response to cause the Querying node to form an adjacency 4904 with it rather than the true peer. In principle, this attack could 4905 be prevented by including an additional cryptographic object in the 4906 Response which ties the Response to the initial Query and the routing 4907 state and can be verified by the Querying node. 4909 Certain security aspects of GIST operation depend on signalling 4910 application behaviour: a poorly implemented or compromised NSLP could 4911 degrade GIST security. However, the degradation would only affect 4912 GIST handling of the NSLP's own signalling traffic or overall 4913 resource usage at the node where the weakness occurred, and 4914 implementation weakness or compromise could have just as great an 4915 effect within the NSLP itself. GIST depends on NSLPs to choose SIDs 4916 appropriately (Section 4.1.3). If NSLPs choose non-random SIDs this 4917 makes off-path attacks based on SID guessing easier to carry out. 4919 NSLPs can also leak information in structured SIDs, but they could 4920 leak similar information in the NLSP payload data anyway. 4922 9. IANA Considerations 4924 This section defines the registries and initial codepoint assignments 4925 for GIST. It also defines the procedural requirements to be followed 4926 by IANA in allocating new codepoints. Note that the guidelines on 4927 the technical criteria to be followed in evaluating requests for new 4928 codepoint assignments are covered normatively in a separate document 4929 which considers the NSIS protocol suite in a unified way. That 4930 document discusses the general issue of NSIS extensibility, as well 4931 as the technical criteria for particular registries. 4933 The registry definitions that follow leave large blocks of codes 4934 marked "Reserved - not to be allocated". This is to allow a future 4935 revision of this specification or another Standards Track document to 4936 modify the relative space given to different allocation policies 4937 without having to change the initial rules retrospectively if they 4938 turn out to have been inappropriate, e.g. if the space for one 4939 particular policy is exhausted too quickly. 4941 The allocation policies used in this section follow the guidance 4942 given in [6]. In addition, for a number of the GIST registries, this 4943 specification also defines private/experimental ranges as discussed 4944 in [11]. Note that the only environment in which these codepoints 4945 can validly be used is a closed one in which the experimenter knows 4946 all the experiments in progress. 4948 This specification allocates the following codepoints in existing 4949 registries: 4951 Well-known UDP port XXX as the destination port for Q-mode 4952 encapsulated GIST messages (Section 5.3). 4954 This specification creates the following registries with the 4955 structures as defined below: 4957 NSLP Identifiers: Each signalling application requires the 4958 assignment of one or more NSLPIDs. The following NSLPID is 4959 allocated by this specification: 4961 +---------+---------------------------------------------------------+ 4962 | NSLPID | Application | 4963 +---------+---------------------------------------------------------+ 4964 | 0 | Used for GIST messages not related to any signalling | 4965 | | application. | 4966 +---------+---------------------------------------------------------+ 4968 Every other NSLPID that uses an MRM which requires RAO usage MUST 4969 be associated with a specific RAO value; multiple NSLPIDs MAY be 4970 associated with the same RAO value. RAO value assignments require 4971 a specification of the processing associated with messages that 4972 carry the value. NSLP specifications MUST normatively depend on 4973 this document for the processing, specifically Section 4.3.1, 4974 Section 4.3.4 and Section 5.3.2. The NSLPID is a 16 bit integer, 4975 and allocation policies for further values are as follows: 4977 1-32703: IESG Approval 4979 32704-32767: Private/Experimental Use 4981 32768-65536: Reserved - not to be allocated 4983 GIST Message Type: The GIST common header (Appendix A.1) contains a 4984 1 byte message type field. The following values are allocated by 4985 this specification: 4987 +---------+----------+ 4988 | MType | Message | 4989 +---------+----------+ 4990 | 0 | Query | 4991 | | | 4992 | 1 | Response | 4993 | | | 4994 | 2 | Confirm | 4995 | | | 4996 | 3 | Data | 4997 | | | 4998 | 4 | Error | 4999 | | | 5000 | 5 | MA-Hello | 5001 +---------+----------+ 5003 Allocation policies for further values are as follows: 5005 6-63: Standards Action 5007 64-119: Expert Review 5009 120-127: Private/Experimental Use 5011 128-255: Reserved - not to be allocated 5013 Object Types: There is a 12-bit field in the object header 5014 (Appendix A.2). The following values for object type are defined 5015 by this specification: 5017 +---------+-----------------------------+ 5018 | OType | Object Type | 5019 +---------+-----------------------------+ 5020 | 0 | Message Routing Information | 5021 | | | 5022 | 1 | Session ID | 5023 | | | 5024 | 2 | Network Layer Information | 5025 | | | 5026 | 3 | Stack Proposal | 5027 | | | 5028 | 4 | Stack Configuration Data | 5029 | | | 5030 | 5 | Query Cookie | 5031 | | | 5032 | 6 | Responder Cookie | 5033 | | | 5034 | 7 | NAT Traversal | 5035 | | | 5036 | 8 | NSLP Data | 5037 | | | 5038 | 9 | Error | 5039 | | | 5040 | 10 | Hello ID | 5041 +---------+-----------------------------+ 5043 Allocation policies for further values are as follows: 5045 10-1023: Standards Action 5047 1024-1999: Specification Required 5049 2000-2047: Private/Experimental Use 5051 2048-4095: Reserved - not to be allocated 5053 When a new object type is allocated according to one of the first 5054 two policies, the specification MUST provide the object format and 5055 define the setting of the extensibility bits (A/B, see 5056 Appendix A.2.1). 5058 Message Routing Methods: GIST allows multiple message routing 5059 methods (see Section 3.3). The MRM is indicated in the leading 5060 byte of the MRI object (Appendix A.3.1). This specification 5061 defines the following values: 5063 +------------+------------------------+ 5064 | MRM-ID | Message Routing Method | 5065 +------------+------------------------+ 5066 | 0 | Path Coupled MRM | 5067 | | | 5068 | 1 | Loose End MRM | 5069 +------------+------------------------+ 5071 Allocation policies for further values are as follows: 5073 2-63: Standards Action 5075 64-119: Expert Review 5077 120-127: Private/Experimental Use 5079 128-255: Reserved - not to be allocated 5081 When a new MRM is defined according to one of the first two 5082 policies, a specification document will be required. This MUST 5083 provide the information described in Section 3.3. 5085 MA-Protocol-IDs: Each protocol that can be used in a messaging 5086 association is identified by a 1-byte MA-Protocol-ID 5087 (Section 5.7). Note that the MA-Protocol-ID is not an IP Protocol 5088 number; indeed, some of the messaging association protocols - such 5089 as TLS - do not have an IP Protocol number. This is used as a tag 5090 in the Stack-Proposal and Stack-Configuration-Data objects 5091 (Appendix A.3.4 and Appendix A.3.5). The following values are 5092 defined by this specification: 5094 +---------------------+-----------------------------------------+ 5095 | MA-Protocol-ID | Protocol | 5096 +---------------------+-----------------------------------------+ 5097 | 0 | Reserved - not to be allocated | 5098 | | | 5099 | 1 | TCP opened in the forwards direction | 5100 | | | 5101 | 2 | TLS initiated in the forwards direction | 5102 +---------------------+-----------------------------------------+ 5104 Allocation policies for further values are as follows: 5106 3-63: Standards Action 5107 64-119: Expert Review 5109 120-127: Private/Experimental Use 5111 128-255: Reserved - not to be allocated 5113 When a new MA-Protocol-ID is allocated according to one of the 5114 first two policies, a specification document will be required. 5115 This MUST define the format for the MA-protocol-options field (if 5116 any) in the Stack-Configuration-Data object that is needed to 5117 define its configuration. If a protocol is to be used for 5118 reliable message transfer, it MUST be described how delivery 5119 errors are to be detected by GIST. Extensions to include new 5120 channel security protocols MUST include a description of how to 5121 integrate the functionality described in Section 3.9 with the rest 5122 of GIST operation. If the new MA-Protocol-ID can be used in 5123 conjunction with existing ones (for example, a new transport 5124 protocol which could be used with Transport Layer Security), the 5125 specification MUST define the interaction between the two. 5127 Error Codes/Subcodes: There is a 2 byte error code and 1 byte 5128 subcode in the Value field of the Error object (Appendix A.4.1). 5129 Error codes 1-12 are defined in Appendix A.4.4 together with 5130 subcodes 0-4 (code 1), 0-5 (code 9), 0-5 (code 10), and 0-2 (code 5131 12). Additional codes and subcodes are allocated on a first-come, 5132 first-served basis. When a new code/subcode combination is 5133 allocated, the following information MUST be provided: 5135 Error case: textual name of error 5137 Error class: from the categories given in Appendix A.4.3 5139 Error code: allocated by IANA, if a new code is required 5141 Error subcode: subcode point, also allocated by IANA 5143 Additional information: what additional information fields it is 5144 mandatory to include in the error message, from Appendix A.4.2 5146 Additional Information Types: An Error object (Appendix A.4.1) may 5147 contain Additional Information fields. Each possible field type 5148 is identified by a 16-bit AI-Type. AI-Types 1-4 are defined in 5149 Appendix A.4.2; additional AI-Types are allocated on a first-come, 5150 first-served basis. 5152 10. Acknowledgements 5154 This document is based on the discussions within the IETF NSIS 5155 working group. It has been informed by prior work and formal and 5156 informal inputs from: Cedric Aoun, Attila Bader, Vitor Bernado, 5157 Roland Bless, Bob Braden, Marcus Brunner, Benoit Campedel, Yoshiko 5158 Chong, Luis Cordeiro, Elwyn Davies, Michel Diaz, Christian Dickmann, 5159 Pasi Eronen, Alan Ford, Xiaoming Fu, Bo Gao, Ruediger Geib, Eleanor 5160 Hepworth, Thomas Herzog, Cheng Hong, Teemu Huovila, Jia Jia, Cornelia 5161 Kappler, Georgios Karagiannis, Ruud Klaver, Chris Lang, Lauri Liuhto, 5162 John Loughney, Allison Mankin, Jukka Manner, Pete McCann, Andrew 5163 McDonald, Glenn Morrow, Dave Oran, Andreas Pashalidis, Henning 5164 Peters, Tom Phelan, Akbar Rahman, Takako Sanda, Charles Shen, Melinda 5165 Shore, Martin Stiemerling, Martijn Swanink, Mike Thomas, Hannes 5166 Tschofenig, Sven van den Bosch, Nuutti Varis, Michael Welzl, Lars 5167 Westberg, and Mayi Zoumaro-djayoon. Parts of the TLS usage 5168 description (Section 5.7.3) were derived from the Diameter base 5169 protocol specification, RFC3588. In addition, Hannes Tschofenig 5170 provided a detailed set of review comments on the security section, 5171 and Andrew McDonald provided the formal description for the initial 5172 packet formats and the name matching algorithm for TLS. Chris Lang's 5173 implementation work provided objective feedback on the clarity and 5174 feasibility of the specification, and he also provided the state 5175 machine description and the initial error catalogue and formats. 5176 Magnus Westerlund carried out a detailed AD review which identified a 5177 number of issues and led to significant clarifications, which was 5178 followed by an even more detailed IESG review, with comments from 5179 Jari Arkko, Ross Callon, Brian Carpenter, Lisa Dusseault, Lars 5180 Eggert, Ted Hardie, Sam Hartman, Russ Housley, Cullen Jennings, and a 5181 very detailed analysis by Adrian Farrel from the Routing Area 5182 directorate. 5184 11. References 5186 11.1. Normative References 5188 [1] Braden, R., "Requirements for Internet Hosts - Communication 5189 Layers", STD 3, RFC 1122, October 1989. 5191 [2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 5192 June 1995. 5194 [3] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 5196 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 5197 Levels", BCP 14, RFC 2119, March 1997. 5199 [5] Schiller, J., "Cryptographic Algorithms for Use in the Internet 5200 Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005. 5202 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 5203 Considerations Section in RFCs", BCP 26, RFC 2434, 5204 October 1998. 5206 [7] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 5207 the Differentiated Services Field (DS Field) in the IPv4 and 5208 IPv6 Headers", RFC 2474, December 1998. 5210 [8] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 5211 RFC 2711, October 1999. 5213 [9] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 5214 RFC 2765, February 2000. 5216 [10] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 5217 Public Key Infrastructure Certificate and Certificate 5218 Revocation List (CRL) Profile", RFC 3280, April 2002. 5220 [11] Narten, T., "Assigning Experimental and Testing Numbers 5221 Considered Useful", BCP 82, RFC 3692, January 2004. 5223 [12] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 5224 Specifications: ABNF", RFC 4234, October 2005. 5226 [13] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 5227 Protocol Version 1.1", RFC 4346, April 2006. 5229 11.2. Informative References 5231 [14] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 5232 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 5233 Specification", RFC 2205, September 1997. 5235 [15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 5236 RFC 2246, January 1999. 5238 [16] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 5240 [17] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP 5241 Operation Over IP Tunnels", RFC 2746, January 2000. 5243 [18] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 5244 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 5246 [19] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 5247 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 5248 Paxson, "Stream Control Transmission Protocol", RFC 2960, 5249 October 2000. 5251 [20] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 5252 IPv4 Clouds", RFC 3056, February 2001. 5254 [21] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 5255 RFC 3068, June 2001. 5257 [22] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 5258 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 5259 September 2001. 5261 [23] Grossman, D., "New Terminology and Clarifications for 5262 Diffserv", RFC 3260, April 2002. 5264 [24] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 5265 Haukka, "Security Mechanism Agreement for the Session 5266 Initiation Protocol (SIP)", RFC 3329, January 2003. 5268 [25] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 5269 - Simple Traversal of User Datagram Protocol (UDP) Through 5270 Network Address Translators (NATs)", RFC 3489, March 2003. 5272 [26] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 5273 Underneath NAT (STUN)", draft-ietf-behave-turn-03 (work in 5274 progress), March 2007. 5276 [27] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 5277 Security Mechanism (GTSM)", RFC 3682, February 2004. 5279 [28] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, 5280 July 2004. 5282 [29] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 5283 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 5284 June 2005. 5286 [30] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 5287 Steps in Signaling (NSIS)", RFC 4081, June 2005. 5289 [31] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 5290 Requirements for Security", BCP 106, RFC 4086, June 2005. 5292 [32] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 5293 Transport Layer Security (TLS)", RFC 4279, December 2005. 5295 [33] Conta, A., Deering, S., and M. Gupta, "Internet Control Message 5296 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 5297 Specification", RFC 4443, March 2006. 5299 [34] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 5300 (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in progress), 5301 March 2007. 5303 [35] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 5304 IPv6 Hosts and Routers", RFC 4213, October 2005. 5306 [36] Kent, S. and K. Seo, "Security Architecture for the Internet 5307 Protocol", RFC 4301, December 2005. 5309 [37] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 5310 Nordmark, "Mobile IP Version 6 Route Optimization Security 5311 Design Background", RFC 4225, December 2005. 5313 [38] Audet, F. and C. Jennings, "Network Address Translation (NAT) 5314 Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, 5315 January 2007. 5317 [39] Floyd, S. and V. Jacobson, "The Synchronisation of Periodic 5318 Routing Messages", SIGCOMM Symposium on Communications 5319 Architectures and Protocols pp. 33--44, September 1993. 5321 [40] Pashalidis, A. and H. Tschofenig, "GIST Legacy NAT Traversal", 5322 draft-pashalidis-nsis-gist-legacynats-01 (work in progress), 5323 March 2007. 5325 [41] Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal", 5326 draft-pashalidis-nsis-gimps-nattraversal-04 (work in progress), 5327 March 2007. 5329 [42] Tschofenig, H., "GIST State Machine", 5330 draft-ietf-nsis-ntlp-statemachine-03 (work in progress), 5331 March 2007. 5333 [43] Ramaiah, A., "Improving TCP's Robustness to Blind In-Window 5334 Attacks", draft-ietf-tcpm-tcpsecure-07 (work in progress), 5335 February 2007. 5337 Appendix A. Bit-Level Formats and Error Messages 5339 This appendix provides formats for the various component parts of the 5340 GIST messages defined abstractly in Section 5.2. The whole of this 5341 appendix is normative. 5343 Each GIST message consists of a header and a sequence of objects. 5344 The GIST header has a specific format, described in more detail in 5345 Appendix A.1 below. An NSLP message is one object within a GIST 5346 message. Note that GIST itself provides the NSLP message length 5347 information and signalling application identification. General 5348 object formatting guidelines are provided in Appendix A.2 below, 5349 followed in Appendix A.3 by the format for each object. Finally, 5350 Appendix A.4 provides the formats used for error reporting. 5352 In the following object diagrams, '//' is used to indicate a variable 5353 sized field and ':' is used to indicate a field that is optionally 5354 present. 5356 A.1. The GIST Common Header 5358 This header begins all GIST messages. It has a fixed format, as 5359 shown below. 5361 0 1 2 3 5362 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 5363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5364 | Version | GIST hops | Message Length | 5365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5366 | NSLPID | Type |S|R|E| Reserved| 5367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5369 Version (8 bits): The GIST protocol version number. 5371 GIST hops (8 bits): A hop count for the number of GIST-aware nodes 5372 this message can still be processed by (including the 5373 destination). 5375 Message Length (16 bits): The total number of 32-bit words in the 5376 message after the common header itself. 5378 NSLPID (16 bits): IANA assigned identifier of the signalling 5379 application the message refers to. 5381 Type (8 bits): The GIST message type (Query, Response, etc.). 5383 S flag: S=1 if the IP source address is the same as the signalling 5384 source address, S=0 if it is different. 5386 R flag: R=1 if a reply to this message is explicitly requested. 5388 E flag: E=1 if the message was explicitly routed (Section 7.1.5). 5390 The rules governing the use of the R-flag depend on the GIST message 5391 type. It MUST always be set (R=1) in Query messages, since these 5392 always elicit a Response, and never in Confirm, Data or Error 5393 messages. It MAY be set in an MA-Hello; if set, another MA-Hello 5394 MUST be sent in reply. It MAY be set in a Response, but MUST be set 5395 if the Response contains a Responder cookie; if set, a Confirm MUST 5396 be sent in reply. The E flag MUST NOT be set unless the message type 5397 is a Data message. 5399 Parsing failures may be caused by unknown Version or Type values, 5400 inconsistent R or E flag setting, or a Message Length inconsistent 5401 with the set of objects carried. In all cases the receiver MUST if 5402 possible return a "Common Header Parse Error" message 5403 (Appendix A.4.4.1) with the appropriate subcode, and not process the 5404 message further. 5406 A.2. General Object Format 5408 Each object begins with a fixed header giving the object Type and 5409 object Length. This is followed by the object Value, which is a 5410 whole number of 32-bit words long. 5412 0 1 2 3 5413 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 5414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5415 |A|B|r|r| Type |r|r|r|r| Length | 5416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5417 // Value // 5418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5420 A/B flags: The bits marked 'A' and 'B' are extensibility flags which 5421 are defined in Appendix A.2.1 below; the remaining bits marked 'r' 5422 are reserved. 5424 Type (12 bits): An IANA-assigned identifier for the type of object. 5426 Length (12 bits): Length has the units of 32-bit words, and measures 5427 the length of Value. If there is no Value, Length=0. If the 5428 Length is not consistent with the contents of the object, an 5429 "Object Value Error" message (Appendix A.4.4.10) with subcode 0 5430 "Incorrect Length" MUST be returned and the message dropped. 5432 Value (variable): Value is (therefore) a whole number of 32 bit 5433 words. If there is any padding required, the length and location 5434 are be defined by the object-specific format information; objects 5435 which contain variable length (e.g. string) types may need to 5436 include additional length subfields to do so. 5438 Any part of the object used for padding or defined as reserved 5439 (marked 'Reserved' or 'Rsv' or, in the case of individual bits, 'r' 5440 in the diagrams below) MUST be set to 0 on transmission and MUST be 5441 ignored on reception. 5443 A.2.1. Object Extensibility 5445 The leading two bits of the TLV header are used to signal the desired 5446 treatment for objects whose Type field is unknown at the receiver. 5447 The following three categories of object have been identified, and 5448 are described here. 5450 AB=00 ("Mandatory"): If the object is not understood, the entire 5451 message containing it MUST be rejected with an "Object Type Error" 5452 message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object"). 5454 AB=01 ("Ignore"): If the object is not understood, it MUST be 5455 deleted and the rest of the message processed as usual. 5457 AB=10 ("Forward"): If the object is not understood, it MUST be 5458 retained unchanged in any message forwarded as a result of message 5459 processing, but not stored locally. 5461 The combination AB=11 is reserved. If a message is received 5462 containing an object with AB=11, it MUST be rejected with an "Object 5463 Type Error" message (Appendix A.4.4.9) with subcode 5 ("Invalid 5464 Extensibility Flags"). 5466 These extensibility rules define only the processing within the GIST 5467 layer. There is no requirement on GIST implementations to support an 5468 extensible service interface to signalling applications, so 5469 unrecognised objects with AB=01 or AB=10 do not need to be indicated 5470 to NSLPs. 5472 A.3. GIST TLV Objects 5474 A.3.1. Message-Routing-Information 5475 Type: Message-Routing-Information 5477 Length: Variable (depends on MRM) 5479 0 1 2 3 5480 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 5481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5482 | MRM-ID |N| Reserved | | 5483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 5484 // Method-specific addressing information (variable) // 5485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5487 MRM-ID (8 bits): An IANA-assigned identifier for the message routing 5488 method. 5490 N flag: If set (N=1), this means that NATs do not need to translate 5491 this MRM; if clear (N=0) it means that the method-specific 5492 information contains network or transport layer information that a 5493 NAT must process. 5495 The remainder of the object contains method-specific addressing 5496 information, which is described below. 5498 A.3.1.1. Path-Coupled MRM 5500 In the case of basic path-coupled routing, the addressing information 5501 takes the following format. The N-flag N=0 for this MRM. 5503 0 1 2 3 5504 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 5505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5506 |IP-Ver |P|T|F|S|A|B|D|Reserved | 5507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5508 // Source Address // 5509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5510 // Destination Address // 5511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5512 | Source Prefix | Dest Prefix | Protocol | DS-field |Rsv| 5513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5514 : Reserved | Flow Label : 5515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5516 : SPI : 5517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5518 : Source Port : Destination Port : 5519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5520 IP-Ver (4 bits): The IP version number, 4 or 6. 5522 Source/Destination address (variable): The source and destination 5523 addresses are always present and of the same type; their length 5524 depends on the value in the IP-Ver field. 5526 Source/Dest Prefix (each 8 bits): The length of the mask to be 5527 applied to the source and destination addresses for address 5528 wildcarding. In the normal case where the MRI refers only to 5529 traffic between specific host addresses, the Source/Dest Prefix 5530 values would both be 32/128 for IPv4/6 respectively. 5532 P flag: P=1 means that the Protocol field is significant. 5534 Protocol (8 bits): The IP protocol number. This MUST be ignored if 5535 P=0. In the case of IPv6, the Protocol field refers to the true 5536 upper layer protocol carried by the packets, i.e. excluding any IP 5537 option headers. This is therefore not necessarily the same as the 5538 Next Header value from the base IPv6 header. 5540 T flag: T=1 means that the DiffServ field (DS-field) is significant. 5542 DS-field (6 bits): The DiffServ field. See [7] and [23]. 5544 F flag: F=1 means that flow label is present and is significant. F 5545 MUST NOT be set if IP-Ver is not 6. 5547 Flow Label (20 bits): The flow label; only present if F=1. If F=0, 5548 the entire 32 bit word containing the Flow Label is absent. 5550 S flag: S=1 means that the SPI field is present and is significant. 5551 The S flag MUST be 0 if the P flag is 0. 5553 SPI field (32 bits): The SPI field; see [36]. If S=0, the entire 32 5554 bit word containing the SPI is absent. 5556 A/B flags: These can only be set if P=1. If either is set, the port 5557 fields are also present. If P=0, the A/B flags MUST both be zero 5558 and the word containing the port numbers is absent. 5560 Source/Destination Port (each 16 bits): If either of A (source), B 5561 (destination) is set the word containing the port numbers is 5562 included in the object. However, the contents of each field is 5563 only significant if the corresponding flag is set; otherwise, the 5564 contents of the field is regarded as padding, and the MRI refers 5565 to all ports (i.e. acts as a wildcard). If the flag is set and 5566 Port=0x0000, the MRI will apply to a specific port, whose value is 5567 not yet known. If neither of A or B is set, the word is absent. 5569 D flag: The Direction flag has the following meaning: the value 0 5570 means 'in the same direction as the flow' (i.e. downstream), and 5571 the value 1 means 'in the opposite direction to the flow' (i.e. 5572 upstream). 5574 The MRI format defines a number of constraints on the allowed 5575 combinations of flags and fields in the object. If these constraints 5576 are violated this constitutes a parse error, and an "Object Value 5577 Error" message (Appendix A.4.4.10) with subcode 2 ("Invalid Flag- 5578 Field Combination") MUST be returned. 5580 A.3.1.2. Loose-End MRM 5582 In the case of the loose-end MRM, the addressing information takes 5583 the following format. The N-flag N=0 for this MRM. 5585 0 1 2 3 5586 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 5587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5588 |IP-Ver |D| Reserved | 5589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5590 // Source Address // 5591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5592 // Destination Address // 5593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5595 IP-Ver (4 bits): The IP version number, 4 or 6. 5597 Source/Destination address (variable): The source and destination 5598 addresses are always present and of the same type; their length 5599 depends on the value in the IP-Ver field. 5601 D flag: The Direction flag has the following meaning: the value 0 5602 means 'towards the edge of the network', and the value 1 means 5603 'from the edge of the network'. Note that for Q-mode messages, 5604 the only valid value is D=0 (see Section 5.8.2). 5606 A.3.2. Session Identification 5608 Type: Session-Identification 5610 Length: Fixed (4 32-bit words) 5611 0 1 2 3 5612 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 5613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5614 | | 5615 + + 5616 | | 5617 + Session ID + 5618 | | 5619 + + 5620 | | 5621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5623 A.3.3. Network-Layer-Information 5625 Type: Network-Layer-Information 5627 Length: Variable (depends on length of Peer-Identity and IP version) 5629 0 1 2 3 5630 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 5631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5632 | PI-Length | IP-TTL |IP-Ver | Reserved | 5633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5634 | Routing State Validity Time | 5635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5636 // Peer Identity // 5637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5638 // Interface Address // 5639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5641 PI-Length (8 bits): The byte length of the Peer Identity field. 5643 Peer Identity (variable): The Peer Identity field. Note that the 5644 Peer-Identity field itself is padded to a whole number of words. 5646 IP-TTL (8 bits): Initial or reported IP layer TTL. 5648 IP-Ver (4 bits): The IP version for the Interface Address field. 5650 Interface Address (variable): The IP address allocated to the 5651 interface, matching the IP-Ver field. 5653 Routing State Validity Time (32 bits): The time for which the 5654 routing state for this flow can be considered correct without a 5655 refresh. Given in milliseconds. The value 0 (zero) is reserved 5656 and MUST NOT be used. 5658 A.3.4. Stack Proposal 5660 Type: Stack-Proposal 5662 Length: Variable (depends on number of profiles and size of each 5663 profile) 5665 0 1 2 3 5666 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 5667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5668 | Prof-Count | Reserved | 5669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5670 // Profile 1 // 5671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5672 : : 5673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5674 // Profile N // 5675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5676 Prof-Count (8 bits): The number of profiles listed. MUST be > 0. 5678 Each profile is itself a sequence of protocol layers, and the profile 5679 is formatted as a list as follows: 5681 o The first byte is a count of the number of layers in the profile. 5682 MUST be > 0. 5684 o This is followed by a sequence of 1-byte MA-Protocol-IDs as 5685 described in Section 5.7. 5687 o The profile is padded to a word boundary with 0, 1, 2 or 3 zero 5688 bytes. These bytes MUST be ignored at the receiver. 5690 If there are no profiles (Prof-Count=0) then an "Object Value Error" 5691 message (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") 5692 MUST be returned; if a particular profile is empty (the leading byte 5693 of the profile is zero), then subcode 3 ("Empty List") MUST be used. 5694 In both cases, the message MUST be dropped. 5696 A.3.5. Stack-Configuration-Data 5698 Type: Stack-Configuration-Data 5700 Length: Variable (depends on number of protocols and size of each 5701 MA-protocol-options field) 5703 0 1 2 3 5704 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 5705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5706 | MPO-Count | Reserved | 5707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5708 | MA-Hold-Time | 5709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5710 // MA-protocol-options 1 // 5711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5712 : : 5713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5714 // MA-protocol-options N // 5715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5717 MPO-Count (8 bits): The number of MA-protocol-options fields present 5718 (these contain their own length information). The MPO-Count MAY 5719 be zero, but this will only be the case if none of the MA- 5720 protocols referred to in the Stack-Proposal require option data. 5722 MA-Hold-Time (32 bits): The time for which the messaging association 5723 will be held open without traffic or a hello message. Note that 5724 this value is given in milliseconds, so the default time of 30 5725 seconds (Section 4.4.5) corresponds to a value of 30000. The 5726 value 0 (zero) is reserved and MUST NOT be used. 5728 The MA-protocol-options fields are formatted as follows: 5730 0 1 2 3 5731 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 5732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5733 |MA-Protocol-ID | Profile | Length |D| Reserved | 5734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5735 // Options Data // 5736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5738 MA-Protocol-ID (8 bits): Protocol identifier as described in 5739 Section 5.7. 5741 Profile (8 bits): Tag indicating which profile from the accompanying 5742 Stack-Proposal object this applies to. Profiles are numbered from 5743 1 upwards; the special value 0 indicates 'applies to all 5744 profiles'. 5746 Length (8 bits): The byte length of MA-protocol-options field that 5747 follows. This will be zero-padded up to the next word boundary. 5749 D flag: If set (D=1), this protocol MUST NOT be used for a messaging 5750 association. 5752 Options Data (variable): Any options data for this protocol. Note 5753 that the format of the options data might differ depending on 5754 whether the field is in a Query or Response. 5756 A.3.6. Query Cookie 5758 Type: Query-Cookie 5760 Length: Variable (selected by querying node) 5762 0 1 2 3 5763 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 5764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5765 // Query Cookie // 5766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5768 The contents are implementation defined. See Section 8.5 for further 5769 discussion. 5771 A.3.7. Responder Cookie 5773 Type: Responder-Cookie 5775 Length: Variable (selected by responding node) 5777 0 1 2 3 5778 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 5779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5780 // Responder Cookie // 5781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5783 The contents are implementation defined. See Section 8.5 for further 5784 discussion. 5786 A.3.8. Hello-ID 5788 Type: Hello-ID 5790 Length: Fixed (1 32-bit word) 5791 0 1 2 3 5792 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 5793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5794 | Hello-ID | 5795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5797 The contents are implementation defined. See Section 5.2.2 for 5798 further discussion. 5800 A.3.9. NAT Traversal 5802 Type: NAT-Traversal 5804 Length: Variable (depends on length of contained fields) 5806 This object is used to support the NAT traversal mechanisms described 5807 in Section 7.2.2. 5809 0 1 2 3 5810 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 5811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5812 | MRI-Length | Type-Count | NAT-Count | Reserved | 5813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5814 // Original Message-Routing-Information // 5815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5816 // List of translated objects // 5817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5818 | Length of opaque information | | 5819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 5820 // Information replaced by NAT #1 | 5821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5822 : : 5823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5824 | Length of opaque information | | 5825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 5826 // Information replaced by NAT #N | 5827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5829 MRI-Length (8 bits): The length of the included MRI payload in 32- 5830 bit words. 5832 Original Message-Routing-Information (variable): The MRI data from 5833 when the message was first sent, not including the object header. 5835 Type-Count (8 bits): The number of objects in the 'List of 5836 translated objects' field. 5838 List of translated objects (variable): This field lists the types of 5839 the objects that were translated by every NAT through which the 5840 message has passed. Each element in the list is a 16-bit field 5841 containing the first 16 bits of the object TLV header, including 5842 the AB extensibility flags, two reserved bits, and 12 bit object 5843 type. The list is initialised by the first NAT on the path; 5844 subsequent NATs may delete elements in the list. Padded with 2 5845 null bytes if necessary. 5847 NAT-Count (8 bits): The number of NATs traversed by the message, and 5848 the number of opaque payloads at the end of the object. The 5849 length fields for each opaque payload are byte counts, not 5850 including the 2 bytes of the length field itself. Note that each 5851 opaque information field is zero-padded to the next 32-bit word 5852 boundary if necessary. 5854 A.3.10. NSLP Data 5856 Type: NSLP-Data 5858 Length: Variable (depends on NSLP) 5860 This object is used to deliver data between NSLPs. GIST regards the 5861 data as a number of complete 32-bit words, as given by the length 5862 field in the TLV; any padding to a word boundary must be carried out 5863 within the NSLP itself. 5865 0 1 2 3 5866 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 5867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5868 // NSLP Data // 5869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5871 A.4. Errors 5873 A.4.1. Error Object 5875 Type: Error 5877 Length: Variable (depends on error) 5878 0 1 2 3 5879 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 5880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5881 | Error Class | Error Code | Error Subcode | 5882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5883 |S|M|C|D|Q| Reserved | MRI Length | Info Count | 5884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5885 | | 5886 + Common Header + 5887 | (of original message) | 5888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5889 : Session Id : 5890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5891 : Message Routing Information : 5892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5893 : Additional Information Fields : 5894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5895 : Debugging Comment : 5896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5898 The flags are: 5899 S - S=1 means the Session ID object is present 5900 M - M=1 means MRI object is present 5901 C - C=1 means a debug Comment is present after header. 5902 D - D=1 means the original message was received in D-mode 5903 Q - Q=1 means the original message was received Q-mode encapsulated 5904 (can't be set if D=0). 5906 A GIST Error object contains an 8 bit error-class (see 5907 Appendix A.4.3), a 16 bit error-code, an 8 bit error-subcode, and as 5908 much information about the message which triggered the error as is 5909 available. This information MUST include the Common header of the 5910 original message and MUST also include the Session Id and MRI objects 5911 if these could be decoded correctly. These objects are included in 5912 their entirety, except for their TLV Headers. The MRI Length field 5913 gives the length of the MRI object in 32-bit words. 5915 The Info Count field contains the number of Additional Information 5916 fields in the object, and the possible formats for these fields are 5917 given in Appendix A.4.2. The precise set of fields to include 5918 depends on the error code/subcode. For every error description in 5919 the error catalogue Appendix A.4.4, the line "Additional Info:" 5920 states what fields MUST be included; further fields beyond these MAY 5921 be included by the sender, and the fields may be included in any 5922 order. The Debugging Comment is a null- terminated UTF-8 string, 5923 padded if necessary to a whole number of 32- bit words with more null 5924 characters. 5926 A.4.2. Additional Information Fields 5928 The Common Error Header may be followed by some Additional 5929 Information fields. Each Additional Information field has a simple 5930 TLV format as follows: 5931 0 1 2 3 5932 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 5933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5934 | AI-Type | AI-Length | 5935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5936 // AI-Value // 5937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5939 The AI-Type is a 16-bit IANA assigned value. The AI-Length gives the 5940 number of 32-bit words in AI-Value; if an AI-Value is not present, 5941 AI-Length=0. The AI-Types and AI-Lengths and AI-Value formats of the 5942 currently defined Additional Information fields are shown below. 5944 Message Length Info: 5945 0 1 2 3 5946 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 5947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5948 | Calculated Length | Reserved | 5949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5950 AI-Type: 1 5951 AI-Length: 1 5952 Calculated Length (16 bits): the length of the original message 5953 calculated by adding up all the objects in the message. Measured in 5954 32-bit words. 5956 MTU Info: 5957 0 1 2 3 5958 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 5959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5960 | Link MTU | Reserved | 5961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5962 AI-Type: 2 5963 AI-Length: 1 5964 Link MTU (16 bits): the IP MTU for a link along which a message 5965 could not be sent. Measured in bytes. 5967 Object Type Info: 5969 0 1 2 3 5970 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 5971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5972 | Object Type | Reserved | 5973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5974 AI-Type: 3 5975 AI-Length: 1 5976 Object type (16 bits): This provides information about the type 5977 of object which caused the error. 5979 Object Value Info: 5980 0 1 2 3 5981 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 5982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5983 | Rsv | Real Object Length | Offset | 5984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5985 // Object // 5986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5987 AI-Type: 4 5988 AI-Length: variable (depends on Object length) 5989 This object carries information about a TLV object which was found 5990 to be invalid in the original message. An error message MAY contain 5991 more than one Object Value Info object. 5993 Real Object Length (12 bits) Since the length in the original TLV 5994 header may be inaccurate, this field provides the actual length of 5995 the object (including the TLV Header) included in the error 5996 message. Measured in 32-bit words. 5998 Offset (16 bits): The byte in the object at which the GIST node 5999 found the error. The first byte in the object has offset=0. 6001 Object (variable): The invalid TLV object (including the TLV 6002 Header). 6004 A.4.3. Error Classes 6006 The first byte of the error object, "Error Class", indicates the 6007 severity level. The currently defined severity levels are: 6009 0 (Informational): reply data which should not be thought of as 6010 changing the condition of the protocol state machine. 6012 1 (Success): reply data which indicates that the message being 6013 responded to has been processed successfully in some sense. 6015 2 (Protocol-Error): the message has been rejected because of a 6016 protocol error (e.g. an error in message format). 6018 3 (Transient-Failure): the message has been rejected because of a 6019 particular local node status which may be transient (i.e. it may 6020 be worthwhile to retry after some delay). 6022 4 (Permanent-Failure): the message has been rejected because of 6023 local node status which will not change without additional out of 6024 band (e.g. management) operations. 6026 Additional error class values are reserved. 6028 The allocation of error classes to particular errors is not precise; 6029 the above descriptions are deliberately informal. Actual error 6030 processing SHOULD take into account the specific error in question; 6031 the error class may be useful supporting information (e.g. in network 6032 debugging). 6034 A.4.4. Error Catalogue 6036 This section lists all the possible GIST errors, including when they 6037 are raised and what additional information fields MUST be carried in 6038 the error object. 6040 A.4.4.1. Common Header Parse Error 6042 Class: Protocol-Error 6043 Code: 1 6044 Additional Info: For subcode 3 only, Message Length Info carries 6045 the calculated message length. 6047 This message is sent if a GIST node receives a message where the 6048 common header cannot be parsed correctly, or where an error in the 6049 overall message format is detected. Note that in this case the 6050 original MRI and Session ID MUST NOT be included in the Error Object. 6051 This error code is split into subcodes as follows: 6053 0: Unknown Version: The GIST version is unknown. The (highest) 6054 supported version supported by the node can be inferred from the 6055 Common Header of the Error message itself. 6057 1: Unknown Type: The GIST message type is unknown. 6059 2: Invalid R-flag: The R flag in the header is inconsistent with the 6060 message type. 6062 3: Incorrect Message Length: The overall message length is not 6063 consistent with the set of objects carried. 6065 4: Invalid E-flag: The E flag is set in the header but this is not a 6066 Data message. 6068 A.4.4.2. Hop Limit Exceeded 6070 Class: Permanent-Failure 6071 Code: 2 6072 Additional Info: None 6074 This message is sent if a GIST node receives a message with a GIST 6075 hop count of zero, or a GIST node tries to forward a message after 6076 its GIST hop count has been decremented to zero on reception. This 6077 message indicates either a routing loop or too small an initial hop 6078 count value. 6080 A.4.4.3. Incorrect Encapsulation 6082 Class: Protocol-Error 6083 Code: 3 6084 Additional Info: None 6086 This message is sent if a GIST node receives a message which uses an 6087 incorrect encapsulation method (e.g. a Query arrives over an MA). 6089 A.4.4.4. Incorrectly Delivered Message 6091 Class: Protocol-Error 6092 Code: 4 6093 Additional Info: None 6095 This message is sent if a GIST node receives a message over an MA 6096 which is not associated with the MRI/NSLPID/SID combination in the 6097 message. 6099 A.4.4.5. No Routing State 6101 Class: Protocol-Error 6102 Code: 5 6103 Additional Info: None 6105 This message is sent if a node receives a message for which routing 6106 state should exist, but has not yet been created and thus there is no 6107 appropriate Querying-SM or Responding-SM. This can occur on 6108 receiving a Data or Confirm message at a node whose policy requires 6109 routing state to exist before such messages can be accepted. See 6110 also Section 6.1 and Section 6.3. 6112 A.4.4.6. Unknown NSLPID 6114 Class: Permanent-Failure 6115 Code: 6 6116 Additional Info: None 6118 This message is sent if a router receives a directly addressed 6119 message for an NSLP which it does not support. 6121 A.4.4.7. Endpoint Found 6123 Class: Permanent-Failure 6124 Code: 7 6125 Additional Info: None 6127 This message is sent if a GIST node at a flow endpoint receives a 6128 Query message for an NSLP which it does not support. 6130 A.4.4.8. Message Too Large 6132 Class: Permanent-Failure 6133 Code: 8 6134 Additional Info: MTU Info 6136 A router receives a message which it can't forward because it exceeds 6137 the IP MTU on the next or subsequent hops. 6139 A.4.4.9. Object Type Error 6141 Class: Protocol-Error 6142 Code: 9 6143 Additional Info: Object Type Info 6145 This message is sent if a GIST node receives a message containing a 6146 TLV object with an invalid type. The message indicates the object 6147 type at fault in the additional info field. This error code is split 6148 into subcodes as follows: 6150 0: Duplicate Object: This subcode is used if a GIST node receives a 6151 message containing multiple instances of an object which may only 6152 appear once in a message. In the current specification, this 6153 applies to all objects. 6155 1: Unrecognised Object: This subcode is used if a GIST node receives 6156 a message containing an object which it does not support, and the 6157 extensibility flags AB=00. 6159 2: Missing Object: This subcode is used if a GIST node receives a 6160 message which is missing one or more mandatory objects. This 6161 message is also sent if a Stack-Proposal is sent without a 6162 matching Stack-Configuration-Data object when one was necessary, 6163 or vice versa. 6165 3: Invalid Object Type: This subcode is used if the object type is 6166 known, but it is not valid for this particular GIST message type. 6168 4: Untranslated Object: This subcode is used if the object type is 6169 known and is mandatory to interpret, but it contains addressing 6170 data which has not been translated by an intervening NAT. 6172 5: Invalid Extensibility Flags: This subcode is used if an object is 6173 received with the extensibility flags AB=11. 6175 A.4.4.10. Object Value Error 6177 Class: Protocol-Error 6178 Code: 10 6179 Additional Info: 1 or 2 Object Value Info fields as given below 6181 This message is sent if a node receives a message containing an 6182 object which cannot be properly parsed. The error message contains a 6183 single Object Value Info object, except for subcode 5 as stated 6184 below. This error code is split into subcodes as follows: 6186 0: Incorrect Length: The overall length does not match the object 6187 length calculated from the object contents. 6189 1: Value Not Supported: The value of a field is not supported by the 6190 GIST node. 6192 2: Invalid Flag-Field Combination: An object contains an invalid 6193 combination of flags and/or fields. At the moment this only 6194 relates to the Path-Coupled MRI (Appendix A.3.1.1), but in future 6195 there may be more. 6197 3: Empty List: At the moment this only relates to Stack-Proposals. 6198 The error message is sent if a stack proposal with a length > 0 6199 contains only null bytes (a length of 0 is handled as "Value Not 6200 Supported"). 6202 4: Invalid Cookie: The message contains a cookie which could not be 6203 verified by the node. 6205 5: Stack-Proposal - Stack-Configuration-Data Mismatch: This subcode 6206 is used if a GIST node receives a message in which the data in the 6207 Stack-Proposal object is inconsistent with the information in the 6208 Stack Configuration Data object. In this case, both the Stack- 6209 Proposal object and Stack-Configuration-Data object MUST be 6210 included in separate Object Value Info fields in that order. 6212 A.4.4.11. Invalid IP layer TTL 6214 Class: Permanent-Failure 6215 Code: 11 6216 Additional Info: None 6218 This error indicates that a message was received with an IP layer TTL 6219 outside an acceptable range; for example, that an upstream Query was 6220 received with an IP layer TTL of less than 254 (i.e. more than one IP 6221 hop from the sender). The actual IP distance can be derived from the 6222 IP-TTL information in the NLI object carried in the same message. 6224 A.4.4.12. MRI Validation Failure 6226 Class: Permanent-Failure 6227 Code: 12 6228 Additional Info: Object Value Info 6230 This error indicates that a message was received with an MRI that 6231 could not be accepted, e.g. because of too much wildcarding or 6232 failing some validation check (cf. Section 5.8.1.2). The Object 6233 Value Info includes the MRI so the error originator can indicate the 6234 part of the MRI which caused the problem. The error code is divided 6235 into subcodes as follows: 6237 0: MRI Too Wild: The MRI contained too much wildcarding (e.g. too 6238 short a destination address prefix) to be forwarded correctly down 6239 a single path. 6241 1: IP Version Mismatch: The MRI in a path-coupled Query message 6242 refers to an IP version which is not implemented on the interface 6243 used, or is different from the IP version of the Query 6244 encapsulation (see Section 7.4). 6246 2: Ingress Filter Failure: The MRI in a path-coupled Query message 6247 describes a flow which would not pass ingress filtering on the 6248 interface used. 6250 Appendix B. API between GIST and Signalling Applications 6252 This appendix provides an abstract API between GIST and signalling 6253 applications. It should not constrain implementers, but rather help 6254 clarify the interface between the different layers of the NSIS 6255 protocol suite. In addition, although some of the data types carry 6256 the information from GIST information elements, this does not imply 6257 that the format of that data as sent over the API has to be the same. 6259 Conceptually the API has similarities to the sockets API, 6260 particularly that for unconnected UDP sockets. An extension for an 6261 API like that for UDP connected sockets could be considered. In this 6262 case, for example, the only information needed in a SendMessage 6263 primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle 6264 (which can be null). Other information which was persistent for a 6265 group of messages could be configured once for the socket. Such 6266 extensions may make a concrete implementation more efficient but do 6267 not change the API semantics, and so are not considered further here. 6269 B.1. SendMessage 6271 This primitive is passed from a signalling application to GIST. It 6272 is used whenever the signalling application wants to initiate sending 6273 a message. 6275 SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, 6276 NSLPID, Session-ID, MRI, SII-Handle, 6277 Transfer-Attributes, Timeout, IP-TTL, GIST-Hop-Count ) 6279 The following arguments are mandatory. 6281 NSLP-Data: The NSLP message itself. 6283 NSLP-Data-Size: The length of NSLP-Data. 6285 NSLP-Message-Handle: A handle for this message, that can be used by 6286 GIST as a reference in subsequent MessageStatus notifications 6287 (Appendix B.3). Notifications could be about error conditions or 6288 about the security attributes that will be used for the message. 6289 A NULL handle may be supplied if the NSLP is not interested in 6290 such notifications. 6292 NSLPID: An identifier indicating which NSLP this is. 6294 Session-ID: The NSIS session identifier. Note that it is assumed 6295 that the signalling application provides this to GIST rather than 6296 GIST providing a value itself. 6298 MRI: Message routing information for use by GIST in determining the 6299 correct next GIST hop for this message. The MRI implies the 6300 message routing method to be used and the message direction. 6302 The following arguments are optional: 6304 SII-Handle: A handle, previously supplied by GIST, to a data 6305 structure that should be used to route the message explicitly to a 6306 particular GIST next hop. 6308 Transfer-Attributes: Attributes defining how the message should be 6309 handled (see Section 4.1.2). The following attributes can be 6310 considered: 6312 Reliability: Values 'unreliable' or 'reliable'. 6314 Security: This attribute allows the NSLP to specify what level of 6315 security protection is requested for the message (such as 6316 'integrity' or 'confidentiality'), and can also be used to 6317 specify what authenticated signalling source and destination 6318 identities should be used to send the message. The 6319 possibilities can be learned by the signalling application from 6320 prior MessageStatus or RecvMessage notifications. If an NSLP- 6321 Message-Handle is provided, GIST will inform the signalling 6322 application of what values it has actually chosen for this 6323 attribute via a MessageStatus callback. This might take place 6324 either synchronously (where GIST is selecting from available 6325 messaging associations), or asynchronously (when a new 6326 messaging association needs to be created). 6328 Local Processing: This attribute contains hints from the 6329 signalling application about what local policy should be 6330 applied to the message; in particular, its transmission 6331 priority relative to other messages, or whether GIST should 6332 attempt to set up or maintain forward routing state. 6334 Timeout: Length of time GIST should attempt to send this message 6335 before indicating an error. 6337 IP-TTL: The value of the IP layer TTL that should be used when 6338 sending this message (may be overridden by GIST for particular 6339 messages). 6341 GIST-Hop-Count: The value for the hop count when sending the 6342 message. 6344 B.2. RecvMessage 6346 This primitive is passed from GIST to a signalling application. It 6347 is used whenever GIST receives a message from the network, including 6348 the case of null messages (zero length NSLP payload), typically 6349 initial Query messages. For Queries, the results of invoking this 6350 primitive are used by GIST to check whether message routing state 6351 should be created (see the discussion of the 'Routing-State-Check' 6352 argument below). 6354 RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLPID, Session-ID, MRI, 6355 Routing-State-Check, SII-Handle, Transfer-Attributes, 6356 IP-TTL, IP-Distance, GIST-Hop-Count, 6357 Inbound-Interface ) 6359 NSLP-Data: The NSLP message itself (may be empty). 6361 NSLP-Data-Size: The length of NSLP-Data (may be zero). 6363 NSLPID: An identifier indicating which NSLP this message is for. 6365 Session-ID: The NSIS session identifier. 6367 MRI: Message routing information that was used by GIST in forwarding 6368 this message. Implicitly defines the message routing method that 6369 was used and the direction of the message relative to the MRI. 6371 Routing-State-Check: This boolean is True if GIST is checking with 6372 the signalling application to see if routing state should be 6373 created with the peer or the message should be forwarded further 6374 (see Section 4.3.2). If True, the signalling application should 6375 return the following values via the RecvMessage call: 6377 A boolean indicating whether to set up the state. 6379 Optionally, an NSLP-Payload to carry in the generated Response 6380 or forwarded Query respectively. 6382 This mechanism could be extended to enable the signalling 6383 application to indicate to GIST whether state installation should 6384 be immediate or deferred (see Section 5.3.3 and Section 6.3 for 6385 further discussion). 6387 SII-Handle: A handle to a data structure, identifying a peer address 6388 and interface. Can be used to identify route changes and for 6389 explicit routing to a particular GIST next hop. 6391 Transfer-Attributes: The reliability and security attributes that 6392 were associated with the reception of this particular message. As 6393 well as the attributes associated with SendMessage, GIST may 6394 indicate the level of verification of the addresses in the MRI. 6395 Three attributes can be indicated: 6397 * Whether the signalling source address is one of the flow 6398 endpoints (i.e. whether this is the first or last GIST hop); 6400 * Whether the signalling source address has been validated by a 6401 return routability check. 6403 * Whether the message was explicitly routed (and so has not been 6404 validated by GIST as delivered consistently with local routing 6405 state). 6407 IP-TTL: The value of the IP layer TTL this message was received with 6408 (if available). 6410 IP-Distance: The number of IP hops from the peer signalling node 6411 which sent this message along the path, or 0 if this information 6412 is not available. 6414 GIST-Hop-Count: The value of the hop count the message was received 6415 with, after being decremented in the GIST receive-side processing. 6417 Inbound-Interface: Attributes of the interface on which the message 6418 was received, such as whether it lies on the internal or external 6419 side of a NAT. These attributes have only local significance and 6420 are implementation defined. 6422 B.3. MessageStatus 6424 This primitive is passed from GIST to a signalling application. It 6425 is used to notify the signalling application that a message that it 6426 requested to be sent could not be dispatched, or to inform the 6427 signalling application about the transfer attributes that have been 6428 selected for the message (specifically, security attributes). The 6429 signalling application can respond to this message with a return code 6430 to abort the sending of the message if the attributes are not 6431 acceptable. 6433 MessageStatus (NSLP-Message-Handle, Transfer-Attributes, Error-Type) 6434 NSLP-Message-Handle: A handle for the message provided by the 6435 signalling application in SendMessage. 6437 Transfer-Attributes: The reliability and security attributes that 6438 will be used to transmit this particular message. 6440 Error-Type: Indicates the type of error that occurred. For example, 6441 'no next node found'. 6443 B.4. NetworkNotification 6445 This primitive is passed from GIST to a signalling application. It 6446 indicates that a network event of possible interest to the signalling 6447 application occurred. 6449 NetworkNotification ( NSLPID, MRI, Network-Notification-Type ) 6451 NSLPID: An identifier indicating which NSLP this is message is for. 6453 MRI: Provides the message routing information to which the network 6454 notification applies. 6456 Network-Notification-Type: Indicates the type of event that caused 6457 the notification and associated additional data. Five events have 6458 been identified: 6460 Last Node: GIST has detected that this is the last NSLP-aware 6461 node in the path. See Section 4.3.4. 6463 Routing Status Change: GIST has installed new routing state, has 6464 detected that existing routing state may no longer be valid, or 6465 has re-established existing routing state. See Section 7.1.3. 6466 The new status is reported; if the status is Good, the SII- 6467 Handle of the peer is also reported, as for RecvMessage. 6469 Route Deletion: GIST has determined that an old route is now 6470 definitely invalid, e.g. that flows are definitely not using it 6471 (see Section 7.1.4). The SII-Handle of the peer is also 6472 reported. 6474 Node Authorisation Change: The authorisation status of a peer has 6475 changed, meaning that routing state is no longer valid or that 6476 a signalling peer is no longer reachable; see Section 4.4.2. 6478 Communication Failure: Communication with the peer has failed; 6479 messages may have been lost. 6481 B.5. SetStateLifetime 6483 This primitive is passed from a signalling application to GIST. It 6484 indicates the duration for which the signalling application would 6485 like GIST to retain its routing state. It can also give a hint that 6486 the signalling application is no longer interested in the state. 6488 SetStateLifetime ( NSLPID, MRI, SID, State-Lifetime ) 6490 NSLPID: Provides the NSLPID to which the routing state lifetime 6491 applies. 6493 MRI: Provides the message routing information to which the routing 6494 state lifetime applies; includes the direction (in the D flag). 6496 SID: The session ID which the signalling application will be using 6497 with this routing state. Can be wildcarded. 6499 State-Lifetime: Indicates the lifetime for which the signalling 6500 application wishes GIST to retain its routing state (may be zero, 6501 indicating that the signalling application has no further interest 6502 in the GIST state). 6504 B.6. InvalidateRoutingState 6506 This primitive is passed from a signalling application to GIST. It 6507 indicates that the signalling application has knowledge that the next 6508 signalling hop known to GIST may no longer be valid, either because 6509 of changes in the network routing or the processing capabilities of 6510 signalling application nodes. See Section 7.1. 6512 InvalidateRoutingState ( NSLPID, MRI, Status, NSLP-Data, 6513 NSLP-Data-Size, Urgent ) 6515 NSLPID: The NSLP originating the message. May be null (in which 6516 case the invalidation applies to all signalling applications). 6518 MRI: The flow for which routing state should be invalidated; 6519 includes the direction of the change (in the D flag). 6521 Status: The new status that should be assumed for the routing state, 6522 one of Bad or Tentative (see Section 7.1.3). 6524 NSLP-Data, NSLP-Data-Size Optional: a payload provided by the NSLP 6525 to be used the next GIST handshake. This can be used as part of a 6526 conditional peering process (see Section 4.3.2). The payload will 6527 be transmitted without security protection. 6529 Urgent: A hint as to whether rediscovery should take place 6530 immediately, or only with the next signalling message. 6532 Appendix C. Deployment Issues with Router Alert Options 6534 The GIST peer discovery handshake (Section 4.4.1) depends on the 6535 interception of Q-mode encapsulated IP packets (Section 4.3.1 and 6536 Section 5.3.2) by routers. There are two fundamental requirements on 6537 the process: 6539 1. Packets relevant to GIST must be intercepted. 6541 2. Packets not relevant to GIST must be forwarded transparently. 6543 This specification defines the GIST behaviour to ensure that both 6544 requirements are met for a GIST-capable node. However, GIST packets 6545 will also encounter non-GIST nodes, for which requirement (2) still 6546 applies. If non-GIST nodes block Q-mode packets, GIST will not 6547 function. It is always possible for middleboxes to block specific 6548 traffic types; by using a normal UDP encapsulation for Q-mode 6549 traffic, GIST allows NATs at least to pass these messages 6550 (Section 7.2.1), and firewalls can be configured with standard 6551 policies. However, where the Q-mode encapsulation uses a Router 6552 Alert Option (RAO) at the IP level this can lead to additional 6553 problems. The situation is different for IPv4 and IPv6. 6555 The IPv4 RAO is defined by [3], which defines the RAO format with a 6556 2-byte value field; however, only one value (zero) is defined and 6557 there is no IANA registry for further allocations. It states that 6558 unknown values should be ignored (i.e. the packets forwarded as 6559 normal IP traffic); however, it has also been reported that some 6560 existing implementations simply ignore the RAO value completely (i.e. 6561 process any packet with an RAO as though the option value was zero). 6562 Therefore, the use of non-zero RAO values cannot be relied on to make 6563 GIST traffic transparent to existing implementations. (Note that it 6564 may still be valuable to be able to allocate non-zero RAO values for 6565 IPv4: this makes the interception process more efficient for nodes 6566 which do examine the value field, and makes no difference to nodes 6567 which - incorrectly - ignore it. Whether or not non-zero RAO values 6568 are used does not change the GIST protocol operation, but needs to be 6569 decided when new NSLPs are registered.) 6571 The second stage of the analysis is therefore what happens when a 6572 non-GIST node which implements RAO handling sees a Q-mode packet. 6573 The RAO specification simply states that "Routers that recognize this 6574 option shall examine packets carrying it more closely (check the IP 6575 Protocol field, for example) to determine whether or not further 6576 processing is necessary." There are two possible basic behaviours 6577 for GIST traffic: 6579 1. The "closer examination" of the packet is sufficiently 6580 intelligent to realise that the node does not need to process it 6581 and should forward it. This could either be by virtue of the 6582 fact that the node has not been configured to match IP- 6583 Protocol=UDP for RAO packets at all, or that even if UDP traffic 6584 is intercepted the port numbers do not match anything locally 6585 configured. 6587 2. The "closer examination" of the packet identifies it as UDP, and 6588 delivers it to the UDP stack on the node. In this case, it can 6589 no longer be guaranteed to be processed appropriately. Most 6590 likely it will simply be dropped or rejected with an ICMP error 6591 (because there is no GIST process on the destination port to 6592 deliver it to). 6594 Analysis of open-source operating system source code shows the first 6595 type of behaviour, and this has also been seen in direct GIST 6596 experiments with commercial routers, including the case when they 6597 process other uses of the RAO (i.e. RSVP). However, it has also 6598 been reported that other RAO implementations will exhibit the second 6599 type of behaviour. The consequence of this would be that Q-mode 6600 packets are blocked in the network and GIST could not be used. Note 6601 that although this caused by some subtle details in the RAO 6602 processing rules, the end result is the same as if the packet was 6603 simply blocked for other reasons (for example, many IPv4 firewalls 6604 drop packets with options by default). 6606 The GIST specification allows two main options for circumventing 6607 nodes which block Q-mode traffic in IPv4. Whether to use these 6608 options is a matter of implementation and configuration choice. 6610 o A GIST node can be configured to send Q-mode packets without the 6611 RAO at all. This should avoid the above problems, but should only 6612 be done if it is known that nodes on the path to the receiver are 6613 able to intercept such packets. (See Section 5.3.2.1.) 6615 o If a GIST node can identify exactly where the packets are being 6616 blocked (e.g. from ICMP messages), or can discover some point on 6617 the path beyond the blockage (e.g. by use of traceroute or by 6618 routing table analysis), it can send the Q-mode messages to that 6619 point using IP-in-IP tunelling without any RAO. This bypasses the 6620 input side processing on the blocking node, but picks up normal 6621 GIST behaviour beyond it. 6623 If in the light of deployment experience the problem of blocked 6624 Q-mode traffic turns out to be widespread and these techniques turn 6625 out to be insufficient, a further possibility is to define an 6626 alternative Q-mode encapsulation which does not use UDP. This would 6627 require a specification change. Such an option would be restricted 6628 to network-internal use, since operation through NATs and firewalls 6629 would be much harder with it. 6631 The situation with IPv6 is rather different, since in that case the 6632 use of non-zero RAO values is well established in the specification 6633 ([8]) and an IANA registry exists. The main problem is that several 6634 implementations are still immature: for example, some treat any RAO- 6635 marked packet as though it was for local processing without further 6636 analysis. Since this prevents any RAO usage at all (including the 6637 existing standardised ones) in such a network, it seems reasonable to 6638 assume that such implementations will be fixed as part of the general 6639 deployment of IPv6. 6641 Appendix D. Example Routing State Table and Handshake 6643 Figure 11 shows a signalling scenario for a single flow being managed 6644 by two signalling applications using the path-coupled message routing 6645 method. The flow sender and receiver and one router support both, 6646 two other routers support one each. The figure also shows the 6647 routing state table at node B. 6649 A B C D E 6650 +------+ +-----+ +-----+ +-----+ +--------+ 6651 | Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow | 6652 |Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver| 6653 | | +-+ +-+ |GIST | |GIST | |GIST | | | 6654 +------+ +-----+ +-----+ +-----+ +--------+ 6655 Flow Direction ------------------------------>> 6657 +------------------------------------+---------+--------+-----------+ 6658 | Message Routing Information | Session | NSLPID | Routing | 6659 | | ID | | State | 6660 +------------------------------------+---------+--------+-----------+ 6661 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | IP-A | 6662 | {IP-A, IP-E, proto/ports}; D=up | | | | 6663 | | | | | 6664 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | (null) | 6665 | {IP-A, IP-E, proto/ports}; D=down | | | | 6666 | | | | | 6667 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | IP-A | 6668 | {IP-A, IP-E, proto/ports}; D=up | | | | 6669 | | | | | 6670 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | Points to | 6671 | {IP-A, IP-E, proto/ports}; D=down | | | B-D MA | 6672 +------------------------------------+---------+--------+-----------+ 6674 Figure 11: A Signalling Scenario 6676 The upstream state is just the same address for each application. 6677 For the downstream direction, NSLP1 only requires D-mode messages and 6678 so no explicit routing state towards C is needed. NSLP2 requires a 6679 messaging association for its messages towards node D, and node C 6680 does not process NSLP2 at all, so the peer state for NSLP2 is a 6681 pointer to a messaging association that runs directly from B to D. 6682 Note that E is not visible in the state table (except implicitly in 6683 the address in the message routing information); routing state is 6684 stored only for adjacent peers. (In addition to the peer 6685 identification, IP hop counts are stored for each peer where the 6686 state itself if not null; this is not shown in the table.) 6688 Figure 12 shows a GIST handshake setting up a messaging association 6689 for B-D signalling, with the exchange of Stack Proposals and MA- 6690 protocol-options in each direction. The Querying node selects TLS/ 6691 TCP as the stack configuration and sets up the messaging association 6692 over which it sends the Confirm. 6694 -------------------------- Query ----------------------------> 6695 IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST) 6696 D-mode magic number (0x4e04 bda5) 6697 GIST(Header(Type=Query; NSLPID=NSLP2; R=1; S=0) 6698 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 6699 SessionID(0x1234) NLI(Peer='string1'; IA=IP#B) 6700 QueryCookie(0x139471239471923526) 6701 StackProposal(#Proposals=3;1=TLS/TCP; 2=TLS/SCTP; 3=TCP) 6702 StackConfigurationData(HoldTime=300; #MPO=2; 6703 TCP(Applicable: all; Data: null) 6704 SCTP(Applicable: all; Data: null))) 6706 <---------------------- Response ---------------------------- 6707 IP(Src=IP#D; Dst=IP#B); UDP(Src=GIST; Dst=6789) 6708 D-mode magic number (0x4e04 bda5) 6709 GIST(Header(Type=Response; NSLPID=NSLP2; R=1; S=1) 6710 MRI(MRM=Path-Coupled; Flow=F; Direction=up) 6711 SessionID(0x1234) NLI(Peer='stringr2', IA=IP#D) 6712 QueryCookie(0x139471239471923526) 6713 ResponderCookie(0xacdefedcdfaeeeded) 6714 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP) 6715 StackConfigurationData(HoldTime=200; #MPO=3; 6716 TCP(Applicable: 3; Data: port=6123) 6717 TCP(Applicable: 1; Data: port=5438) 6718 SCTP(Applicable: all; Data: port=3333))) 6720 -------------------------TCP SYN-----------------------> 6721 <----------------------TCP SYN/ACK---------------------- 6722 -------------------------TCP ACK-----------------------> 6723 TCP connect(IP Src=IP#B; IP Dst=IP#D; Src Port=9166; Dst Port=6123) 6724 <-----------------------TLS INIT-----------------------> 6726 ------------------------ Confirm ----------------------------> 6727 [Sent within messaging association] 6728 GIST(Header(Type=Confirm; NSLPID=NSLP2; R=0; S=1) 6729 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 6730 SessionID(0x1234) NLI(Peer='string1'; IA=IP#B) 6731 ResponderCookie(0xacdefedcdfaeeeded) 6732 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP) 6733 StackConfigurationData(HoldTime=300)) 6735 Figure 12: GIST Handshake Message Sequence 6737 Appendix E. Change History 6739 Note to the RFC Editor: this appendix to be removed before 6740 publication as an RFC. 6742 E.1. Changes in Version -14 6744 The following changes were made in version 14. They include fixes 6745 for the issues identified at the Karlsruhe interop event. 6747 1. Changed the treatment of D-mode messages received (at the IP 6748 destination address) with the wrong magic number so they are 6749 silently dropped rather than generating an error message 6750 (Section 5.3.1, Section 5.3.2.3, and Appendix A.4.4.1). 6752 2. Added a dedicated figure to illustrate the example in 6753 Section 3.10. 6755 3. Added a note in Section 4.3.1 to clarify that GIST messages with 6756 zero hop count should never be seen from correct 6757 implementations. 6759 4. Added a figure to show the high-level format of normal D-mode 6760 encapsulation (especially the location of the magic number) to 6761 Section 5.3.1. 6763 5. Added a clarification in Section 5.3.2.1 explaining the 6764 significance of S=1 for the processing of ICMP error messages, 6765 and made the text there more consistent with the RFC2119 6766 language in Section 5.8.1.2. 6768 6. Corrected the message size rules in Section 4.3.3 to allow the 6769 use of messages up to the path MTU to the next peer if this is 6770 known. Also made the default MTU limit consistent in the bypass 6771 processing rules in Section 4.3.4. 6773 7. Clarified the ability to use Q-mode for Data messages when 6774 requested by local policy, in Section 4.1.2, Section 4.3.3, 6775 Section 5.3.2 and Section 5.5. 6777 8. Clarified in Section 5.6 that the NSLPID of messages that cause 6778 an error should be deduced from the Common Header embedded in 6779 the Error object. 6781 9. Modified the text in Section 4.3.2 to clarify that the Hop Count 6782 is still decremented in this case (but no other GIST payloads). 6784 10. Tidied up the text in Section 4.3.4 describing the scenarios 6785 under which a GIST message may be bypassed at the GIST level. 6787 11. Clarified the text in Section 7.2.1 to say that the legacy NAT 6788 detection procedure does not handle the case of Data messages 6789 sent outside a messaging association. 6791 12. Extended the description at the end of Section 7.2.2 to explain 6792 the responsibility of the Responding node to translate between 6793 the MRIs used either side of the NAT for messages sent after the 6794 handshake. 6796 13. Modified the text introducing Section 5.5 to restrict the 6797 Incorrect Encapsulation error message to apply only when a 6798 message that should be in C-mode arrives in D-mode and vice 6799 versa. 6801 14. Clarified that rule 6 in Section 6.3 should include dropping the 6802 incoming data. [Interop ticket 36] 6804 15. Modified the handling of the Stack-Proposal verification in 6805 Section 5.7.1 to say that the MA is only torn down if it is a 6806 new one; otherwise, the action is that the routing state for the 6807 MRI is deleted or never created. Added the verification of the 6808 Responder cookie to be included in the same set of checks. 6809 [Interop ticket 43, 49] 6811 16. Clarified that the timer used to retransmit Responses follows 6812 the same rules as other timers in Section 5.3.3;also, in 6813 Section 6.3 stated that Expire_RNode should be reset to the 6814 initial value on a new Query, and its expiration overrides any 6815 outstanding No_Confirm timer. [Interop ticket 48] 6817 17. Clarified in Section 5.6 that if the messaging association that 6818 should be used to deliver an Error message has been closed, this 6819 comes into the category of 'messages that cannot be sent'. 6820 [Interop ticket 50] 6822 18. Amended the description of Confirm contents in Section 5.1 to 6823 note that the Stack-Proposal may not be present if it was not 6824 present in the Response. (This can only happen if the Response 6825 was sent over an existing MA; if a new MA is set up, a Stack- 6826 Proposal is required in the Response. Therefore, if the 6827 abbreviated SCD is sent in the Confirm, there will always be a 6828 Stack-Proposal to accompany it.) [Interop ticket 55] 6830 19. Refined the definition of the Inactive_QNode timer in 6831 Section 6.2 to clarify that this is just to measure the activity 6832 in terms of NSLP traffic rather than GIST-internal traffic, and 6833 modified Rule 4 accordingly. [Interop ticket 64] 6835 20. Deleted the term 'full handshake' as this implied mandatory use 6836 of the 3 message for (Q/R/C), whereas in the places the term was 6837 used the purpose was to highlight that the handshake was taking 6838 place in D-mode rather than partly in C-mode. Whether a Confirm 6839 is sent is under the control of the Responder. [Interop ticket 6840 65] 6842 21. Clarified in Section 3.4 and Section 5.1 that generation of a 6843 Confirm is controlled by the content of the Response, and that 6844 when a new MA is being set up the rules for content of a 6845 Response require a Confirm. [Interop ticket 66] 6847 22. Modified the Responder-Cookie construction in Section 8.5 to 6848 clarify which parts of the NLI are included and to carry the 6849 reception interface outside the hash, and pointed to [41] for 6850 further constructions in the case of GIST-aware NAT traversal. 6852 23. Removed remaining sections of this change history. 6854 Authors' Addresses 6856 Henning Schulzrinne 6857 Columbia University 6858 Department of Computer Science 6859 450 Computer Science Building 6860 New York, NY 10027 6861 US 6863 Phone: +1 212 939 7042 6864 Email: hgs+nsis@cs.columbia.edu 6865 URI: http://www.cs.columbia.edu 6867 Robert Hancock 6868 Siemens/Roke Manor Research 6869 Old Salisbury Lane 6870 Romsey, Hampshire SO51 0ZN 6871 UK 6873 Email: robert.hancock@roke.co.uk 6874 URI: http://www.roke.co.uk 6876 Full Copyright Statement 6878 Copyright (C) The IETF Trust (2007). 6880 This document is subject to the rights, licenses and restrictions 6881 contained in BCP 78, and except as set forth therein, the authors 6882 retain all their rights. 6884 This document and the information contained herein are provided on an 6885 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 6886 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 6887 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 6888 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 6889 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 6890 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6892 Intellectual Property 6894 The IETF takes no position regarding the validity or scope of any 6895 Intellectual Property Rights or other rights that might be claimed to 6896 pertain to the implementation or use of the technology described in 6897 this document or the extent to which any license under such rights 6898 might or might not be available; nor does it represent that it has 6899 made any independent effort to identify any such rights. Information 6900 on the procedures with respect to rights in RFC documents can be 6901 found in BCP 78 and BCP 79. 6903 Copies of IPR disclosures made to the IETF Secretariat and any 6904 assurances of licenses to be made available, or the result of an 6905 attempt made to obtain a general license or permission for the use of 6906 such proprietary rights by implementers or users of this 6907 specification can be obtained from the IETF on-line IPR repository at 6908 http://www.ietf.org/ipr. 6910 The IETF invites any interested party to bring to its attention any 6911 copyrights, patents or patent applications, or other proprietary 6912 rights that may cover technology that may be required to implement 6913 this standard. Please address the information to the IETF at 6914 ietf-ipr@ietf.org. 6916 Acknowledgment 6918 Funding for the RFC Editor function is provided by the IETF 6919 Administrative Support Activity (IASA).