idnits 2.17.1 draft-ietf-nsis-ntlp-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 5884. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5861. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5874. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MA-Protocol-ID | Profile | Length |D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Options Data // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MA-Protocol-ID = Protocol identifier as described in Section 5.7 . Profile = Tag indicating which profile from the accompanying Stack-Proposal object this applies to. Profiles are numbered from 1 upwards; the special value 0 indicates 'applies to all profiles'. Length = the byte length of MA-protocol-options field that follows. This will be zero-padded up to the next word boundary. D flag = If set (D=1), this protocol MUST not be used for a messaging association. -- 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 (February 9, 2006) is 6623 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 253 -- Looks like a reference, but probably isn't: 'Flow' on line 265 -- Looks like a reference, but probably isn't: 'Adjacent' on line 275 -- Looks like a reference, but probably isn't: 'Initialisation' on line 2872 ** Obsolete normative reference: RFC 2765 (ref. '5') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2246 (ref. '6') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4234 (ref. '7') (Obsoleted by RFC 5234) ** Downref: Normative reference to an Historic draft: draft-ietf-tls-rfc2246-bis (ref. '8') -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '11') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '12') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. '14') (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '19') (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 3682 (ref. '21') (Obsoleted by RFC 5082) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-09 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-09 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-04 == Outdated reference: A later version (-02) exists of draft-loughney-nsis-ext-01 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 16 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 Expires: August 13, 2006 R. Hancock 5 Siemens/RMR 6 February 9, 2006 8 GIST: General Internet Signaling Transport 9 draft-ietf-nsis-ntlp-09 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 August 13, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies protocol stacks for the routing and transport 43 of per-flow signaling messages along the path taken by that flow 44 through the network. The design uses existing transport and security 45 protocols under a common messaging layer, the General Internet 46 Signaling Transport (GIST), which provides a universal service for 47 diverse signaling applications. GIST does not handle signaling 48 application state itself, but manages its own internal state and the 49 configuration of the underlying transport and security protocols to 50 enable the transfer of messages in both directions along the flow 51 path. The combination of GIST and the lower layer transport and 52 security protocols provides a solution for the base protocol 53 component of the "Next Steps in Signaling" framework. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Restrictions on Scope . . . . . . . . . . . . . . . . . . 5 59 2. Requirements Notation and Terminology . . . . . . . . . . . . 6 60 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 8 62 3.2. Modes and Messaging Associations . . . . . . . . . . . . 9 63 3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 10 64 3.4. Signaling Sessions . . . . . . . . . . . . . . . . . . . 12 65 3.5. Signaling Applications and NSLPIDs . . . . . . . . . . . 13 66 3.6. Example of Operation . . . . . . . . . . . . . . . . . . 14 67 4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 16 68 4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 16 69 4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 18 70 4.3. Basic Message Processing . . . . . . . . . . . . . . . . 19 71 4.4. Routing State and Messaging Association Maintenance . . . 25 72 5. Message Formats and Transport . . . . . . . . . . . . . . . . 32 73 5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 32 74 5.2. Information Elements . . . . . . . . . . . . . . . . . . 34 75 5.3. Datagram Mode Transport . . . . . . . . . . . . . . . . . 38 76 5.4. Connection Mode Transport . . . . . . . . . . . . . . . . 40 77 5.5. Message Type/Encapsulation Relationships . . . . . . . . 42 78 5.6. Error Message Processing . . . . . . . . . . . . . . . . 43 79 5.7. Messaging Association Setup . . . . . . . . . . . . . . . 44 80 5.8. Specific Message Routing Methods . . . . . . . . . . . . 47 81 6. Formal Protocol Specification . . . . . . . . . . . . . . . . 52 82 6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 53 83 6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 55 84 6.3. Responder Node Processing . . . . . . . . . . . . . . . . 58 85 6.4. Messaging Association Processing . . . . . . . . . . . . 62 86 7. Advanced Protocol Features . . . . . . . . . . . . . . . . . 65 87 7.1. Route Changes and Local Repair . . . . . . . . . . . . . 65 88 7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 71 89 7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 74 90 7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 75 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 77 92 8.1. Message Confidentiality and Integrity . . . . . . . . . . 77 93 8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 78 94 8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 78 95 8.4. Denial of Service Prevention . . . . . . . . . . . . . . 80 96 8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 81 97 8.6. Security Protocol Selection Policy . . . . . . . . . . . 83 98 8.7. Residual Threats . . . . . . . . . . . . . . . . . . . . 84 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 92 103 11.2. Informative References . . . . . . . . . . . . . . . . . 92 104 Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 95 105 A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 95 106 A.2. General Object Format . . . . . . . . . . . . . . . . . . 96 107 A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 97 108 A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 104 109 Appendix B. API between GIST and Signaling Applications . . . . 112 110 B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 112 111 B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 113 112 B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 115 113 B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 115 114 B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 116 115 B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 116 116 Appendix C. Example Routing State Table and Handshake Message 117 Sequence . . . . . . . . . . . . . . . . . . . . . . 118 118 Appendix D. Change History . . . . . . . . . . . . . . . . . . . 120 119 D.1. Changes In Version -09 . . . . . . . . . . . . . . . . . 120 120 D.2. Changes In Version -08 . . . . . . . . . . . . . . . . . 120 121 D.3. Changes In Version -07 . . . . . . . . . . . . . . . . . 122 122 D.4. Changes In Version -06 . . . . . . . . . . . . . . . . . 123 123 D.5. Changes In Version -05 . . . . . . . . . . . . . . . . . 124 124 D.6. Changes In Version -04 . . . . . . . . . . . . . . . . . 125 125 D.7. Changes In Version -03 . . . . . . . . . . . . . . . . . 126 126 D.8. Changes In Version -02 . . . . . . . . . . . . . . . . . 127 127 D.9. Changes In Version -01 . . . . . . . . . . . . . . . . . 128 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 131 129 Intellectual Property and Copyright Statements . . . . . . . . . 132 131 1. Introduction 133 Signaling involves the manipulation of state held in network 134 elements. 'Manipulation' could mean setting up, modifying and 135 tearing down state; or it could simply mean the monitoring of state 136 which is managed by other mechanisms. 138 This specification concentrates on "path-coupled" signaling, which 139 involves network elements which are located on the path taken by a 140 particular data flow, possibly including but not limited to the flow 141 endpoints. Indeed, there are almost always more than two 142 participants in a path-coupled signaling session, although there is 143 no need for every node on the path to participate. Path-coupled 144 signaling thus excludes end-to-end higher-layer application signaling 145 (except as a degenerate case) such as ISUP (telephony signaling for 146 Signaling System #7) messages being transported by SCTP between two 147 nodes. 149 In the context of path-coupled signaling, examples of state 150 management include network resource allocation (for "resource 151 reservation"), firewall configuration, and state used in active 152 networking; examples of state monitoring are the discovery of 153 instantaneous path properties (such as available bandwidth, or 154 cumulative queuing delay). Each of these different uses of path- 155 coupled signaling is referred to as a signaling application. 157 Every signaling application requires a set of state management rules, 158 as well as protocol support to exchange messages along the data path. 159 Several aspects of this protocol support are common to all or a large 160 number of signaling applications, and hence can be developed as a 161 common protocol. The NSIS framework given in [22] provides a 162 rationale for a function split between the common and application 163 specific protocols, and gives outline requirements for the former, 164 the 'NSIS Transport Layer Protocol' (NTLP). The application specific 165 protocols are referred to as 'NSIS Signaling Layer Protocols' 166 (NSLPs), and are defined in separate documents. 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 Signaling Transport 171 (GIST). GIST does not handle signaling application state itself; in 172 that crucial respect, it differs from application signaling protocols 173 such as SIP, RTSP, and the control component of FTP. Instead, GIST 174 manages its own internal state and the configuration of the 175 underlying transport and security protocols to ensure the transfer of 176 signaling messages on behalf of signaling applications in both 177 directions along the flow path. 179 The structure of this specification is as follows. Section 2 defines 180 terminology, and Section 3 gives an informal overview of the protocol 181 design principles and operation. The normative specification is 182 contained mainly in Section 4 to Section 8. Section 4 describes the 183 message sequences and Section 5 their format and contents (note that 184 the detailed bit formats are given in Appendix A). The protocol 185 operation is captured in the form of state machine language in 186 Section 6. Section 7 describes some more advanced protocol features 187 and security considerations are contained in Section 8. In addition, 188 Section 9 gives the IANA considerations, Appendix B describes an 189 abstract API for the service which GIST provides to signaling 190 applications, and Appendix C provides an example message flow. 192 1.1. Restrictions on Scope 194 This section briefly lists some important restrictions on GIST 195 applicability and functionality. In some cases, these are implicit 196 consequences of the functionality split developed in the NSIS 197 framework; in others, they are restrictions on the types of scenario 198 in which GIST can operate correctly. 200 Flow splitting: In some cases, e.g. where packet-level load sharing 201 has been implemented, the path taken by a single flow in the 202 network may not be well defined. If this is the case, GIST cannot 203 route signaling meaningfully. (In some circumstances, GIST 204 implementations could detect this condition, but even this cannot 205 be guaranteed.) 207 Multicast: GIST does not handle multicast flows. This includes 208 'classical' IP multicast and any of the 'small group multicast' 209 schemes recently proposed. 211 Legacy NATs: GIST messages will generally pass through NATs, but 212 unless the NAT is GIST-aware, any addressing data carried in the 213 payload will not be handled correctly. There is a dual problem of 214 whether the GIST peers either side of the boundary can work out 215 how to address each other, and whether they can work out what 216 translation to apply to the signaling packet payloads. The 217 fundamental problem is that GIST messages contain 3 or 4 218 interdependent addresses which all have to be consistently 219 translated, and existing generic NAT traversal techniques such as 220 STUN [19] or TURN [20] can process only two. (Appropriate 221 behaviour for a GIST-aware NAT is discussed in Section 7.2.) 223 2. Requirements Notation and Terminology 225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 227 document are to be interpreted as described in [2]. 229 The terminology used in this specification is fully defined in this 230 section. The basic entities relevant at the GIST level are shown in 231 Figure 1. 233 Source GIST (adjacent) peer nodes Destination 235 IP address IP addresses = Signaling IP address 236 = Flow Source/Destination Addresses = Flow 237 Source (depending on signaling direction) Destination 238 Address | | Address 239 V V 240 +--------+ +------+ Data Flow +------+ +--------+ 241 | Flow |-----------|------|-------------|------|-------->| Flow | 242 | Sender | | | | | |Receiver| 243 +--------+ | GIST |============>| GIST | +--------+ 244 | Node |<============| Node | 245 +------+ Signaling +------+ 246 GN1 Flow GN2 248 >>>>>>>>>>>>>>>>> = Downstream direction 249 <<<<<<<<<<<<<<<<< = Upstream direction 251 Figure 1: Basic Terminology 253 [Data] Flow: A set of packets identified by some fixed combination of 254 header fields. Flows are unidirectional (a bidirectional 255 communication is considered a pair of unidirectional flows). 257 Session: A single application layer flow of information for which 258 some state information is to be manipulated or monitored. See 259 Section 3.4 for further detailed discussion. 261 [Flow] Sender: The node in the network which is the source of the 262 packets in a flow. Could be a host, or a router (e.g. if the flow 263 is actually an aggregate). 265 [Flow] Receiver: The node in the network which is the sink for the 266 packets in a flow. 268 Downstream: In the same direction as the data flow. 270 Upstream: In the opposite direction to the data flow. 272 GIST Node: Any node along the data path supporting GIST (regardless 273 of what signaling applications it supports). 275 [Adjacent] Peer: The next node along the data path, in the upstream 276 or downstream direction, with which a GIST node explicitly 277 interacts. The GIST peer discovery mechanisms implicitly 278 determine whether two nodes will be adjacent. It is possible for 279 adjacencies to 'skip over' intermediate nodes which decide not to 280 take part in the signaling exchange at the NTLP layer; even if 281 such nodes process parts of the signaling messages, they store no 282 state about the session and are never explicitly visible at the 283 GIST level to the nodes either side. 285 Datagram Mode: A mode of sending GIST messages between nodes without 286 using any transport layer state or security protection. Datagram 287 mode uses UDP encapsulation, with IP addresses derived either from 288 the flow definition or previously discovered adjacency 289 information. 291 Connection Mode: A mode of sending GIST messages directly between 292 nodes using point to point "messaging associations" (see below). 293 Connection mode allows the re-use of existing transport and 294 security protocols where such functionality is required. 296 Messaging Association: A single connection between two explicitly 297 identified GIST adjacent peers, i.e. between a given signaling 298 source and destination address. A messaging association may use a 299 specific transport protocol and known ports. If security 300 protection is required, it may use a specific network layer 301 security association, or use a transport layer security 302 association internally. A messaging association is bidirectional; 303 signaling messages can be sent over it in either direction, and 304 can refer to flows of either direction. 306 Message Routing Method: There can be different algorithms for 307 discovering the route that signaling messages should take. These 308 are referred to as message routing methods, and GIST supports 309 alternatives within a common protocol framework. See Section 3.3. 311 Transfer Attributes: A description of the requirements which a 312 signaling application has for the delivery of a particular 313 message; for example, whether the message should be delivered 314 reliably. See Section 4.1.2. 316 3. Design Overview 318 3.1. Overall Design Approach 320 The generic requirements identified in the NSIS framework [22] for 321 transport of path-coupled signaling messages are essentially two- 322 fold: 324 "Routing": Determine how to reach the adjacent signaling node along 325 each direction of the data path (the GIST peer), and if necessary 326 explicitly establish addressing and identity information about 327 that peer; 329 "Transport": Deliver the signaling information to that peer. 331 To meet the routing requirement, one possibility is for the node to 332 use local routing state information to determine the identity of the 333 GIST peer explicitly. GIST defines a 3-way handshake (Query/ 334 Response/optional Confirm) which sets up the necessary routing state 335 between adjacent peers, during which signaling applications can also 336 exchange data; the Query message is encapsulated in a special way, 337 depending on the message routing method, in order to probe the 338 network infrastructure so that the correct peer will intercept it. 339 If the routing state does not exist, GIST may be able to send a 340 message anyway, with the same encapsulation as for a Query message. 342 Once the routing decision has been made, the node has to select a 343 mechanism for transport of the message to the peer. GIST divides the 344 transport problems into two categories, the easy and the difficult. 345 It handles the easy cases internally, and uses well-understood 346 transport protocols for the harder cases. Here, with details 347 discussed later, "easy" messages are those that are sized well below 348 the lowest MTU along a path, are infrequent enough not to cause 349 concerns about congestion and flow control, and do not need security 350 protection or guaranteed delivery. 352 In [22] all of these routing and transport requirements are assigned 353 to a single notional protocol, the 'NSIS Transport Layer Protocol' 354 (NTLP). The strategy of splitting the transport problem leads to a 355 layered structure for the NTLP, of a specialised GIST 'messaging' 356 layer running over standard transport and security protocols, as 357 shown in Figure 2. This also shows GIST offering its services to 358 upper layers at an abstract interface, the GIST API, further 359 discussed in Section 4.1. 361 ^^ +-------------+ 362 || | Signaling | 363 NSIS +------------|Application 2| 364 Signaling | Signaling +-------------+ 365 Application |Application 1| | 366 Level +-------------+ | 367 || | | 368 VV | | 369 ========|===================|===== <-- GIST API 370 | | 371 ^^ +------------------------------------------------+ 372 || |+-----------------------+ +--------------+ | 373 || || GIST | | GIST State | | 374 || || Encapsulation |<<<>>>| Maintenance | | 375 || |+-----------------------+ +--------------+ | 376 || | GIST: Messaging Layer | 377 || +------------------------------------------------+ 378 NSIS | | | | 379 Transport ............................. 380 Level . Transport Layer Security . 381 ("NTLP") ............................. 382 || | | | | 383 || +----+ +----+ +----+ +----+ 384 || |UDP | |TCP | |SCTP| |DCCP| ... other 385 || +----+ +----+ +----+ +----+ protocols 386 || | | | | 387 || ............................. 388 || . IP Layer Security . 389 || ............................. 390 VV | | | | 391 ========================|=======|=======|=======|=============== 392 | | | | 393 +----------------------------------------------+ 394 | IP | 395 +----------------------------------------------+ 397 Figure 2: Protocol Stacks for Signaling Transport 399 3.2. Modes and Messaging Associations 401 Internally, GIST has two modes of operation: 403 Datagram mode ('D mode') is used for small, infrequent messages with 404 modest delay constraints; it is also used at least for the Query 405 message of the 3-way handshake. 407 Connection mode ('C mode') is used for larger data objects or where 408 fast state setup in the face of packet loss is desirable, or where 409 channel security is required. 411 Datagram mode uses UDP, as this is the only encapsulation which does 412 not require per-message shared state to be maintained between the 413 peers. The connection mode can in principal use any stream or 414 message-oriented transport protocol; this specification defines TCP 415 as the initial choice. It can in principal employ specific network 416 layer security associations, or an internal transport layer security 417 association; this specification defines TLS as the initial choice. 418 When GIST messages are carried in connection mode, they are treated 419 just like any other traffic by intermediate routers between the GIST 420 peers. Indeed, it would be impossible for intermediate routers to 421 carry out any processing on the messages without terminating the 422 transport and security protocols used. 424 It is possible to mix these two modes along a path. This allows, for 425 example, the use of datagram mode at the edges of the network and 426 connection mode in the core of the network. Such combinations may 427 make operation more efficient for mobile endpoints, while allowing 428 multiplexing of signaling messages across shared security 429 associations and transport connections between core routers. 431 It must be understood that the routing and transport decisions made 432 by GIST are not independent. If the message transfer has 433 requirements that require connection mode (e.g. the message is so 434 large that fragmentation is required), this can only be used between 435 explicitly identified nodes. In such cases, GIST carries out the 436 3-way handshake initially in datagram mode to identify the peer and 437 then sets up the necessary connections if they do not already exist. 438 It must also be understood that the signaling application does not 439 make the D/C mode selection directly; rather, this decision is made 440 by GIST on the basis of the message characteristics and the transfer 441 attributes stated by the application. The distinction is not visible 442 at the GIST service interface. 444 In general, the state associated with connection mode messaging to a 445 particular peer (signaling destination address, protocol and port 446 numbers, internal protocol configuration and state information) is 447 referred to as a "messaging association". There may be any number of 448 messaging associations between two GIST peers (although the usual 449 case is 0 or 1), and they are set up and torn down by management 450 actions within GIST itself. 452 3.3. Message Routing Methods 454 The baseline message routing functionality in GIST is that signaling 455 messages follow a route defined by an existing flow in the network, 456 visiting a subset of the nodes through which it passes. This is the 457 appropriate behaviour for application scenarios where the purpose of 458 the signaling is to manipulate resources for that flow. However, 459 there are scenarios for which other behaviours are applicable. Two 460 examples are: 462 Predictive Routing: Here, the intent is to signal along a path that 463 the data flow may follow in the future. Possible cases are pre- 464 installation of state on the backup path that would be used in the 465 event of a link failure; and predictive installation of state on 466 the path that will be used after a mobile node handover. 468 NAT Address Reservations: This applies to the case where a node 469 behind a NAT wishes to reserve an address at which it can be 470 reached by a sender on the other side. This requires a message to 471 be sent outbound from what will be the flow receiver although no 472 reverse routing state for the flow yet exists. 474 Most of the details of GIST operation are independent of which 475 alternative is being used. Therefore, the GIST design encapsulates 476 the routing-dependent details as a message routing method (MRM), and 477 allows multiple MRMs to be defined. The default is the path-coupled 478 MRM, which corresponds to the baseline functionality described above; 479 a second MRM for the NAT Address Reservation case is also defined. 481 The content of a MRM definition is as follows, using the path-coupled 482 MRM as an example: 484 o The format of the information that describes the path that the 485 signaling should take, the Message Routing Information (MRI). For 486 the path-coupled MRM, this is just the Flow Identifier (see 487 Section 5.8.1.1) and some additional control information. 488 Specifically, the MRI always includes a flag to distinguish 489 between the two directions that signaling messages can take, 490 denoted 'upstream' and 'downstream'. 492 o A specification of the IP level encapsulation of the Query 493 messages which probe the network to discover the adjacent peers. 494 A downstream encapsulation must be defined; an upstream 495 encapsulation is optional. For the path-coupled MRM, this 496 information is given in Section 5.8.1.2 and Section 5.8.1.3. 498 o A specification of what validation checks GIST should apply to the 499 probe messages, for example to protect against IP address spoofing 500 attacks. The checks may be dependent on the direction (upstream/ 501 downstream) of the message. For the path-coupled MRM, the 502 downstream validity check is basically a form of ingress 503 filtering, also discussed in Section 5.8.1.2. 505 o The mechanism(s) available for route change detection, i.e. any 506 change in the neighbour relationships that the MRM discovers. The 507 default case for any MRM is soft-state refresh, but additional 508 supporting techniques may be possible; see Section 7.1.2. 510 In addition, it should be noted that NAT traversal almost certainly 511 requires transformation of the MRI field in GIST messages (see 512 Section 7.2). Although the transformation does not have to be 513 defined as part of the standard, the impact on existing GIST-aware 514 NAT implementations should be considered. 516 The MRI is passed explicitly between signaling applications and GIST; 517 therefore, signaling application specifications must define which 518 MRMs they require (they may use more than one, e.g. depending on the 519 type of message). Signaling applications may use fields in the MRI 520 in their packet classifiers; if they use additional information for 521 packet classification, this would be carried at the NSLP level and so 522 would be invisible to GIST. Any node hosting a particular signaling 523 application MUST use a GIST implementation that supports the 524 corresponding MRMs. The GIST processing rules enforce that nodes 525 which do not host the signaling application are not forced to handle 526 messages for it at the GIST level, so it does not matter if they 527 support the MRM or not. 529 3.4. Signaling Sessions 531 GIST allows signaling applications to associate each message with a 532 "signaling session". Informally, given an application layer exchange 533 of information for which some network control state information is to 534 be manipulated or monitored, the corresponding signaling messages 535 should be associated with the same session. Signaling applications 536 provide the session identifier (SID) whenever they wish to send a 537 message, and GIST reports the SID when a message is received. 539 Most GIST processing and state information is related to the flow 540 (defined by the MRI, see above) and signaling application (given by 541 the NSLPID, see below). There are several possible relationships 542 between flows and sessions, for example: 544 o The simplest case is that all messages for the same flow have the 545 same SID. 547 o Messages for more than one flow may use the same SID, for example 548 because one flow is replacing another in a mobility or multihoming 549 scenario. 551 o A single flow may have messages for different SIDs, for example 552 from independently operating NSLPIDs. 554 Because of this range of options, GIST does not perform any 555 validation on how signaling applications map between flows and 556 sessions, nor does it perform any validation on the properties of the 557 SID itself. In particular, when a new SID is needed, logically it 558 should be generated by the signaling application. (NSIS 559 implementations could provide common functionality to generate SIDs 560 for use by any signaling application, but this is not part of GIST.) 561 GIST only defines the syntax of the SID as an opaque 128-bit 562 identifier. 564 The SID assignment has the following impact on GIST processing: 566 o Messages with the same SID to be delivered reliably between the 567 same GIST peers are delivered in order. 569 o All other messages are handled independently. 571 o GIST identifies routing state (upstream and downstream peer) by 572 the triplet (MRI, NSLPID, SID). 574 Strictly, the routing state should not depend on the SID. However, 575 if the routing state is keyed only by (MRI, NSLPID) there is a 576 trivial denial of service attack (see Section 8.3) where a malicious 577 off-path node asserts that it is the peer for a particular flow. 578 Instead, the routing state is also segregated between different SIDs, 579 which means that the attacking node can only disrupt a signaling 580 session if it can guess the corresponding SID. A consequence of this 581 design is that signaling applications should choose SIDs so that they 582 are cryptographically random, and should not use several SIDs for the 583 same flow unless strictly necessary, to avoid additional load from 584 routing state maintenance. 586 3.5. Signaling Applications and NSLPIDs 588 The functionality for signaling applications is supported by NSIS 589 signaling layer protocols (NSLPs). Each NSLP is identified by a 16 590 bit NSLPID, assigned by IANA (Section 9). A single signaling 591 application (e.g. "resource reservation") may define a family of 592 NSLPs to implement its functionality, for example to carry out 593 signaling operations at different levels in a hierarchy (cf. [15]). 594 However, the interactions between the different NSLPs (for example, 595 to relate aggregation levels or aggregation region boundaries in the 596 resource management case) are handled at the signaling application 597 level; the NSLPID is the only information visible to GIST about the 598 signaling application being used. 600 3.6. Example of Operation 602 This section presents an example of GIST usage in a relatively simple 603 (in particular, NAT-free) signaling scenario, to illustrate its main 604 features. 606 Consider the case of an RSVP-like signaling application which 607 allocates resources for a single unicast flow. We will consider how 608 GIST transfers messages between two adjacent peers along the path, 609 GN1 and GN2 (see Figure 1). In this example, the end-to-end exchange 610 is initiated by the signaling application instance in the sender; we 611 take up the story at the point where the first message is being 612 processed (above the GIST layer) by the signaling application in GN1. 614 1. The signaling application in GN1 determines that this message is 615 a simple description of resources that would be appropriate for 616 the flow. It determines that it has no special security or 617 transport requirements for the message, but simply that it should 618 be transferred to the next downstream signaling application peer 619 on the path that the flow will take. 621 2. The message payload is passed to the GIST layer in GN1, along 622 with a definition of the flow and description of the message 623 transfer attributes {unsecured, unreliable}. GIST determines 624 that this particular message does not require fragmentation and 625 that it has no knowledge of the next peer for this flow and 626 signaling application; however, it also determines that this 627 application is likely to require secured upstream and downstream 628 transport of large messages in the future. This determination is 629 a function of node-local policy interactions between GIST and the 630 signaling application. 632 3. GN1 therefore constructs a GIST-Query message, a UDP datagram 633 carrying the NSLP payload and additional payloads at the GIST 634 level to be used to initiate a messaging association. The Query 635 is injected into the network, addressed towards the flow 636 destination and with a Router Alert Option included. 638 4. The Query message passes through the network towards the flow 639 receiver, and is seen by each router in turn. GIST-unaware 640 routers will not recognise the RAO value and will forward the 641 message unchanged; GIST-aware routers which do not support the 642 NSLP in question will also forward the message basically 643 unchanged, although they may need to process more of the message 644 to decide this. 646 5. The message is intercepted at GN2. The GIST layer identifies the 647 message as relevant to a local signaling application, and passes 648 the NSLP payload and flow description upwards to it. The 649 signaling application in GN2 indicates to GIST that it will peer 650 with GN1 and so GIST should proceed to set up any routing state. 651 In addition, the signaling application continues to process the 652 message as in GN1 (compare step 1), and this will eventually 653 result in the message reaching the flow receiver. 655 6. In parallel, the GIST instance in GN2 now knows that it should 656 maintain routing state and a messaging association for future 657 signaling with GN1. This is recognised because the message is a 658 GIST-Query, and because the local signaling application has 659 indicated that it will peer with GN1. There are two basic 660 possible cases for sending back the necessary GIST-Response: 662 A. GN1 and GN2 already have an appropriate messaging 663 association. GN2 simply records the identity of GN1 as its 664 upstream peer for that flow and NSLP, and sends a GIST- 665 Response back to GN1 over the association identifying itself 666 as the peer for this flow. 668 B. No messaging association exists. GN2 sends the GIST-Response 669 in D mode directly to GN1, identifying itself and agreeing to 670 the association setup. The protocol exchanges needed to 671 complete this will proceed in the background. 673 7. Eventually, another NSLP message works its way upstream from the 674 receiver to GN2. This message contains a description of the 675 actual resources requested, along with authorisation and other 676 security information. The signaling application in GN2 passes 677 this payload to the GIST level, along with the flow definition 678 and transfer attributes {secured, reliable}. 680 8. The GIST layer in GN2 identifies the upstream peer for this flow 681 and NSLP as GN1, and determines that it has a messaging 682 association with the appropriate properties. The message is 683 queued on the association for transmission (this may mean some 684 delay if the procedures begun in step 6.B have not yet 685 completed). 687 Further messages can be passed in each direction in the same way. 688 The GIST layer in each node can in parallel carry out maintenance 689 operations such as route change detection (see Section 7.1). 691 It should be understood that several of these details of GIST 692 operations can be varied, either by local policy or according to 693 signaling application requirements. The authoritative details are 694 contained in the remainder of this document. 696 4. GIST Processing Overview 698 This section defines the basic structure and operation of GIST. 699 Section 4.1 describes the way in which GIST interacts with (local) 700 signaling applications in the form of an abstract service interface. 701 Section 4.2 describes the per-flow and per-peer state that GIST 702 maintains for the purpose of transferring messages. Section 4.3 703 describes how messages are processed in the case where any necessary 704 messaging associations and routing state already exist; this includes 705 the simple scenario of pure datagram mode operation, where no 706 messaging associations are necessary in the first place. Finally, 707 Section 4.4 describes how routing state and messaging associations 708 are created and managed. 710 4.1. GIST Service Interface 712 This section defines the service interface that GIST presents to 713 signaling applications in terms of abstract properties of the message 714 transfer. Note that the same service interface is presented at every 715 GIST node; however, applications may invoke it differently at 716 different nodes (e.g. depending on local policy). In addition, the 717 service interface is defined independently of any specific transport 718 protocol, or even the distinction between datagram and connection 719 mode. The initial version of this specification defines how to 720 support the service interface using a connection mode based on TCP; 721 if additional protocol support is added, this will support the same 722 interface and so the change will be invisible to applications (except 723 as a possible performance improvement). A more detailed description 724 of this service interface is given in Appendix B. 726 4.1.1. Message Handling 728 Fundamentally, GIST provides a simple message-by-message transfer 729 service for use by signaling applications: individual messages are 730 sent, and individual messages are received. At the service 731 interface, the NSLP payload (which is opaque to GIST) is accompanied 732 by control information expressing the application's requirements 733 about how the message should be routed, and the application also 734 provides the session identifier (see Section 3.4). Additional 735 message transfer attributes control the specific transport and 736 security properties that the signaling application desires for the 737 message. 739 The distinction between GIST connection and datagram modes is not 740 visible at the service interface. In addition, the invocation of 741 GIST functionality to handle fragmentation and reassembly, bundling 742 together of small messages (for efficiency), and congestion control 743 is not directly visible at the service interface; GIST will take 744 whatever action is necessary based on the properties of the messages 745 and local node state. 747 4.1.2. Message Transfer Attributes 749 Message transfer attributes are used to define certain performance 750 and security related aspects of message processing. The attributes 751 available are as follows: 753 Reliability: This attribute may be 'true' or 'false'. For the case 754 'true', messages MUST be delivered to the signaling application in 755 the peer exactly once or not at all; if there is a chance that the 756 message was not delivered, an error MUST be indicated to the local 757 signaling application identifying the routing information for the 758 message in question. Messages with the same SID to the same peer 759 MUST be delivered in order. For the case 'false', a message may 760 be delivered, once, several times or not at all, with no error 761 indications in any case. 763 Security: This attribute defines the security properties that the 764 signaling application requires for the message, including the type 765 of protection required, and what authenticated identities should 766 be used for the signaling source and destination. This 767 information maps onto the corresponding properties of the security 768 associations established between the peers in connection mode. It 769 can be specified explicitly by the signaling application, or 770 reported by GIST to the signaling application (either on receiving 771 a message, or just before sending a message but after configuring 772 or selecting the messaging association to be used for it). This 773 attribute can also be used to convey information about any address 774 validation carried out by GIST (for example, whether a return 775 routability check has been carried out). Further details are 776 discussed in Appendix B. 778 Local Processing: An NSLP may provide hints to GIST to enable more 779 efficient or appropriate processing. For example, the NSLP may 780 select a priority from a range of locally defined values to 781 influence the sequence in which messages leave a node. Any 782 priority mechanism MUST respect the ordering requirements for 783 reliable messages within a session, and priority values are not 784 carried in the protocol or available at the signaling peer or 785 intermediate nodes. An NSLP may also indicate that reverse path 786 routing state will not be needed for this flow, to inhibit the 787 node requesting its downstream peer to create it. 789 4.2. GIST State 791 4.2.1. Message Routing State 793 For each flow, the GIST layer can maintain message routing state to 794 manage the processing of outgoing messages. This state is 795 conceptually organised into a table with the following structure. 797 The primary key (index) for the table is the combination of the 798 information about how the message is to be routed, the session being 799 signalled for, and the signaling application itself: 801 Message Routing Information (MRI): This defines the method to be used 802 to route the message, the direction in which to send the message, 803 and any associated addressing information; see Section 3.3. 805 Session Identification (SID): The signaling session with which this 806 message should be associated; see Section 3.4. 808 NSLP Identification (NSLPID): This is an IANA assigned identifier 809 associated with the NSLP which is generating messages for this 810 flow. The inclusion of this identifier allows the routing state 811 to be different for different NSLPs (e.g. because of different 812 adjacencies). 814 The information for a given key consists of the routing state to 815 reach the peer in the direction given by the MRI. For any flow, 816 there will usually be two entries (for the upstream and downstream 817 MRI). The routing state includes information about the peer identity 818 (see Section 4.4.2), and a UDP port number (for datagram mode) or a 819 reference to one or more messaging associations (for connection 820 mode). All of this information is learned from prior GIST exchanges. 822 It is also possible for the state information for either direction to 823 be null. There are several possible cases: 825 o The signaling application has indicated that no messages will 826 actually be sent in that direction. 828 o The node is a flow endpoint, so there can be no signaling peer in 829 one or other direction. 831 o The node is the endpoint of the signaling path (for example, 832 because it is acting as a proxy, or because it has determined 833 explicitly that there are no further signaling nodes in that 834 direction). 836 o The node is using other techniques to route the message. For 837 example, it can encapsulate it the same way as a Query message and 838 rely on the peer to intercept it. 840 Each item of routing state has an associated validity timer for how 841 long it can be considered accurate; when this timer expires, it MUST 842 be purged if it has not been refreshed. Installation and maintenance 843 of routing state is described in more detail in Section 4.4. 845 Note also that the routing state is described as a table of flows, 846 but that there is no implied constraint on how the information is 847 stored. However, in general, and especially if GIST peers are 848 several IP hops away, there is no way to identify the correct 849 downstream peer for a flow and signaling application from the local 850 forwarding table using prefix matching, and the same applies always 851 to upstream peer state because of the possibility of asymmetric 852 routing: per-flow state has to be stored, just as for RSVP [9]. 854 4.2.2. Messaging Association State 856 The per-flow message routing state is not the only state stored by 857 GIST. There is also the state required to manage the messaging 858 associations. Since these are typically per-peer rather than per- 859 flow, they are stored separately, including the following 860 information: 862 o messages pending transmission while an association is being 863 established; 865 o a timer for how long since the peer re-stated its desire to keep 866 the association open (see Section 4.4.3). 868 In addition, per-association state is held in the messaging 869 association protocols themselves. However, the details of this state 870 are not directly visible to GIST, and they do not affect the rest of 871 the protocol description. 873 4.3. Basic Message Processing 875 This section describes how signaling application messages are 876 processed in the case where any necessary messaging associations and 877 routing state are already in place. The description is divided into 878 several parts. Firstly, message reception, local processing and 879 message transmission are described for the case where the node hosts 880 the NSLPID identified in the message. Secondly, the case where the 881 message is handled directly in the IP or GIST layer (because there is 882 no matching signaling application on the node) is given. An overview 883 is given in Figure 3. 885 +---------------------------------------------------------+ 886 | >> Signaling Application Processing >> | 887 | | 888 +--------^---------------------------------------V--------+ 889 ^ V 890 ^ NSLP Payloads V 891 ^ V 892 +--------^---------------------------------------V--------+ 893 | >> GIST >> | 894 | ^ ^ ^ Processing V V V | 895 +--x-----------N--Q---------------------Q--N-----------x--+ 896 x N Q Q N x 897 x N Q>>>>>>>>>>>>>>>>>>>>>Q N x 898 x N Q Bypass at Q N x 899 +--x-----+ +--N--Q--+ GIST level +--Q--N--+ +-----x--+ 900 | C-mode | | D-mode | | D-mode | | C-mode | 901 |Handling| |Handling| |Handling| |Handling| 902 +--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+ 903 x N Q Q N x 904 x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x 905 x N Q Bypass at Q N x 906 +--x--N--+ +-----Q--+ IP (router +--Q-----+ +--N--x--+ 907 |IP Host | | RAO | alert) level | RAO | |IP Host | 908 |Handling| |Handling| |Handling| |Handling| 909 +--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+ 910 x N Q Q N x 911 +--x--N-----------Q--+ +--Q-----------N--x--+ 912 | IP Layer | | IP Layer | 913 | (Receive Side) | | (Transmit Side) | 914 +--x--N-----------Q--+ +--Q-----------N--x--+ 915 x N Q Q N x 916 x N Q Q N x 918 NNNNNNNNNNNNNN = 'Normal' datagram mode messages 919 QQQQQQQQQQQQQQ = Datagram mode messages which 920 are Queries or likewise encapsulated 921 xxxxxxxxxxxxxx = connection mode messages 922 RAO = Router Alert Option 924 Figure 3: Message Paths through a GIST Node 926 4.3.1. Message Reception 928 Messages can be received in connection or datagram mode, and in the 929 latter case with two types of message encapsulation. 931 Reception in connection mode is simple: incoming packets undergo the 932 security and transport treatment associated with the messaging 933 association, and the messaging association provides complete messages 934 to the GIST layer for further processing. 936 Reception in datagram mode depends on the message type. 'Normal' 937 messages arrive UDP encapsulated and addressed directly to the 938 receiving signaling node, at an address and port learned previously. 939 Each datagram contains a single message which is passed to the GIST 940 layer for further processing, just as in the connection mode case. 942 Where GIST is sending messages to be intercepted by the appropriate 943 peer rather than directly addressed to it (in particular, Query 944 messages), these are UDP encapsulated with an IP router alert option. 945 Each signaling node will therefore 'see' all such messages. The case 946 where the NSLPID does not match a local signaling application at all 947 is considered below in Section 4.3.4; otherwise, it is again passed 948 up to the GIST layer for further processing. 950 4.3.2. Local Processing and Validation 952 Once a message has been received, it is processed locally within the 953 GIST layer. The GIST hop count MUST be decremented immediately the 954 message has been received. Further processing depends on the message 955 type and payloads carried; most of the GIST payloads are associated 956 with state maintenance and details are covered in Section 4.4. 958 In the case of a GIST-Query, there is an interaction with signaling 959 application policy to determine which of two courses to follow: 961 1. The signaling application wishes to become a signaling peer with 962 the Querying node. GIST MUST continue with the handshake process 963 to set up message routing state, as described in Section 4.4.1. 964 The application MAY provide an NSLP payload for the same NSLPID, 965 which GIST will transfer in the GIST-Response. 967 2. The signaling application does not wish to set up state with the 968 Querying node and become its peer. GIST MUST propagate the 969 Query, similar to the case described in Section 4.3.4. No 970 message is sent back to the Querying node. The application MAY 971 provide an updated NSLP payload for the same NSLPID (which will 972 be used in the Query message forwarded by GIST). 974 This interaction with the signaling application, including the 975 generation or update of an NSLP payload, SHOULD take place 976 synchronously as part of the Query message processing . In terms of 977 the GIST service interface, this can be implemented by providing 978 appropriate return values for the primitive that is triggered when 979 such a message is received; see Appendix B.2 for further discussion. 981 For all other message types, the GIST payloads are processed as 982 described in Section 4.4. The remainder of the GIST message consists 983 of an NSLP payload, which is delivered locally to the signaling 984 application identified by the NSLPID. The format of the payload is 985 not constrained by GIST, and the content is not interpreted. 986 Delivery is subject to the following validation checks: 988 o if the message was explicitly routed (see Section 7.1.4) or is a 989 Data message delivered without routing state (see Section 5.3.2), 990 the payload is delivered but flagged to the receiving NSLP to 991 indicate that routing state was not validated; 993 o else, if there is no routing state for the MRI/SID/NSLPID the 994 message MUST be rejected with a "No Routing State" error message 995 (Appendix A.4.4.5); 997 o else, if the message arrived on an association which is not 998 associated with the MRI/NSLPID/SID combination given in the 999 message, the message MUST be rejected with an "Incorrectly 1000 Delivered Message" error message (Appendix A.4.4.4); 1002 o else, the payload is delivered as normal. 1004 4.3.3. Message Transmission 1006 Signaling applications can generate their messages for transmission, 1007 either asynchronously, or in response to a normal input message, and 1008 GIST can also generate messages autonomously. Regardless of the 1009 source, outgoing messages are passed downwards for message 1010 transmission. When a message is available for transmission, GIST 1011 uses internal policy and the stored routing state to determine how to 1012 handle it. The following processing applies equally to locally 1013 generated messages and messages forwarded from within the GIST or 1014 signaling application levels. (However, see Section 5.6 for special 1015 rules applying to the transmission of error messages by GIST.) 1017 The main decision is whether the message must be sent in connection 1018 mode or datagram mode. Reasons for using the former are: 1020 o signaling application requirements: for example, it has requested 1021 channel secured delivery, or reliable delivery; 1023 o protocol specification: a message that requires fragmentation MUST 1024 be sent over a messaging association; 1026 o local policy: for example, a node MAY send messages over a 1027 messaging association to benefit from adaptive congestion control. 1029 In principle, as well as determining that some messaging association 1030 must be used, GIST MAY select between a set of alternatives, e.g. for 1031 load sharing or because different messaging associations provide 1032 different transport or security attributes. 1034 If the use of a messaging association is selected, the message is 1035 queued on the association found from the routing state table, and 1036 further output processing is carried out according to the details of 1037 the protocol stacks used. If no appropriate association exists, the 1038 message is queued while one is created (see Section 4.4.1). If no 1039 association can be created, this is an error condition, and should be 1040 indicated back to the local signaling application. 1042 If a messaging association is not required, the message is sent in 1043 datagram mode. The processing in this case depends on the message 1044 type and whether routing state exists or not. 1046 o If the message is not a Query, and routing state exists, it is UDP 1047 encapsulated and sent directly to the address from the routing 1048 state table. 1050 o If the message is a Query, then it is UDP encapsulated with IP 1051 address and router alert option determined from the MRI and NSLPID 1052 (further details depend on the message routing method). 1054 o If no routing state exists, GIST can attempt to use the same 1055 encapsulation as in the Query case. If this is not possible (e.g. 1056 because the encapsulation for the message routing method is only 1057 defined for one message direction), then this is an error 1058 condition which is reported back to the local signaling 1059 application. 1061 4.3.4. Nodes not Hosting the NSLP 1063 A node may receive messages where it has no signaling application 1064 corresponding to the message NSLPID. There are several possible 1065 cases depending mainly on the encapsulation: 1067 1. A Query-encapsulated message contains an RAO value which is 1068 relevant to NSIS but not to the specific node, but the IP layer 1069 is unable to recognise whether it needs to be passed to GIST for 1070 further processing or whether the packet should be forwarded just 1071 like a normal IP datagram. 1073 2. A Query-encapsulated message contains an RAO value which is 1074 relevant to the node, but the specific signaling application 1075 functionality for the actual NSLPID in the message is not 1076 processed there. 1078 3. A directly addressed message (in datagram or connection mode) is 1079 delivered to a node for which there is no corresponding signaling 1080 application. (With the current specification, this should never 1081 happen. While future versions might find a use for such a 1082 feature, currently this MUST cause an "Unknown NSLPID" error 1083 message, Appendix A.4.4.6.) 1085 4. A Query-encapsulated message arrives at the end-system which does 1086 not handle the signaling application. This is possible in normal 1087 operation, and MUST be notified to the sender with an "Endpoint 1088 Found" informational message (Appendix A.4.4.7). The end-system 1089 includes the MRI and SID from the original message in the error 1090 message without interpreting them. 1092 5. The node is GIST-aware NAT. See Section 7.2. 1094 In cases (1) and (2), the role of GIST is to forward the message 1095 essentially unchanged, and it will not become a peer to the node 1096 sending the message. (Forwarding with modified NSLP payloads is 1097 covered above in Section 4.3.2.) However, a GIST implementation must 1098 ensure that the IP TTL field and GIST hop count are managed correctly 1099 to prevent message looping, and this should be done consistently 1100 independently of whether the processing (e.g. for case (1)) takes 1101 place on the fast path or in GIST-specific code. The rules are that 1102 in cases (1) and (2), the IP TTL MUST be decremented just as if the 1103 message was a normal IP forwarded packet; in case (2) the GIST hop 1104 count MUST be decremented as in the case of normal input processing, 1105 which indeed applies to cases (3) and (4). 1107 A GIST node processing Query-encapsulated messages in this way SHOULD 1108 make the routing decision based on the full contents of the MRI and 1109 not only the IP destination address. It MAY also apply a restricted 1110 set of sanity checks and under certain conditions return an error 1111 message rather than forwarding the message. These conditions are: 1113 1. The message is so large that it would be fragmented on downstream 1114 links (e.g. because the downstream MTU is very small). The error 1115 "Message Too Large" (Appendix A.4.4.8) SHOULD be returned to the 1116 sender, which SHOULD begin messaging association setup. 1118 2. The GIST hop count has been exceeded. The error "Hop Limit 1119 Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender, 1120 which MAY retry with a larger initial hop count if it is clear 1121 that a loop has not been formed. 1123 3. The MRI represents a flow definition which is too general to be 1124 forwarded along a unique path (e.g. the destination address 1125 prefix is too short). The error "MRI Validation Failure" 1126 (Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be 1127 returned to the sender, which MAY retry with restricted MRIs, 1128 possibly starting additional signaling sessions to do so. If the 1129 GIST node does not understand the MRM in question it MUST NOT 1130 apply this check, instead forwarding the message transparently. 1132 In the first two cases, only the common header is examined; in the 1133 third case, the MRI is also examined. The rest of the message MUST 1134 never be inspected or modified. 1136 Note that the hop count is only intended to prevent message looping 1137 at the GIST level, and by default NSLPs must take their own measures 1138 to prevent looping at the application level. However, the GIST API 1139 (Appendix B) provides the incoming hop count to the NSLPs, which can 1140 preserve it on outgoing messages as they are forwarded further along 1141 the path. This provides a lightweight loop-prevention mechanism for 1142 NSLPs which do not define anything more sophisticated. 1144 4.4. Routing State and Messaging Association Maintenance 1146 The main responsibility of GIST is to manage the routing state and 1147 messaging associations which are used in the message processing 1148 described above. Routing state is installed and maintained by 1149 specific GIST messages. Messaging associations depend on the 1150 existence of routing state, but are actually set up by the normal 1151 procedures of the transport and security protocols that comprise 1152 them. Timers control routing state and messaging association refresh 1153 and expiration. 1155 There are two different cases for state installation and refresh: 1157 1. Where routing state is being discovered or a new association is 1158 to be established; and 1160 2. Where an existing association can be re-used, including the case 1161 where routing state for the flow is being refreshed. 1163 These cases are now considered in turn, followed by the case of 1164 background general management procedures. 1166 4.4.1. State Setup 1168 The complete sequence of possible messages for state setup between 1169 adjacent peers is shown in Figure 4 and described in detail in the 1170 following text. A concrete example is given in Appendix C. 1172 +----------+ +----------+ 1173 | Querying | |Responding| 1174 | Node | | Node | 1175 +----------+ +----------+ 1176 GIST-Query 1177 ----------------------> ............. 1178 Router Alert Option . Routing . 1179 MRI/SID/NSLPID . state . 1180 Q-Node Network Layer Info . installed . 1181 Query Cookie . at . 1182 [Q-Node Stack-Proposal . R-node(1) . 1183 Q-Node Stack-Config-Data] ............. 1184 [NSLP Payload] 1186 ...................................... 1187 . The responder can use an existing . 1188 . messaging association if available . 1189 . from here onwards to short-circuit . 1190 . messaging association setup . 1191 ...................................... 1193 GIST-Response 1194 ............. <---------------------- 1195 . Routing . MRI/SID/NSLPID 1196 . state . R-Node Network Layer Info (D Mode only) 1197 . installed . Query cookie 1198 . at . [Responder Cookie 1199 . Q-Node . [R-Node Stack-Proposal 1200 ............. R-Node Stack-Config-Data]] 1201 [NSLP Payload] 1203 .................................... 1204 . If a messaging association needs . 1205 . to be created, it is set up here . 1206 .................................... 1208 GIST-Confirm 1209 ----------------------> 1210 MRI/SID/NSLPID ............. 1211 Q-Node Network Layer Info . Routing . 1212 [Responder Cookie . state . 1213 [R-Node Stack-Proposal . installed . 1214 [Q-Node Stack-Config-Data]]] . at . 1215 [NSLP Payload] . R-node(2) . 1216 ............. 1218 Figure 4: Message Sequence at State Setup 1219 The initial message in any routing state maintenance operation is a 1220 GIST-Query message, sent from the querying node and intercepted at 1221 the responding node. This message has addressing and other 1222 identifiers appropriate for the flow and signaling application that 1223 state maintenance is being done for, addressing information about the 1224 node itself, and it MAY contain an NSLP payload. It also includes a 1225 Query Cookie, and optionally capability information about messaging 1226 association protocol stacks. The role of the cookies in this and 1227 subsequent messages is to protect against certain denial of service 1228 attacks and to correlate the various events in the message sequence. 1230 Provided that the signaling application has indicated that message 1231 routing state should be set up (see Section 4.3.2), reception of a 1232 GIST-Query MUST elicit a GIST-Response message. This is a 'normally' 1233 encapsulated datagram mode message with additional payloads. It 1234 contains network layer information about the responding node, echoes 1235 the Query Cookie, and MAY contain an NSLP payload (possibly a 1236 response to the NSLP payload in the initial message). In case a 1237 messaging association was requested, it MUST also contain a Responder 1238 Cookie and its own capability information about messaging association 1239 protocol stacks. Even if a messaging association is not requested, 1240 the Response MAY still include a Responder Cookie if the node's 1241 routing state setup policy requires it (see below). 1243 Setup of a new messaging association begins when peer addressing 1244 information is available and a new messaging association is actually 1245 needed. The setup MUST be contemporaneous with a specific GIST- 1246 Query/Response exchange, because the addressing information used may 1247 have a limited lifetime (either because it depends on limited 1248 lifetime NAT bindings, or because it refers to agile destination 1249 ports for the transport protocols). The Stack-Proposal and Stack- 1250 Configuration-Data objects carried in the exchange carry capability 1251 information about what messaging association protocols can be used, 1252 and the processing of these objects is described in more detail in 1253 Section 5.7. With the protocol options currently defined, setup of 1254 the messaging association always starts from the Querying node, 1255 although more flexible configurations are possible within the overall 1256 GIST design. In any case, once set up the association itself can be 1257 used equally in both directions. 1259 Finally, a GIST-Confirm MUST be sent if the GIST-Response requested 1260 it. If a messaging association is being used, the GIST-Confirm MUST 1261 be sent over it before any other messages for the same flow, and it 1262 echoes the Responder Cookie and Stack-Proposal from the GIST- 1263 Response. The former is used to allow the receiver to validate the 1264 contents of the message (see Section 8.5), and the latter is to 1265 prevent certain bidding-down attacks on messaging association 1266 security. The Confirm MAY also contain an abbreviated form of the 1267 original Stack-Configuration-Data to finalise details of the 1268 messaging association configuration. The association can be used in 1269 the upstream direction for that MRI and NSLPID after the Confirm has 1270 been received. 1272 The querying node MUST install the responder address as routing state 1273 information after verifying the Query Cookie in the GIST-Response. 1274 The responding node MAY install the querying address as peer state 1275 information at two points in time: 1277 1. after the receipt of the initial GIST-Query, or 1279 2. after a GIST-Confirm message containing the Responder Cookie. 1281 The precise constraints on when state information is installed are a 1282 matter of security policy considerations on prevention of denial-of- 1283 service attacks and state poisoning attacks, which are discussed 1284 further in Section 8. Because the responding node MAY choose to 1285 delay state installation as in case (2), the GIST-Confirm must 1286 contain sufficient information to allow it to be processed 1287 identically to the original Query. This places some special 1288 requirements on NAT traversal and cookie functionality, which are 1289 discussed in Section 7.2 and Section 8 respectively. 1291 4.4.2. Association Re-use 1293 It is a design goal of GIST that, so far as possible, messaging 1294 associations should be re-used for multiple flows and sessions, 1295 rather than a new association set up for each. This is to ensure 1296 that the association cost scales only like the number of peers, and 1297 to avoid the latency of new association setup where possible. 1299 However, re-use requires the identification of an existing 1300 association which matches the same routing state and desired 1301 properties that would be the result of a full handshake in D-mode, 1302 and this identification must be done as reliably and securely as 1303 continuing with the full procedure. Note that this requirement is 1304 complicated by the fact that NATs may remap the node addresses in 1305 D-mode messages, and also interacts with the fact that some nodes may 1306 peer over multiple interfaces (and so with different addresses). 1308 Association re-use is controlled by the Network-Layer-Information 1309 (NLI) object, which is carried in GIST-Query/Confirm and optionally 1310 GIST-Response messages. The NLI object includes: 1312 Peer-Identity: For a given node, this is an interface independent 1313 value with opaque syntax. It MUST be chosen so as to have a high 1314 probability of uniqueness between peers, and SHOULD be stable (at 1315 least between restarts). Note that there is no cryptographic 1316 protection of this identity (attempting to provide this would 1317 essentially duplicate the functionality in the messaging 1318 association security protocols). 1320 Interface-Address: This is an IP address through which the signaling 1321 node can be reached. There may be several choices available for 1322 the Interface-Address, and further discussion of this is contained 1323 in Section 5.2.2. 1325 By default, a messaging association is associated with the NLI object 1326 that was provided by the peer in the Query/Response/Confirm at the 1327 time the association was set up. There may be more than one 1328 association for a given NLI object (e.g. with different properties). 1330 Association re-use is controlled by matching the NLI provided in a 1331 GIST message with those associated with existing associations. This 1332 can be done on receiving either a GIST-Query or GIST-Response (the 1333 former is more likely): 1335 o If there is a perfect match to the NLI of an existing association, 1336 that association SHOULD be re-used (provided it has the 1337 appropriate properties in other respects). This is indicated by 1338 sending the remaining messages in the handshake over that 1339 association. This will only fail (i.e. lead to re-use of an 1340 association to the 'wrong' node) if signaling nodes have colliding 1341 Peer-Identities, and one is reachable at the same Interface- 1342 Address as another. (This could be done by an on-path attacker.) 1344 o In all other cases, the full handshake MUST be executed in 1345 datagram mode as usual. There are in fact four possibilities: 1347 1. Nothing matches: this is clearly a new peer. 1349 2. Only the Peer-Identity matches: this may be either a new 1350 interface on an existing peer, or a changed address mapping 1351 behind a NAT, or an attacker attempting to hijack the Peer- 1352 Identity. These should be rare events, so the expense of a 1353 new association setup is acceptable. 1355 3. Only the Interface-Address matches: this is probably a new 1356 peer behind the same NAT as an existing one. A new 1357 association setup is required. 1359 4. The full NLI object matches: this is a degenerate case, where 1360 one node recognises an existing peer, but wishes to allow the 1361 option to set up a new association in any case (for example to 1362 create an association with different properties). 1364 4.4.3. State Maintenance Procedures 1366 Refresh and expiration of all types of state is controlled by timers. 1368 Each item of routing state expires after a validity lifetime which is 1369 negotiated during the Query/Response/Confirm handshake. The NLI 1370 object in the Query contains a proposal for the lifetime value, and 1371 the NLI in the Response contains the value the Responding node 1372 requires. The Querying node MUST generate a GIST-Query message 1373 before this timer expires, if it believes that the flow is still 1374 active; otherwise, the Responding node MAY delete the state. Receipt 1375 of the message at the Responding node will refresh peer addressing 1376 state for one direction, and receipt of a GIST-Response at the 1377 querying node will refresh it for the other. There is no mechanism 1378 at the GIST level for explicit teardown of routing state. However, 1379 GIST MUST NOT refresh routing state if a flow is known to be 1380 inactive, either because upstream state has expired, or because the 1381 signaling application has indicated via the GIST API (Appendix B.5) 1382 that the state is no longer required, because this would prevent 1383 correct state repair in the case of network rerouting. 1385 Unneeded messaging associations are torn down by GIST, using the 1386 teardown mechanisms of the underlying transport or security protocols 1387 if available (for example, simply by closing a TCP connection). The 1388 teardown can be initiated by either end. Whether an association is 1389 needed is a combination of two factors: 1391 o local policy, which could take into account the cost of keeping 1392 the messaging association open, the level of past activity on the 1393 association, and the likelihood of future activity (e.g. if there 1394 is routing state still in place which might generate messages to 1395 use it). 1397 o whether the peer still wants the association in place. During 1398 messaging association setup, each node indicates its own MA-Hold- 1399 Time as part of the Stack-Configuration-Data. (Because the 1400 Responding node can choose not to retain state until a Confirm 1401 message, an abbreviated Stack-Configuration-Data object containing 1402 just this information MUST be repeated by the Querying node in the 1403 first Confirm sent on a new messaging association.) A node MUST 1404 NOT tear down the association if it has received traffic from its 1405 peer over that period. A peer which has generated no traffic but 1406 still wants the association retained SHOULD use a special 'null' 1407 message (GIST-MA-Hello) to indicate the fact. 1409 Messaging associations can always be set up on demand, and messaging 1410 association status is not made directly visible outside the GIST 1411 layer. Therefore, even if GIST tears down and later re-establishes a 1412 messaging association, signaling applications cannot distinguish this 1413 from the case where the association is kept permanently open. To 1414 maintain the transport semantics described in Section 4.1, GIST MUST 1415 close transport connections carrying reliable messages gracefully or 1416 report an error condition, and MUST NOT open a new association for a 1417 given session and peer while messages on a previous association may 1418 still be outstanding. 1420 This specification defines precisely only the time at which state or 1421 messaging associations expire; it does not define when refresh 1422 transactions should be initiated. Implementations SHOULD select 1423 timer settings which take at least the following into account: 1425 o The transmission latency between source and destination; 1427 o The need for retransmissions (either explicitly or within the 1428 messaging association protocols); 1430 o The need to avoid network synchronisation of control traffic (cf. 1431 [34]). 1433 In most cases, a reasonable policy is (for example) to initiate the 1434 refresh process when between 1/2 and 3/4 of the appropriate validity 1435 time has elapsed since the last successful refresh. The actual 1436 moment is chosen randomly within this interval to avoid 1437 synchronisation effects. 1439 5. Message Formats and Transport 1441 5.1. GIST Messages 1443 All GIST messages begin with a common header, followed by a sequence 1444 of type-length-value (TLV) objects. This subsection describes the 1445 various GIST messages and their contents at a high level; a more 1446 detailed description of the header and each object is given in 1447 Section 5.2. 1449 The common header includes a version number, message type and size, 1450 and NSLPID. It also carries a hop count to prevent message looping 1451 and various control flags, including one to indicate if a reply of 1452 some sort is requested. The objects following the common header MUST 1453 be carried in a fixed order, depending on message type. Messages 1454 with missing, duplicate or invalid objects for the message type MUST 1455 be rejected with an "Object Type Error" error message with the 1456 appropriate subcode (Appendix A.4.4.9). 1458 The following gives the basic syntax of GIST messages in ABNF [7]. 1459 Note that the NAT traversal mechanism for GIST involves the insertion 1460 of an additional NAT-Traversal object in certain messages; the rules 1461 for this are given in Section 7.2. 1463 GIST-Message: The main messages are either one of the stages in the 1464 3-way handshake, or a simple message carrying NSLP data. Additional 1465 types are allocated for errors and messaging association keepalive. 1467 GIST-Message = GIST-Query / GIST-Response / 1468 GIST-Confirm / GIST-Data / 1469 GIST-Error / GIST-MA-Hello 1471 GIST-Query: A GIST-Query MUST be sent in datagram mode. As well as 1472 the common header, it contains certain mandatory control objects, and 1473 MAY contain a signaling application payload. A stack proposal and 1474 configuration data MUST be included if the message exchange relates 1475 to setup of a messaging association. The R flag MUST always be set 1476 (R=1) in a Query, since this message always elicits a Response. 1478 GIST-Query = Common-Header 1479 Message-Routing-Information 1480 Session-Identification 1481 Network-Layer-Information 1482 Query-Cookie 1483 [ Stack-Proposal Stack-Configuration-Data ] 1484 [ NSLP-Data ] 1486 GIST-Response: A GIST-Response may be sent in datagram or connection 1487 mode (if a messaging association is being re-used). It MUST echo the 1488 MRI (with inverted direction), SID and Query-Cookie of the Query, and 1489 in D-mode carries its own Network-Layer-Information; if the message 1490 exchange relates to setup of a messaging association (which can only 1491 take place in datagram mode), a Responder cookie MUST be included, as 1492 well as its own stack proposal and configuration data. The R flag 1493 MUST be set (R=1) if a Responder cookie is present but otherwise is 1494 optional; if the R flag is set, a Confirm MUST be sent as a reply. 1496 GIST-Response = Common-Header 1497 Message-Routing-Information 1498 Session-Identification 1499 [ Network-Layer-Information ] 1500 Query-Cookie 1501 [ Responder-Cookie 1502 [ Stack-Proposal Stack-Configuration-Data ] ] 1503 [ NSLP-Data ] 1505 GIST-Confirm: A GIST-Confirm may be sent in datagram or connection 1506 mode (if a messaging association has been re-used). It MUST echo the 1507 MRI (with inverted direction), SID, and Responder-Cookie if the 1508 Response carried one; if the message exchange relates to setup of a 1509 new messaging association or reuse of an existing one (which can only 1510 take place in connection mode), the message MUST also echo the Stack- 1511 Proposal from the GIST-Response so it can be verified that this has 1512 not been tampered with. The first message on an association MUST 1513 also repeat the Stack-Configuration-Data from the original Query in 1514 an abbreviated form (just containing the MA-Hold-Time). 1516 GIST-Confirm = Common-Header 1517 Message-Routing-Information 1518 Session-Identification 1519 Network-Layer-Information 1520 [ Responder-Cookie 1521 [ Stack-Proposal 1522 [ Stack-Configuration-Data ] ] ] 1523 [ NSLP-Data ] 1525 GIST-Data: A plain data message contains no control objects, but only 1526 the MRI and SID associated with the NSLP data being transferred. 1527 Network-Layer-Information MUST be carried in the datagram mode case 1528 and not otherwise. 1530 GIST-Data = Common-Header 1531 Message-Routing-Information 1532 Session-Identification 1533 [ Network-Layer-Information ] 1534 NSLP-Data 1536 GIST-Error: A GIST-Error message reports a problem determined at the 1537 GIST level. (Errors generated by signaling applications are reported 1538 in NSLP-Data payloads and are not treated specially by GIST.) The 1539 message includes a Network-Layer-Information object for the 1540 originator of the error message it if is being sent in datagram mode; 1541 all other information related to the error is carried in a GIST- 1542 Error-Data object. 1544 GIST-Error = Common-Header 1545 [ Network-Layer-Information ] 1546 GIST-Error-Data 1548 GIST-MA-Hello: This message MUST be sent only in C-Mode to indicate 1549 that a node wishes to keep a messaging association open. It contains 1550 only the common header, with a null NSLPID. The R flag MAY be set 1551 (R=1) to indicate that a reply is requested, thus allowing a node to 1552 test the liveness of the peer. 1554 GIST-MA-Hello = Common-Header 1556 5.2. Information Elements 1558 This section describes the content of the various objects that can be 1559 present in each GIST message, both the common header, and the 1560 individual TLVs. The bit formats are provided in Appendix A. 1562 5.2.1. The Common Header 1564 Each message begins with a fixed format common header, which contains 1565 the following information: 1567 Version: The version number of the GIST protocol. 1569 Length: The number of 32 bit words in the message following the 1570 common header. 1572 Upper layer identifier (NSLPID): This gives the specific NSLP that 1573 this message is used for. 1575 GIST hop counter: A hop counter to prevent a message from looping. 1577 Message type: The message type (Query, Response, etc.) 1579 Source addressing mode: If set (S=1), this indicates that the IP 1580 source address of the message is the same as the signaling source 1581 address, in which case replies to this message can be sent safely 1582 to this address. It is cleared (S=0) if the IP source address was 1583 derived from the message routing information in the payload and 1584 this is different from the signaling source address. 1586 Response requested: A flag which if set (R=1) indicates that a 1587 message should be sent in response to this message. 1589 Explicit routing: A flag which if set (E=1) indicates that the 1590 message was explicitly routed (see Section 7.1.4). 1592 5.2.2. TLV Objects 1594 All data following the common header is encoded as a sequence of 1595 type-length-value objects. Currently, each object can occur at most 1596 once; the set of required and permitted objects is determined by the 1597 message type and encapsulation. 1599 Message-Routing-Information (MRI): Information sufficient to define 1600 how the signaling message should be routed through the network. 1602 Message-Routing-Information = message-routing-method 1603 method-specific-information 1605 The format of the method-specific-information depends on the 1606 message-routing-method requested by the signaling application. It 1607 is provided by the NSLP in the message sender and used by GIST to 1608 select the message routing. 1610 Session-Identification (SID): The GIST session identifier is a 128 1611 bit, cryptographically random identifier chosen by the node which 1612 originates the signaling exchange. See Section 3.4. 1614 Network-Layer-Information: This object carries information about the 1615 network layer attributes of the node sending the message, 1616 including data related to the management of routing state. This 1617 includes a peer identity and IP address for the sending node. It 1618 also includes IP TTL information to allow the hop count between 1619 GIST peers to be measured and reported, and a validity time for 1620 the routing state. 1622 Network-Layer-Information = peer-identity 1623 interface-address 1624 RS-validity-time 1625 IP-TTL 1627 The use of the RS-validity-time field is described in 1628 Section 4.4.3. The peer-identity and interface-address are used 1629 for matching existing associations, as discussed in Section 4.4.2. 1631 The interface-address must be routable, i.e. it MUST be usable as 1632 a destination IP address for packets to be sent back to the node 1633 generating the signaling message (whether in datagram or 1634 connection mode). Where this object is carried in a GIST-Query or 1635 GIST-Confirm, the interface-address MUST specifically be set to an 1636 address bound to the interface associated with the MRI (e.g. the 1637 one carrying the outbound flow), to allow its use in route change 1638 handling, see Section 7.1. A node may have several choices for 1639 which of its addresses to use as the interface-address. For 1640 example, there may be a choice of IP versions, or addresses of 1641 limited scope (e.g. link-local), or addresses bound to different 1642 interfaces in the case of a router or multi-homed host. However, 1643 some of these interface addresses may not be usable by the peer. 1644 A node SHOULD follow a default policy of using a global address of 1645 the same IP version as in the MRI, unless it can establish that an 1646 alternative address would also be usable. 1648 The setting and interpretation of the IP-TTL field depends on the 1649 message direction (as determined from the MRI) and encapsulation. 1651 * If the message is downstream, the IP-TTL MUST be set to the TTL 1652 that will be set in the IP header for the message (if this can 1653 be determined), or else set to 0. 1655 * On receiving a downstream message in datagram mode, a non-zero 1656 IP-TTL is compared to the TTL in the IP header, and the 1657 difference is stored as the IP-hop-count-to-peer for the 1658 upstream peer in the routing state table for that flow. 1659 Otherwise, the field is ignored. 1661 * If the message is upstream, the IP-TTL MUST be set to the value 1662 of the IP-hop-count-to-peer stored in the routing state table, 1663 or 0 if there is no value yet stored. 1665 * On receiving an upstream message, the IP-TTL is stored as the 1666 IP-hop-count-to-peer for the downstream peer. 1668 In all cases, the TTL value reported to signaling applications is 1669 the one stored with the routing state for that flow, after it has 1670 been updated (if appropriate) from processing the message in 1671 question. 1673 Stack-Proposal: This field contains information about which 1674 combinations of transport and security protocols are available for 1675 use in messaging associations, and is also discussed further in 1676 Section 5.7. 1678 Stack-Proposal = 1*stack-profile 1679 stack-profile = 1*protocol-layer 1681 Each protocol-layer field identifies a protocol with a unique tag; 1682 any additional data (e.g. higher-layer addressing or other options 1683 data) associated with the protocol will be carried in a MA- 1684 protocol-options field in the Stack-Configuration-Data TLV (see 1685 below). 1687 Stack-Configuration-Data: This object carries information about the 1688 overall configuration of a messaging association. 1690 Stack-Configuration-Data = MA-Hold-Time 1691 0*MA-protocol-options 1693 The MA-Hold-Time field indicates how long a node will hold open an 1694 inactive association; see Section 4.4.3 for more discussion. The 1695 MA-protocol-options fields give the configuration of the protocols 1696 to be used for new messaging associations, and they are described 1697 in more detail in Section 5.7. 1699 Query-Cookie/Responder-Cookie: A Query-Cookie is contained in a GIST- 1700 Query message and MUST be echoed in a GIST-Response; a Responder- 1701 Cookie MAY be sent in a GIST-Response message, and if present MUST 1702 be echoed in the following GIST-Confirm message. Cookies are 1703 variable length (chosen by the cookie generator). See Section 8.5 1704 for further details on requirements and mechanisms for cookie 1705 generation. 1707 NSLP-Data: The NSLP payload to be delivered to the signaling 1708 application. GIST does not interpret the payload content. 1710 GIST-Error-Data: This contains all the information to determine the 1711 cause and context of an error. 1713 GIST-Error-Data = error-class error-code error-subcode 1714 common-header 1715 [ Message-Routing-Information-content ] 1716 [ Session-Identification-content ] 1717 0*additional-information 1718 [ comment ] 1720 The error-class indicates the severity level, and the error-code 1721 and error-subcode identify the specific error itself. A full list 1722 of GIST errors and their severity levels is given in Appendix A.4. 1723 The common-header from the original message is always included, as 1724 are the contents of the Message-Routing-Information and Session- 1725 Identification objects if they were successfully decoded. For 1726 some errors, additional information fields must be included 1727 according to a fixed format; finally, an optional free-text 1728 comment may be added. 1730 5.3. Datagram Mode Transport 1732 This section describes the various encapsulation options for datagram 1733 mode messages. Although there are several possibilities, depending 1734 on message type, message routing method, and local policy, the 1735 general design principle is that the sole purpose of the 1736 encapsulation is to ensure that the message is delivered to or 1737 intercepted at the correct peer. Beyond that, minimal significance 1738 is attached to the type of encapsulation or the values of addresses 1739 or ports used for it. This allows new options to be developed in the 1740 future to handle particular deployment requirements without modifying 1741 the overall protocol specification. 1743 5.3.1. Normal Encapsulation 1745 Normal encapsulation MUST be used for all datagram mode messages 1746 where the signaling peer is already known from previous signaling. 1747 This includes Response and Confirm messages, and Data messages except 1748 if these are being sent without using local routing state. Normal 1749 encapsulation is simple: the complete set of GIST payloads is 1750 concatenated together with the common header, and placed in the data 1751 field of a UDP datagram. UDP checksums MUST be enabled. The message 1752 is IP addressed directly to the adjacent peer; the UDP port numbering 1753 MUST be compatible with that used on Query messages (see below), that 1754 is, the same for messages in the same direction and swapped 1755 otherwise. 1757 5.3.2. Query Encapsulation 1759 Query encapsulation MUST be used for messages where no routing state 1760 is available or where the routing state is being refreshed, in 1761 particular for GIST-Query messages. Query encapsulation is similar 1762 to normal encapsulation, with changes in IP address selection, IP 1763 options, and a defined method for selecting UDP ports. 1765 In general, the IP addresses are derived from information in the MRI; 1766 the exact rules depend on the message routing method. In addition, 1767 the IP header is given a Router Alert Option ([1] and [4]) to assist 1768 the peer in intercepting the message depending on the NSLPID. Each 1769 NSLPID corresponds to a unique RAO value, but not necessarily vice 1770 versa; further details are discussed in [36]. 1772 The source UDP port is selected by the message sender as the port at 1773 which it is prepared to receive UDP messages in reply, and a 1774 destination UDP port is allocated by IANA (see Section 9). Note that 1775 GIST may send messages addressed as {flow sender, flow receiver} 1776 which could make their way to the flow receiver even if that receiver 1777 were GIST-unaware. These should be rejected (with an ICMP message) 1778 rather than delivered to the user application (which would be unable 1779 to use the source address to identify it as not being part of the 1780 normal data flow). Therefore, a "well-known" port is required. 1782 5.3.3. Retransmission and Rate-Control 1784 Datagram mode uses UDP, and hence has no automatic reliability or 1785 congestion control capabilities. Signaling applications requiring 1786 reliability should be serviced using C-mode, which should also carry 1787 the bulk of signaling traffic. However, some form of messaging 1788 reliability is required for the GIST control messages themselves, as 1789 is rate control to handle retransmissions and also bursts of 1790 unreliable signaling or state setup requests from the signaling 1791 applications. 1793 Query messages which do not receive Responses MAY be retransmitted; 1794 retransmissions MUST use a binary exponential backoff, with an 1795 initial timeout of T1 up to a maximum of T2 seconds. Retransmitted 1796 Queries MUST use different Query-Cookie values. These rules apply 1797 equally to the message that first creates routing state, and those 1798 that refresh it. The values of T1 and T2 are implementation defined. 1799 Note that Queries may go unanswered either because of message loss 1800 (in either direction), or because there is no reachable GIST peer. 1801 Therefore, implementations should trade off reliability (large T2) 1802 against promptness of error feedback to applications (small T2). If 1803 the Query message carries NSLP data, it may be delivered multiple 1804 times to the signaling application. If the NSLP has indicated a 1805 timeout on the validity of this payload (see Appendix B.1), T2 SHOULD 1806 be chosen to be less than this value. 1808 This algorithm is sufficient to handle lost Queries and Responses. 1809 The case of a lost Confirm is more subtle. Notionally, we can 1810 distinguish between two cases: 1812 1. Where the Responding node is already prepared to store per-flow 1813 state after receiving a single (Query) message. This would 1814 include any cases where the node has NSLP data queued to send. 1815 Here, the Responding node MAY run a retransmission timer to 1816 resend the Response message until a Confirm is received, since 1817 the node is already managing state for that flow. The problem of 1818 an amplification attack stimulated by a malicious Query is 1819 handled by requiring the cookie mechanism to enable the node 1820 receiving the Response to discard it efficiently if it does not 1821 match a previously sent Query. 1823 2. Where the responding node is not prepared to store per-flow state 1824 until receiving a properly formed Confirm message. 1826 In case (2), a retransmission timer should not be required. However, 1827 we can assume that the next signaling message will be in the 1828 direction Querying Node -> Responding Node (if there is no 'next 1829 signaling message' the fact that the Confirm has been lost is moot). 1830 In this case, the responding node will start to receive messages at 1831 the GIST level for a MRI/NSLP combination for which there is no 1832 stored routing state (since this state is only created on receipt of 1833 a Confirm). 1835 Therefore, the error condition is detected at the Responding node 1836 when such a message arrives, without the need for a specific timer. 1837 Recovery requires a Confirm to be transmitted and successfully 1838 received. The mechanism to cause this is that the Responding node 1839 MUST reject the incoming message with a "No Routing State" error 1840 message (Appendix A.4.4.5) back to the Querying node, which MUST 1841 interpret this as caused by a lost Confirm; the Querying node MUST 1842 regenerate the Confirm purely from local state (e.g. in particular it 1843 needs to remember a valid Responder Cookie). 1845 In all cases, Responses MUST be sent promptly to avoid spurious 1846 retransmissions. Nodes generating any type of retransmission MUST be 1847 prepared to receive (and match) a reply to any of them (not just the 1848 one most recently sent). 1850 The basic rate-control requirements for datagram mode traffic are 1851 deliberately minimal. A single rate limiter applies to all traffic 1852 (for all interfaces and message types). It applies to 1853 retransmissions as well as new messages, although an implementation 1854 MAY choose to prioritise one over the other. When the rate limiter 1855 is in effect, datagram mode messages are queued until transmission is 1856 re-enabled, or an error condition MAY be indicated back to local 1857 signaling applications. The rate limiting mechanism is 1858 implementation defined, but it is RECOMMENDED that a token bucket 1859 limiter as described in [26] be used. 1861 5.4. Connection Mode Transport 1863 Encapsulation in connection mode is more complex, because of the 1864 variation in available transport functionality. This issue is 1865 treated in Section 5.4.1. The actual encapsulation is given in 1866 Section 5.4.2. 1868 5.4.1. Choice of Transport Protocol 1870 It is a general requirement of the NTLP defined in [22] that it 1871 should be able to support bundling (of small messages), fragmentation 1872 (of large messages), and message boundary delineation. Not all 1873 transport protocols natively support all these features. 1875 TCP provides both bundling and fragmentation, but not message 1876 boundaries. However, the length information in the common header 1877 allows the message boundary to be discovered during parsing. 1879 SCTP [12] satisfies all requirements. 1881 DCCP [25] is message based but does not provide bundling or 1882 fragmentation. Bundling can be carried out by the GIST layer 1883 sending multiple messages in a single datagram; because the common 1884 header includes length information, the message boundaries within 1885 the datagram can be discovered during parsing. Fragmentation of 1886 GIST messages over multiple datagrams should be avoided, because 1887 of amplification of message loss rates that this would cause. 1889 The bundling together of small messages is either built into the 1890 transport protocol or can be carried out by the GIST layer during 1891 message construction. Either way, two approaches can be 1892 distinguished: 1894 1. As messages arrive for transmission they are gathered into a 1895 bundle until a size limit is reached or a timeout expires (cf. 1896 the Nagle algorithm of TCP or similar optional functionality in 1897 SCTP). This provides maximal efficiency at the cost of some 1898 latency. 1900 2. Messages awaiting transmission are gathered together while the 1901 node is not allowed to send them (e.g. because it is congestion 1902 controlled). 1904 The second type of bundling is always appropriate. For GIST, the 1905 first type SHOULD NOT be used for 'trigger' (i.e. state-changing) 1906 messages, but may be appropriate for refresh messages. These 1907 distinctions are known only to the signaling applications, but MAY be 1908 indicated (as an implementation issue) by setting the priority 1909 transfer attribute. 1911 It can be seen that all of these transport protocol options can be 1912 supported by the basic GIST message format already presented. GIST 1913 messages requiring fragmentation must be carried using a reliable 1914 transport protocol, TCP or SCTP. This specification defines only the 1915 use of TCP, but other possibilities could be included without 1916 additional work on message formatting. 1918 5.4.2. Encapsulation Format 1920 The GIST message, consisting of common header and TLVs, is carried 1921 directly in the transport protocol (possibly incorporating transport 1922 layer security protection). Further messages can be carried in a 1923 continuous stream (for TCP), or up to the next transport layer 1924 message boundary (for SCTP/DCCP/UDP). This situation is shown in 1925 Figure 5. 1927 +---------------------------------------------+ 1928 | L2 Header | 1929 +---------------------------------------------+ 1930 | IP Header | ^ 1931 | Source address = signaling source | ^ 1932 | Destination address = signaling destination | . 1933 +---------------------------------------------+ . 1934 | L4 Header | . ^ 1935 | (Standard TCP/SCTP/DCCP/UDP header) | . ^ 1936 +---------------------------------------------+ . . 1937 | GIST Message | . . ^ 1938 | (Common header and TLVs as in section 5.1) | . . ^ Scope of 1939 +---------------------------------------------+ . . . security 1940 | Additional GIST messages, each with its | . . . protection 1941 | own common header, either as a continuous | . . . (depending 1942 | stream, or continuing to the next L4 | . . . on channel 1943 . message boundary . . . . security 1944 . . V V V mechanism 1945 . . V V V in use) 1947 Figure 5: Connection Mode Encapsulation 1949 5.5. Message Type/Encapsulation Relationships 1951 GIST has four primary message types (Query/Response/Confirm/Data) and 1952 three possible encapsulation methods (D-Mode Normal/D-Mode Query/ 1953 C-Mode). For information, the possible combinations of message type 1954 and encapsulation are given in the table below. In some cases there 1955 are several possible choices, depending on the existence of routing 1956 state or messaging associations. The rules governing GIST policy, 1957 including whether or not to create such state to handle a message, 1958 are described normatively in the other sections of this 1959 specification. If a message arrives with an invalid encapsulation 1960 (e.g. a Query arrives over a messaging association), this MUST be 1961 rejected with an "Incorrect Encapsulation" error message 1962 (Appendix A.4.4.3). However, it should be noted that the processing 1963 of the message at the receiver is not otherwise affected by the 1964 encapsulation method used, with the exception that the decapsulation 1965 process may provide additional information (e.g. translated addresses 1966 or IP hop count) which is used in the subsequent message processing. 1968 +---------------+---------------+-------------------+---------------+ 1969 | Message | D-Mode Normal | D-Mode Query | C-Mode | 1970 +---------------+---------------+-------------------+---------------+ 1971 | GIST-Query | Never | Always | Never | 1972 | | | | | 1973 | GIST-Response | Unless a | Never | If a | 1974 | | messaging | | messaging | 1975 | | association | | association | 1976 | | is being | | is being | 1977 | | re-used | | re-used | 1978 | | | | | 1979 | GIST-Confirm | Unless a | Never | If a | 1980 | | messaging | | messaging | 1981 | | association | | association | 1982 | | has been set | | has been set | 1983 | | up or is | | up or is | 1984 | | being re-used | | being re-used | 1985 | | | | | 1986 | GIST-Data | If routing | If no routing | If a | 1987 | | state exists | state exists and | messaging | 1988 | | for the flow | the MRI can be | association | 1989 | | but no | used to derive | exists | 1990 | | messaging | the query | | 1991 | | association | encapsulation | | 1992 +---------------+---------------+-------------------+---------------+ 1994 5.6. Error Message Processing 1996 Special rules apply to the encapsulation and transmission of error 1997 messages. 1999 GIST only generates error messages in response to incoming messages. 2000 (Error messages MUST NOT be generated in response to incoming error 2001 messages.) The routing and encapsulation of the error message is 2002 derived from that of the message that caused the error; in 2003 particular, local routing state is not consulted. Routing state and 2004 messaging association state MUST NOT be created to handle the error, 2005 and error messages MUST NOT be retransmitted explicitly by GIST, 2006 although they are subject to the same rate control as other messages. 2008 o If the incoming message was received in datagram mode, the error 2009 MUST be sent in datagram mode using the 'normal' encapsulation, 2010 using the addressing information from the NLI object in the 2011 incoming message. If the NLI could not be determined, the error 2012 MUST be sent to the IP source of the incoming message if the S 2013 flag was set in it. The NLI object in the GIST-Error message 2014 reports information about the generator of the error. 2016 o If the incoming message was received over a messaging association, 2017 the error MUST be sent back over the same messaging association. 2019 The NSLPID in the common header of the GIST-Error is the null value 2020 (as for GIST-MA-Hello). If for any reason the error message cannot 2021 be sent (for example, because an error message is too large to send 2022 in datagram mode), an error should be logged locally. 2024 5.7. Messaging Association Setup 2026 5.7.1. Overview 2028 A key attribute of GIST is that it is flexible in its ability to use 2029 existing transport and security protocols. Different transport 2030 protocols may have performance attributes appropriate to different 2031 environments; different security protocols may fit appropriately with 2032 different authentication infrastructures. Even given an initial 2033 default mandatory protocol set for GIST, the need to support new 2034 protocols in the future cannot be ruled out, and secure feature 2035 negotiation cannot be added to an existing protocol in a backwards- 2036 compatible way. Therefore, some sort of capability discovery is 2037 required. 2039 Capability discovery is carried out in GIST-Query/Response messages, 2040 using Stack-Proposal and Stack-Configuration-Data objects. If a new 2041 messaging association is required it is then set up, followed by a 2042 GIST-Confirm. Messaging association re-use is achieved by short- 2043 circuiting this exchange by sending the GIST-Response or GIST-Confirm 2044 messages on an existing association (Section 4.4.2); whether to do 2045 this is a matter of local policy. The end result of this process is 2046 a messaging association which is a stack of protocols. If multiple 2047 associations exist, it is a matter of local policy how to distribute 2048 messages over them, subject to respecting the transfer attributes 2049 requested for each message. 2051 Every possible protocol for a messaging association has the following 2052 attributes: 2054 o MA-Protocol-ID, a 1-byte IANA assigned value (see Section 9). 2056 o A specification of the (non-negotiable) policies about how the 2057 protocol should be used (for example, in which direction a 2058 connection should be opened). 2060 o [Depending on the specific protocol:] Formats for an MA-protocol- 2061 options field to carry the protocol addressing and other 2062 configuration information in the Stack-Configuration-Data object. 2063 The format may differ depending on whether the field is present in 2064 the Query or Response. Some protocols do not require the 2065 definition of such additional data, in which case no corresponding 2066 MA-protocol-options field will occur in the SCD object. 2068 A Stack-Proposal object is simply a list of profiles; each profile is 2069 a sequence of MA-Protocol-IDs. A profile lists the protocols in 'top 2070 to bottom' order (e.g. TLS over TCP, or TCP over IPsec, etc.) A 2071 Stack-Proposal is generally accompanied by a Stack-Configuration-Data 2072 object which carries an MA-protocol-options field for any protocol 2073 listed in the Stack-Proposal which needs it. An MA-protocol-options 2074 field may apply globally (to all instances of the protocol in the 2075 Stack-Proposal) or be tagged as applying to a specific instance; for 2076 example, this can be used to carry different port numbers for TCP 2077 depending on whether it is to be used with or without TLS. An MA- 2078 protocol-options field may also be flagged as 'not usable'; for 2079 example, a NAT which could not handle SCTP would set this in an MA- 2080 protocol-options field about SCTP. A protocol flagged this way MUST 2081 NOT be used for a messaging association. If the Stack-Proposal and 2082 Stack-Configuration-Data are both present but not consistent (e.g. 2083 they refer to different protocols, or an MA-protocol-options field 2084 refers to a non-existent profile), an "Object Value Error" error 2085 message (Appendix A.4.4.10) with subcode 5 ("SP-SCD Mismatch") MUST 2086 be returned and the message dropped. 2088 A node generating a Stack-Configuration-Data object MUST honour the 2089 implied protocol configurations for the period during which a 2090 messaging association might be set up; in particular, it MUST be 2091 immediately prepared to accept incoming datagrams or connections at 2092 the protocol/port combinations advertised. However, the object 2093 contents MUST be retained only for the duration of the Query/Response 2094 exchange and any following association setup, and afterwards 2095 discarded. (They may become invalid because of expired bindings at 2096 intermediate NATs, or because the advertising node is using agile 2097 ports.) 2099 A GIST-Query requesting association setup always contains a Stack- 2100 Proposal and Stack-Configuration-Data object, and unless re-use 2101 occurs, the GIST-Response does so also. For a GIST-Response, the 2102 Stack-Proposal MUST NOT depend on the GIST-Query. A node MAY make 2103 different proposals depending on the combination of interface and 2104 NSLPID. Once the messaging association is set up, the querying node 2105 repeats the responder's Stack-Proposal over it in the GIST-Confirm. 2106 The responding node MUST verify this to ensure that no bidding-down 2107 attack has occurred; see Section 8.6 for further discussion. 2109 5.7.2. Protocol Definition: Forwards-TCP 2111 This MA-Protocol-ID denotes a basic use of TCP between peers. 2112 Support for this protocol is REQUIRED; associations using it can 2113 carry messages with the transfer attribute Reliable=True. The 2114 connection is opened in the forwards direction, from the querying 2115 node, towards the responder at a previously advertised port. If this 2116 protocol is offered, MA-protocol-options data MUST also be carried in 2117 the SCD object. The MA-protocol-options field formats are: 2119 o in a Query: no information apart from the field header. 2121 o in a Response: 2 byte port number at which the connection will be 2122 accepted, followed by 2 pad bytes. 2124 5.7.3. Protocol Definition: Transport Layer Security 2126 This MA-Protocol-ID denotes a basic use of transport layer channel 2127 security. Support for this protocol is mandatory; associations using 2128 it can carry messages with the transfer attribute Secure=True. For 2129 use with TCP, implementation of TLS1.0 [6] is REQUIRED and 2130 implementation of TLS1.1 [8] is RECOMMENDED. (If an unreliable 2131 transport such as DCCP or UDP is defined for GIST in the future, this 2132 MA-Protocol-ID would be implemented for it using DTLS [35].) GIST 2133 nodes supporting TLS1.0 or TLS1.1 MUST be able to negotiate the TLS 2134 ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD be able to 2135 negotiate the TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. 2137 The default mode of TLS authentication (which applies in particular 2138 to the above ciphersuites) uses a client/server certificate exchange. 2139 The Querying node acts as a TLS client, and the Responding node acts 2140 as a TLS server. Where one of the above ciphersuites is negotiated, 2141 the GIST node acting as a server MUST provide a certificate, and MUST 2142 request one from the GIST node acting as a TLS client. This allows 2143 either server-only or mutual authentication, depending on the 2144 certificates available to the client and the policy applied at the 2145 server. 2147 GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the 2148 negotiation of alternative ciphersuites is used to trigger 2149 alternative authentication procedures (for example, the use of pre- 2150 shared keys, [24]). The use of other authentication procedures may 2151 require additional specification work to define how they can be used 2152 as part of TLS within the GIST framework, and may or may not require 2153 the definition of additional MA-Protocol-IDs. 2155 No MA-protocol-options field is required for this use of TLS. 2157 5.7.4. Additional Protocol Options 2159 Further protocols or configurations could be defined in the future 2160 for additional performance or flexibility. Examples are: 2162 o SCTP or DCCP as alternatives to TCP, with essentially the same 2163 configuration. 2165 o SigComp [17] for message compression. 2167 o IPsec [30], ssh [31], or HIP/IPsec [32] for channel security. 2169 o Alternative modes of TCP operation, for example where it is set up 2170 from the responder to the querying node. 2172 5.8. Specific Message Routing Methods 2174 Each message routing method (see Section 3.3) requires the definition 2175 of the format of the message routing information (MRI) and Query- 2176 encapsulation rules. These are given in the following subsections 2177 for the various possible message routing methods. 2179 5.8.1. The Path-Coupled MRM 2181 5.8.1.1. Message Routing Information 2183 For the path-coupled MRM, this is essentially the Flow Identifier as 2184 in [22]. Minimally, this could just be the flow destination address; 2185 however, to account for policy based forwarding and other issues a 2186 more complete set of header fields should be used (see Section 4.3.4 2187 and Section 7.2 for further discussion). 2189 MRI = network-layer-version 2190 source-address prefix-length 2191 destination-address prefix-length 2192 IP-protocol 2193 diffserv-codepoint 2194 [ flow-label ] 2195 [ ipsec-SPI / L4-ports] 2197 Additional control information defines whether the flow-label, SPI 2198 and port information are present, and whether the IP-protocol and 2199 diffserv-codepoint fields should be interpreted as significant. The 2200 source and destination addresses MUST be real node addresses, but 2201 prefix lengths other than 32/128 (for IPv4/6) MAY be used to 2202 implement address 'wildcarding', allowing the MRI to refer to traffic 2203 to or from a wider address range. The MRI format allows a 2204 potentially very large number of different flag and field 2205 combinations. A GIST implementation that cannot interpret the MRI in 2206 a message MUST return an "Object Value Error" message 2207 (Appendix A.4.4.10) with subcodes 1 ("Value Not Supported") or 2 2208 ("Invalid Flag-Field Combination") and drop the message. 2210 5.8.1.2. Downstream Query Encapsulation 2212 Where the signaling message is travelling in the same ('downstream') 2213 direction as the flow defined by the MRI, the IP addressing for Query 2214 messages is as follows. Support for this encapsulation is REQUIRED. 2216 o The destination address MUST be the flow destination address as 2217 given in the MRI of the message payload. 2219 o By default, the source address is the flow source address, again 2220 from the MRI. This provides the best likelihood that the message 2221 will be correctly routed through any region performing per-packet 2222 policy-based forwarding or load balancing which takes the source 2223 address into account. However, there may be circumstances where 2224 the use of the signaling source address is preferable, such as: 2226 * In order to receive ICMP error messages about the Query message 2227 (such as unreachable port or address). If these are delivered 2228 to the flow source rather than the signaling source, it will be 2229 very difficult for the querying node to detect that it is the 2230 last GIST node on the path. 2232 * In order to receive GIST error messages where the error message 2233 sender could not interpret the NLI in the original message. 2235 * In order to attempt to run GIST through an unmodified NAT, 2236 which will only process and translate IP addresses in the IP 2237 header. 2239 Because of these considerations, use of the signaling source 2240 address is allowed as an option, with use based on local policy. 2241 A node SHOULD use the flow source address for initial Query 2242 messages, but SHOULD transition to the signaling source address 2243 for some retransmissions or as a matter of static configuration 2244 (e.g. if a NAT is known to be in the path out of a certain 2245 interface). A flag in the common header tells the message 2246 receiver which option was used. 2248 It is vital that the Query message mimics the actual data flow as 2249 closely as possible, since this is the basis of how the signaling 2250 message is attached to the data path. To this end, GIST SHOULD set 2251 the DiffServ codepoint and (for IPv6) flow label to match the values 2252 in the MRI. 2254 Any message sent in datagram mode SHOULD be below a conservative 2255 estimate of the path MTU, for which this specification takes the 2256 value 512 bytes as a default. It is possible that fragmented 2257 datagrams including an RAO will not be correctly handled in the 2258 network, so the sender SHOULD set the DF (do not fragment) bit in the 2259 IPv4 header in order to detect that a message has encountered a link 2260 with an unusually low MTU. In this case, it MUST use the signaling 2261 source address for the IP source address in order to receive the ICMP 2262 error. 2264 A GIST implementation SHOULD apply validation checks to the MRI, to 2265 reject Query messages that are being injected by nodes with no 2266 legitimate interest in the flow being signalled for. In general, if 2267 the GIST node can detect that no flow could arrive over the same 2268 interface as the Query message, it MUST be rejected with an 2269 appropriate error message. (Such checks apply only to messages with 2270 the query encapsulation, since only those messages are required to 2271 track the flow path.) The main checks are that the IP version should 2272 match the version(s) used on that interface, and that the full range 2273 of source addresses (the source-address masked with its prefix- 2274 length) would pass ingress filtering checks. For these cases, the 2275 error message is "MRI Validation Failure" (Appendix A.4.4.12) with 2276 subcodes 1 or 2 ("IP Version Mismatch" or "Ingress Filter Failure") 2277 respectively. 2279 5.8.1.3. Upstream Query Encapsulation 2281 In some deployment scenarios it is desirable and logically possible 2282 to set up routing state in the upstream direction (from flow receiver 2283 towards the sender). This could be used to support firewall 2284 signaling to control traffic from an 'un-cooperative' sender, or 2285 signaling in general where the flow sender was not NSIS-capable. 2286 This is incorporated into GIST by defining an encapsulation and 2287 processing rules for sending Query messages upstream. 2289 In general, it is not possible to determine the hop-by-hop route 2290 upstream because of asymmetric routing. However, in particular 2291 cases, the upstream peer can be discovered with a high degree of 2292 confidence, for example: 2294 o The upstream GIST peer is 1 IP hop away, and can be reached by 2295 tracing back through the interface on which the flow arrives. 2297 o The upstream peer is a border router of a single-homed (stub) 2298 network. 2300 This section defines an upstream Query encapsulation and validation 2301 checks for when it can be used. The functionality to generate 2302 upstream Queries is OPTIONAL, but if received they MUST be processed 2303 in the normal way (no special functionality is needed for this). It 2304 is possible for routing state (for a given MRI and NSLPID) to be 2305 installed by both upstream and downstream Query exchanges. If the 2306 SIDs are different, these items of routing state MUST be considered 2307 as independent; if they match, that installed by the downstream 2308 exchange MUST take precedence. 2310 The details of the encapsulation are as follows: 2312 o The destination address SHOULD be the flow source address as given 2313 in the MRI of the message payload. An implementation with more 2314 detailed knowledge of local routing MAY use an alternative 2315 destination address (e.g. the address of its default router). 2317 o The source address SHOULD be the signaling node address. 2319 o The DiffServ codepoint and (for IPv6) flow label MAY be set to 2320 match the values from the MRI, as in the downstream case. The 2321 same considerations about message size and fragmentation also 2322 apply as in the downstream case, and RAO setting and UDP port 2323 selection are also the same. 2325 o The IP-TTL of the message MUST be set to 255. 2327 The sending GIST implementation SHOULD attempt to send the Query 2328 message out of the same interface and to the same link layer 2329 neighbour from which the data packets of the flow are arriving. 2331 The receiving GIST node MAY apply validation checks to the message 2332 and MRI, to reject Query messages which have reached a node at which 2333 they can no longer be trusted. In particular, a node SHOULD reject a 2334 message which has been propagated more than one IP hop, with an 2335 "Invalid IP TTL" error message (Appendix A.4.4.11). This can be 2336 determined by examining the received IP TTL, similar to the 2337 generalised IP TTL security mechanism described in [21]. 2338 Alternatively, receipt of an upstream Query at the flow source MAY be 2339 used to trigger setup of NTLP state in the downstream direction. 2340 These restrictions may be relaxed in a future version. 2342 5.8.2. The Loose-End MRM 2344 This MRM is used to discover GIST nodes with particular properties in 2345 the direction of a given address, for example to discover a NAT along 2346 the upstream data path (e.g. as in [27]. 2348 5.8.2.1. Message Routing Information 2350 For the loose-end MRM, only a simplified version of the Flow 2351 Identifier is needed. 2353 MRI = network-layer-version 2354 source-address 2355 destination-address 2357 The source address is the address of the node initiating the 2358 discovery process, for example the node that will be the data 2359 receiver in the NAT discovery case. The destination address is the 2360 address of a node which is expected to be the 'other side' of the 2361 node to be discovered. Additional control information defines the 2362 direction of the message relative to this flow as in the path-coupled 2363 case. 2365 5.8.2.2. Downstream Query Encapsulation 2367 Only one encapsulation is defined for the loose-end MRM; by 2368 convention, this is referred to as the downstream encapsulation, and 2369 is defined as follows: 2371 o The IP destination address MUST be the destination address as 2372 given in the MRI of the message payload. 2374 o By default, the IP source address is the source address, again 2375 from the MRI. However, the use of the signaling source address is 2376 allowed as in the case of the path-coupled MRM. 2378 There are no special requirements on the setting of the DiffServ 2379 codepoint, IP TTL, or (for IPv6) the flow label. Nor are any special 2380 validation checks applied. 2382 Restrictions on message size and setting of the DF (do not fragment) 2383 bit apply as in the case of the path-coupled MRM. 2385 6. Formal Protocol Specification 2387 This section provides a more formal specification of the operation of 2388 GIST processing, in terms of rules for transitions between states of 2389 a set of communicating state machines within a node. The following 2390 description captures only the basic protocol specification; 2391 additional mechanisms can be used by an implementation to accelerate 2392 route change processing, and these are captured in Section 7.1. 2394 Conceptually, GIST processing at a node may be seen in terms of 4 2395 types of cooperating state machine: 2397 1. There is a top-level state machine which represents the node 2398 itself (Node-SM). It is responsible for the processing of events 2399 which cannot be directed towards a more specific state machine, 2400 for example, inbound messages for which no routing state 2401 currently exists. This machine exists permanently, and is 2402 responsible for creating 'per-flow' state machines to manage the 2403 GIST handshake and routing state maintenance procedures. 2405 2. For each flow and signaling direction where the node is 2406 responsible for the creation of routing state, there is an 2407 instance of a Query-Node state machine (Query-SM). This machine 2408 sends Query and Confirm messages and waits for Responses, 2409 according to the requirements from local API commands or timer 2410 processing (e.g. message repetition or routing state refresh). 2412 3. For each flow and signaling direction where the node has accepted 2413 the creation of routing state by a peer, there is an instance of 2414 a Responding-Node state machine (Response-SM). This machine is 2415 responsible for managing the status of the routing state for that 2416 flow. Depending on policy, it MAY be responsible for 2417 [re]transmission of Response messages, or this MAY be handled by 2418 the Node-SM, and a Response-SM is not even created for a flow 2419 until a properly formatted Confirm has been accepted. 2421 4. Messaging associations have their own lifecycle, represented by 2422 MA-SM, from when they are first created (in an 'incomplete' 2423 state, listening for an inbound connection or waiting for 2424 outbound connections to complete), to when they are active and 2425 available for use. 2427 Apart from the fact that the various machines can be created and 2428 destroyed by each other, there is almost no interaction between them. 2429 The machines for different flows do not interact; the Query-SM and 2430 Response-SM for a single flow and signaling direction do not 2431 interact. That is, the Response-SM which accepts the creation of 2432 routing state for a flow on one interface has no direct interaction 2433 with the Query-SM which sets up routing state on the next interface 2434 along the path. This interaction is mediated instead through the 2435 NSLP. 2437 The state machine descriptions use the terminology rx_MMMM, tg_TTTT 2438 and er_EEEE for incoming messages, API/lower layer triggers and error 2439 conditions respectively. The possible events of these types are 2440 given in the table below. In addition, timeout events denoted 2441 to_TTTT may also occur; the various timers are listed independently 2442 for each type of state machine in the following subsections. 2444 +---------------------+---------------------------------------------+ 2445 | Name | Meaning | 2446 +---------------------+---------------------------------------------+ 2447 | rx_Query | A GIST Query message has been received. | 2448 | | | 2449 | rx_Response | A GIST Response message has been received. | 2450 | | | 2451 | rx_Confirm | A GIST Confirm message has been received. | 2452 | | | 2453 | rx_Data | A GIST Data message has been received. | 2454 | | | 2455 | rx_Message | rx_Query||rx_Response||rx_Confirm||rx_Data. | 2456 | | | 2457 | rx_Hello | A GIST MA-Hello message has been received. | 2458 | | | 2459 | tg_NSLPData | A signaling application has requested data | 2460 | | transfer (via API SendMessage). | 2461 | | | 2462 | tg_Connected | The protocol stack for a messaging | 2463 | | association has completed connecting. | 2464 | | | 2465 | tg_RawData | GIST wishes to transfer data over a | 2466 | | particular messaging association. | 2467 | | | 2468 | er_NoRSM | A "No Routing State" error was received. | 2469 | | | 2470 | er_MAConnect | A messaging association protocol failed to | 2471 | | complete a connection. | 2472 | | | 2473 | er_MAFailure | A messaging association failed. | 2474 +---------------------+---------------------------------------------+ 2476 6.1. Node Processing 2478 The Node level state machine is responsible for processing events for 2479 which no more appropriate messaging association state or routing 2480 state exists. Its structure is trivial: there is a single state 2481 ('Idle'); all events cause a transition back to Idle. Some events 2482 cause the creation of other state machines. The only events that are 2483 processed by this state machine are incoming GIST messages (Query/ 2484 Response/Confirm/Data) and API requests to send data; all other 2485 events are impossible. In addition to this event processing, the 2486 Node level machine is responsible for managing listening endpoints 2487 for messaging associations (although these relate to Responding node 2488 operation, they cannot be handled by the Responder state machine 2489 since they are not created per flow). The processing rules for each 2490 event are as follows: 2492 Rule 1 (rx_Query): 2494 use the GIST service interface to determine the signaling application 2495 policy relating to this peer 2496 if (the signaling application indicates that routing state should 2497 be created) then 2498 if (routing state can be created without a 3-way handshake) then 2499 create R-SM and transfer control to it 2500 else 2501 send Response 2502 else 2503 propagate the Query with any updated NSLP payload provided 2505 Rule 2 (rx_Response): 2507 // should already have a Q-SM to handle this 2508 discard message 2509 send "No Routing State" error message 2511 Rule 3 (rx_Confirm): 2513 if (routing state can be created before receiving a Confirm) then 2514 // should already have R-SM for it which would handle this message 2515 discard message 2516 send "No Routing State" error message 2517 else 2518 create R-SM and pass message to it 2520 Rule 4 (rx_Data): 2522 if (node policy will only process Data messages with matching 2523 routing state) then 2524 send "No Routing State" error message 2525 else 2526 pass directly to NSLP 2528 Rule 5 (tg_NSLPData): 2530 if Q-mode encapsulation is not possible for this MRI 2531 reject message with an error 2532 else 2533 if (local policy & transfer attributes say routing 2534 state is not needed) then 2535 send message statelessly 2536 else 2537 create Q-SM and pass message to it 2539 6.2. Query Node Processing 2541 The Querying-Node state machine (Q-SM) has three states: 2543 o Awaiting Response 2545 o Established 2547 o Awaiting Refresh 2549 The Q-SM is created by the N-SM machine as a result of a request to 2550 send a message for a flow in a signaling direction where the 2551 appropriate state does not exist. The Query is generated immediately 2552 and the No_Response timer is started. The NSLP data MAY be carried 2553 in the Query if local policy and the transfer attributes allow it, 2554 otherwise it MUST be queued locally pending MA establishment. Then 2555 the machine transitions to the Awaiting Response state, in which 2556 timeout-based retransmissions are handled. Data messages (rx_Data 2557 events) should not occur in this state; if they do, this may indicate 2558 a lost Response and a node MAY also retransmit a Query for this 2559 reason. 2561 Once a Response has been successfully received and routing state 2562 created, the machine transitions to Established, during which NSLP 2563 data can be sent and received normally. Further Responses received 2564 in this state MUST be treated the same way (this may be the result of 2565 a lost Confirm). The Awaiting Refresh state can be considered as a 2566 substate of Established, where a new Query has been generated to 2567 refresh the routing state (as in Awaiting Response) but NSLP data can 2568 be handled normally. 2570 The timers relevant to this state machine are as follows: 2572 Refresh_QNode: Indicates when the routing state stored by this state 2573 machine must be refreshed. It is reset whenever a Response is 2574 received indicating that the routing state is still valid. 2575 Implementations MUST set the period of this timer based on the 2576 value in the RS-validity-time field of a Response message to 2577 ensure that a Query is generated before the peer's routing state 2578 expires. 2580 No_Response: Indicates that a Response has not been received in 2581 answer to a Query. This is started whenever a Query is sent and 2582 stopped when a Response is received. 2584 Inactive_QNode: Indicates that no traffic is currently being handled 2585 by this state machine. This is reset whenever the state machine 2586 handles NSLP data (in either direction). When it expires, the 2587 state machine MAY be deleted. The period of the timer can be set 2588 at any time via the API (SetStateLifetime), and if the period is 2589 reset in this way the timer itself SHOULD be restarted. 2591 The main events (including all those that cause state transitions) 2592 are shown in the figure below, tagged with the number of the 2593 processing rule that is used to handle the event. These rules are 2594 listed after the diagram. All events not shown or described in the 2595 text above are assumed to be impossible in a correct implementation. 2597 [Initialisation] +-----+ 2598 -------------------------|Birth| 2599 | +-----+ 2600 | rx_Response[4] 2601 | || tg_NSLPData[5] 2602 | tg_NSLPData[1] er_NoRSM[3] || rx_Data[7] 2603 | -------- ------------------ ------- 2604 | | V | V | V 2605 | | V | V | V 2606 | +----------+ | +-----------+ 2607 ---->>| Awaiting | ---------------- |Established| 2608 ------| Response |---------------------------->> | | 2609 | +----------+ rx_Response[4] +-----------+ 2610 | ^ | ^ | 2611 | ^ | ^ | 2612 | -------- | | 2613 | to_No_Response[2] | | 2614 | [!nResp_reached] tg_NSLPData[5] | | 2615 | || rx_Data[7] | | 2616 | -------- | | 2617 | | V | | 2618 | to_No_Response[2] | V | | 2619 | [nResp_reached] +-----------+ rx_Response[4] | | 2620 ---------- -----------| Awaiting |----------------- | 2621 | | | Refresh |<<------------------- 2622 | | +-----------+ to_Refresh_QNode[8] 2623 | | ^ | 2624 | | ^ | 2625 | | -------- 2626 | | to_No_Response[2] 2627 | | [!nResp_reached] 2628 V V 2629 V V 2630 +-----+ 2631 |Death|<<--------------- 2632 +-----+ to_Inactive_QNode[6] 2633 (from all states) 2635 Figure 6: Query Node State Machine 2637 The processing rules are as follows: 2639 Rule 1: Store the message for later transmission 2641 Rule 2: 2643 if number of Queries sent has reached the threshold 2644 // nQuery_isMax is true 2645 indicate No Response error to NSLP 2646 destroy self 2647 else 2648 send Query message 2649 start No_Response timer with new value 2651 Rule 3: 2653 // Assume the Confirm was lost in transit so resend it 2654 // for the last Response we received 2655 send Confirm message 2656 restart Refresh_QNode and Inactive_QNode timers 2658 Rule 4: 2660 if a new MA-SM is needed create one 2661 if the R flag was set send a Confirm message 2662 pass any NSLP data to the NSLP 2663 send any stored Data messages 2664 stop No_Response timer 2665 start Refresh_QNode and Inactive_QNode timers 2667 Rule 5: 2669 send Data message 2670 restart Inactive_QNode timer 2672 Rule 6: Terminate 2674 Rule 7: 2676 pass any data to the NSLP 2677 (re)start Inactive_QNode timer 2679 Rule 8: 2681 send Query message 2682 start No_Response timer 2683 stop Refresh_QNode timer 2685 6.3. Responder Node Processing 2687 The Responding-Node state machine (R-SM) has three states: 2689 o Awaiting Confirm 2690 o Established 2692 o Awaiting Refresh 2694 The policy governing the creation of the R-SM has 3 cases (ignoring 2695 the case of pure stateless operation where a Response may be 2696 generated or the message propagated forwards, but no routing state is 2697 created at the GIST level): 2699 1. It is created on receiving a Query, no Confirm is requested. 2701 2. It is created on receiving a Query, but a Confirm is requested. 2702 A timer is used to retransmit Response messages and the R-SM is 2703 destroyed if no valid Confirm is received. 2705 3. It cannot be created until a valid Confirm is received (the 2706 initial Query will have been handled by the Node level machine). 2708 In case 2 the R-SM is created in the Awaiting Confirm state, and 2709 remains there until a Confirm is received, at which point it 2710 transitions to Established. In cases 1 and 3 the R-SM is created 2711 directly in the Established state. Note that if the machine is 2712 created on receiving a Query, some of the message processing will 2713 already have been performed in the Node state machine. In the 2714 Established state the NSLP can send and receive data normally, and 2715 any additional rx_Confirm events MUST be silently ignored. The 2716 Awaiting Refresh state can be considered a substate of Established, 2717 where a Query has been received to begin the routing state refresh. 2719 In the Awaiting Refresh state the R-SM behaves as in the Awaiting 2720 Confirm state, except that the NSLP can still send and receive data. 2721 In particular, in both states there is timer-based retransmission of 2722 Response messages until a Confirm is received; additional rx_Query 2723 events in these states MUST also generate a response and restart the 2724 no_Confirm timer. 2726 The timers relevant to the operation of this state machine are as 2727 follows: 2729 Expire_RNode: Indicates when the routing state stored by this state 2730 machine needs to be expired. It is reset whenever a Query or 2731 Confirm (depending on local policy) is received indicating that 2732 the routing state is still valid. Note that state cannot be 2733 refreshed from the R-Node. 2735 No_Confirm: Indicates that a Confirm has not been received in answer 2736 to a Response. This is started/reset whenever a Response is sent 2737 and stopped when a Confirm is received. 2739 The detailed state transitions and processing rules are described 2740 below as in the Query node case. 2742 rx_Query[1] rx_Query[5] 2743 [confirmRequired] +-----+ [!confirmRequired] 2744 -------------------------|Birth|---------------------------- 2745 | +-----+ | 2746 | | rx_Confirm[2] | 2747 | ---------------------------- | 2748 | | | 2749 | tg_NSLPData[3] | | 2750 | tg_NSLPData[7] || rx_Query[5] | | 2751 | || rx_Query[1] || rx_Data[4] | | 2752 | || rx_Data[6] [!confirmRequired] | | 2753 | -------- -------------- | | 2754 | | V | V V V 2755 | | V | V V V 2756 | +----------+ | +-----------+ 2757 ---->>| Awaiting | rx_Confirm[8] -----------|Established| 2758 ------| Confirm |------------------------------>> | | 2759 | +----------+ +-----------+ 2760 | ^ | ^ | 2761 | ^ | tg_NSLPData[3] ^ | 2762 | -------- || rx_Query[1] | | 2763 | to_No_Confirm[9] || rx_Data[4] | | 2764 | [!nConf_reached] -------- | | 2765 | | V | | 2766 | to_No_Confirm[9] | V | | 2767 | [nConf_reached] +-----------+ rx_Confirm[8] | | 2768 ---------- ------------| Awaiting |----------------- | 2769 | | | Refresh |<<------------------- 2770 | | +-----------+ rx_Query[1] 2771 | | ^ | [confirmRequired] 2772 | | ^ | 2773 | | -------- 2774 V V to_No_Confirm[9] 2775 V V [!nConf_reached] 2776 +-----+ 2777 |Death|<<--------------------- 2778 +-----+ to_Expire_RNode[10] 2779 (from all states) 2781 Figure 7: Responder Node State Machine 2782 The processing rules are as follows: 2784 Rule 1: 2786 // a Confirm message is required 2787 send Response message 2788 (re)start No_Confirm timer 2790 Rule 2: 2792 pass any piggybacked data to the NSLP 2793 if a new MA-SM would be needed for this peer 2794 create one in listening state 2795 start Expire_RNode timer 2797 Rule 3: send the Data message 2799 Rule 4: pass data to NSLP 2801 Rule 5: 2803 // no Confirm message is required 2804 send Response message 2805 start Expire_RNode timer 2807 Rule 6: send "No Routing State" error message 2809 Rule 7: store Data message 2811 Rule 8: 2813 pass any piggybacked data to the NSLP 2814 send any stored Data messages 2815 stop No_Confirm timer 2816 start Expire_RNode timer 2818 Rule 9: 2820 if number of Responses sent has reached threshold 2821 // nResp_isMax is true 2822 destroy self 2823 else 2824 send Response message 2825 start No_Response timer 2827 Rule 10: destroy self 2829 6.4. Messaging Association Processing 2831 Messaging associations are modelled for use within GIST with a simple 2832 3-state process. The Awaiting Connection state indicates that the MA 2833 is waiting for the connection process(es) for every protocol in the 2834 messaging association to complete; this might involve creating 2835 listening endpoints or attempting active connects. Timers may also 2836 be necessary to detect connection failure (e.g. no incoming 2837 connection within a certain period), but these are not modelled 2838 explicitly. The Connected state indicates that the MA is open and 2839 ready to use. In addition there is an Idle state in which the local 2840 node no longer requires the messaging association but the remote node 2841 still wants it to be kept open. 2843 Clearly, many internal details of the messaging association protocols 2844 are hidden in this model, especially where the messaging association 2845 uses multiple protocol layers. Note also that although the existence 2846 of messaging associations is not directly visible to signaling 2847 applications, there is some interaction between the two because 2848 security-related information becomes available during the open 2849 process, and this may be indicated to signaling applications if they 2850 have requested it. 2852 The timers relevant to the operation of this state machine are as 2853 follows: 2855 SendHello: Indicates that an MAHello message should be sent to the 2856 remote node. The period of this timer is determined by the MA- 2857 Hold-Time sent by the remote node during the Query/Response/ 2858 Confirm exchange. 2860 NoHello: Indicates that no MAHello has been received from the remote 2861 node for a period of time. The period of this timer is sent to 2862 the remote node as the MA-Hold-Time during the Query/Response 2863 exchange. 2865 NoActivity: Indicates that the link has been inactive for a period of 2866 time. The period of this timer is implementation specific but is 2867 likely to be related to the period of the NoHello timer. 2869 The detailed state transitions and processing rules are described 2870 below as in the Query node case. 2872 [Initialisation] +-----+ 2873 ----------------------------|Birth| 2874 | +-----+ 2875 | tg_RawData[1] 2876 | || rx_Message[2] 2877 | || rx_Hello[3] 2878 | tg_RawData[5] || to_SendHello[4] 2879 | -------- -------- 2880 | | V | V 2881 | | V | V 2882 | +----------+ +-----------+ 2883 ---->>| Awaiting | tg_Connected[6] | Connected | 2884 ------|Connection|----------------------->>| | 2885 | +----------+ +-----------+ 2886 | ^ | 2887 | tg_RawData[1] ^ | 2888 | || rx_Message[2] | |to_NoActivity[7] 2889 | | V 2890 | | V 2891 | er_MAConnect[8] +-----+ to_NoHello[8] +-----------+ 2892 ---------------->>|Death|<<----------------| Idle | 2893 +-----+ | | 2894 ^ +-----------+ 2895 ^ ^ | 2896 | ^ | 2897 --------------- -------- 2898 er_MAFailure[8] rx_Hello[3] 2899 (from all states) 2901 Figure 8: Messaging Association State Machine 2903 The processing rules are as follows: 2905 Rule 1: 2907 pass message to transport layer 2908 (re)start NoActivity timer 2909 (re)start SendHello 2911 Rule 2: 2913 pass message to N-SM 2914 (re)start NoActivity timer 2915 Rule 3: 2917 if reply requested 2918 send MA-Hello 2919 restart NoHello timer 2921 Rule 4: 2923 send MA-Hello message 2924 restart NoHello timer 2926 Rule 5: queue message for later transmission 2928 Rule 6: 2930 pass outstanding queued messages to transport layer 2931 stop any timers controlling connection establishment 2932 start NoActivity timer 2933 start SendHello timer 2935 Rule 7: 2937 stop NoActivity timer 2938 stop sendHello timer 2939 start NoHello timer 2941 Rule 8: destroy self 2943 7. Advanced Protocol Features 2945 7.1. Route Changes and Local Repair 2947 7.1.1. Introduction 2949 When re-routing takes place in the network, GIST and signaling 2950 application state need to be updated for all flows whose paths have 2951 changed. The updates to signaling application state are usually 2952 signaling application dependent: for example, if the path 2953 characteristics have actually changed, simply moving state from the 2954 old to the new path is not sufficient. Therefore, GIST cannot carry 2955 out the complete path update processing. Its responsibilities are to 2956 detect the route change, update its local routing state consistently, 2957 and inform interested signaling applications at affected nodes. 2959 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 2960 x +--+ +--+ +--+ x Initial 2961 x .|C1|_.....|D1|_.....|E1| x Configuration 2962 x . +--+. .+--+. .+--+\. x 2963 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 2964 +-+ +-+ . .. .. . +-+ 2965 ...|A|_......|B|/ .. .. .|F|_.... 2966 +-+ +-+ . . . . . . +-+ 2967 . . . . . . 2968 . +--+ +--+ +--+ . 2969 .|C2|_.....|D2|_.....|E2|/ 2970 +--+ +--+ +--+ 2972 +--+ +--+ +--+ Configuration 2973 .|C1|......|D1|......|E1| after failure 2974 . +--+ .+--+ +--+ of E1-F link 2975 . \. . \. ./ 2976 +-+ +-+ . .. .. +-+ 2977 ...|A|_......|B|. .. .. .|F|_.... 2978 +-+ +-+\ . . . . . +-+ 2979 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 2980 x . +--+ +--+ +--+ . x 2981 x .|C2|_.....|D2|_.....|E2|/ x 2982 x +--+ +--+ +--+ x 2983 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 2985 ........... = physical link topology 2986 >>xxxxxxx>> = flow direction 2987 _.......... = outgoing link for flow xxxxxx given 2988 by local forwarding table 2990 Figure 9: A Re-Routing Event 2991 Route change management is complicated by the distributed nature of 2992 the problem. Consider the re-routing event shown in Figure 9. An 2993 external observer can tell that the main responsibility for 2994 controlling the updates will probably lie with nodes B and F; 2995 however, E1 is best placed to detect the event quickly at the GIST 2996 level, and C1 and D1 could also attempt to initiate the repair. 2998 On the assumption that signaling applications are soft-state based 2999 and operate end to end, and because GIST also periodically updates 3000 its picture of routing state, route changes will eventually be 3001 repaired automatically. The specification as already given includes 3002 this functionality. However, especially if upper layer refresh times 3003 are extended to reduce signaling load, the duration of inconsistent 3004 state may be very long indeed. Therefore, GIST includes logic to 3005 exchange prompt notifications with signaling applications, to allow 3006 local repair if possible. The additional mechanisms to achieve this 3007 are described in the following subsections. To a large extent, these 3008 additions can be seen as implementation issues; the protocol messages 3009 and their significance are not changed, but there are extra 3010 interactions through the API between GIST and signaling applications, 3011 and additional triggers for transitions between the various GIST 3012 states. 3014 7.1.2. Route Change Detection Mechanisms 3016 There are two aspects to detecting a route change at a single node: 3018 o Detecting that the outgoing path, in the direction of the Query, 3019 has (or may have) changed. 3021 o Detecting that the incoming path, in the direction of the 3022 Response, has (or may have) changed (in which case the node may no 3023 longer be on the path at all). 3025 At a single node, these processes are largely independent, although 3026 clearly a change in one direction at a node corresponds to a change 3027 the opposite direction at its peer. Note that there are two possible 3028 forms for a route change: the interface through which a flow leaves 3029 or enters a node may change, and the adjacent peer may change. In 3030 general, a route change can include one or the other or both (or 3031 indeed neither, although such changes are very hard to detect). 3033 The route change detection mechanisms available to a node depend on 3034 the MRM in use and the role the node played in setting up the routing 3035 state in the first place (i.e. as Querying or Responding node). The 3036 following discussion is specific to the case of the path-coupled MRM 3037 using downstream Queries only; other scenarios may require other 3038 methods. However, the repair logic described in the subsequent 3039 subsections is intended to be universal. 3041 There are five mechanisms for a node to detect that a route change 3042 has occurred, which are listed below. They apply differently 3043 depending on whether the change is in the Query or Response 3044 direction, and these differences are summarised in the following 3045 table. 3047 Local Trigger: In trigger mode, GIST finds out from the local 3048 forwarding table that the next hop has changed. This only works 3049 if the routing change is local, not if it happens a few routing 3050 hops away (including the case that it happens at a GIST-unaware 3051 node). 3053 Extended Trigger: Here, GIST checks a link-state topology database to 3054 discover that the path has changed. This makes certain 3055 assumptions on consistency of route computation and only works 3056 within a single area for OSPF and similar link-state protocols. 3057 Where available, this offers the most accurate and rapid 3058 indication of route changes, but requires more access to the 3059 routing internals than a typical operating system may provide. 3061 GIST C-mode Monitoring: GIST may find that C-mode packets are 3062 arriving (from either peer) with a different TTL or on a different 3063 interface. This provides no direct information about the new flow 3064 path, but indicates that routing has changed and that rediscovery 3065 may be required. 3067 Data Plane Monitoring: The signaling application on a node may detect 3068 a change in behaviour of the flow, such as TTL change, arrival on 3069 a different interface, or loss of the flow altogether. The 3070 signaling application on the node is allowed to notify this 3071 information locally to GIST (Appendix B.6). 3073 GIST Probing: According to the specification, each GIST node MUST 3074 periodically repeat the discovery (GIST-Query/GIST-Response) 3075 operation. The querying node will discover the route change by a 3076 modification in the Network-Layer-Information in the GIST- 3077 Response. The period can be negotiated independently for each 3078 GIST hop, so nodes that have access to the other techniques listed 3079 above MAY use long periods for the probing operation. 3081 +------------+--------------------------+---------------------------+ 3082 | Method | Query direction | Response direction | 3083 +------------+--------------------------+---------------------------+ 3084 | Local | Discovers new interface | Not applicable | 3085 | Trigger | (and peer if local) | | 3086 | | | | 3087 | Extended | Discovers new interface | May determine that route | 3088 | Trigger | and may determine new | from peer will have | 3089 | | peer | changed | 3090 | | | | 3091 | C-Mode | Provides hint that | Provides hint that change | 3092 | Monitoring | change has occurred | has occurred | 3093 | | | | 3094 | Data Plane | Not applicable | NSLP informs GIST that a | 3095 | Monitoring | | change may have occurred | 3096 | | | | 3097 | Probing | Discovers changed NLI in | Discovers changed NLI in | 3098 | | GIST-Response | GIST-Query | 3099 +------------+--------------------------+---------------------------+ 3101 7.1.3. GIST Behaviour Supporting Re-Routing 3103 The GIST behaviour necessary to support re-routing can be modelled 3104 using a 3-level classification of the validity of each item of 3105 routing state. (This classification applies separately to the 3106 Querying and Responding node for each pair of GIST peers.) The 3107 levels are: 3109 Bad: The routing state is either missing altogether, or not safe to 3110 use to send data. 3112 Tentative: The routing state may have changed, but it is still usable 3113 for sending NSLP data pending verification. 3115 Good: The routing state has been established and no events affecting 3116 it have since been detected. 3118 These classifications are not identical to the states described in 3119 Section 6, but there are dependencies between them. Specifically, 3120 routing state is considered Bad until the machine first enters the 3121 Established state, at which point it becomes Good. Thereafter, the 3122 status may be invalidated for any of the reasons discussed above; it 3123 is an implementation issue to decide which techniques to implement in 3124 any given node, and how to reclassify routing state (as Bad or 3125 Tentative) for each. The status returns to Good, either when the 3126 state machine re-enters the Established state, or if GIST can 3127 determine from direct examination of the routing or forwarding tables 3128 that the peer has not changed. When the status returns to Good, GIST 3129 MUST if necessary update its routing state table so that the 3130 relationships between MRI/SID/NSLPID tuples and messaging 3131 associations are up to date. 3133 When classification of the routing state for the downstream direction 3134 changes to Bad/Tentative because of local routing indications, GIST 3135 MAY automatically change the classification in the upstream direction 3136 to Tentative unless local routing indicates that this is not 3137 necessary. This SHOULD NOT be done in the case where the initial 3138 change was indicated by the signaling application. This mechanism 3139 accounts for the fact that a routing change may affect several nodes, 3140 and so can be an indication that upstream routing may also have 3141 changed. In any case, whenever GIST updates the routing status, it 3142 informs the signaling application with the NetworkNotification API 3143 (Appendix B.4), unless the change was caused via the API in the first 3144 place. 3146 The GIST behaviour for state repair is different for the Querying and 3147 Responding node. At the Responding node, there is no additional 3148 behaviour, since the Responding node cannot initiate protocol 3149 transitions autonomously, it can only react to the Querying node. 3150 The Querying node has three options, depending on how the transition 3151 from 'Good' was initially caused: 3153 1. To inspect the routing/forwarding table and verifying that the 3154 next peer has not changed. This technique MUST NOT be used if 3155 the transition was caused by a signaling application, but SHOULD 3156 be used otherwise if available. 3158 2. To move to the 'Awaiting Refresh' state. This technique MUST NOT 3159 be used if the current status is 'Bad', since data is being 3160 incorrectly delivered. 3162 3. To move to the 'Awaiting Response' state. This technique may be 3163 used at any time, but has the effect of freezing NSLP 3164 communication while GIST state is being repaired. 3166 The second and third techniques trigger the execution of a GIST 3167 handshake to carry out the repair. It may be desirable to delay the 3168 start of the handshake process, either to wait for the network to 3169 stabilise, to avoid flooding the network with Query traffic for a 3170 large number of affected flows, or to wait for confirmation that the 3171 node is still on the path from the upstream peer. One approach is to 3172 delay the handshake until there is NSLP data to be transmitted. 3173 Implementation of such delays is a matter of local policy; however, 3174 GIST MUST begin the handshake immediately if the status change was 3175 caused by an InvalidateRoutingState API call marked as 'Urgent', and 3176 SHOULD begin it if the upstream routing state is still known to be 3177 Good. 3179 7.1.4. Signaling Application Operation 3181 Signaling applications can use these functions as provided by GIST to 3182 carry out rapid local repair following re-routing events. The 3183 signaling application instances carry out the multi-hop aspects of 3184 the procedure, including crossover node detection, and tear-down/ 3185 reinstallation of signaling application state; they also trigger GIST 3186 to carry out the local routing state maintenance operations over each 3187 individual hop. The local repair procedures depend heavily on the 3188 fact that stateful NSLP nodes are a single GIST hop apart; this is 3189 enforced by the details of the GIST peer-discovery process. 3191 The following outline description of a possible set of NSLP actions 3192 takes the scenario of Figure 9 as an example. 3194 1. The signaling application at node E1 is notified by GIST of route 3195 changes affecting the downstream and upstream directions. The 3196 downstream status was updated to Bad because of a trigger from 3197 the local forwarding tables, and the upstream status changed 3198 automatically to Tentative as a consequence. The signaling 3199 application at E1 MAY begin local repair immediately, or MAY 3200 propagate a notification upstream to D1 that re-routing has 3201 occurred. 3203 2. The signaling application at node D1 is notified of the route 3204 change, either by signaling application notifications or from the 3205 GIST level (e.g. by a trigger from a link-state topology 3206 database). If the information propagates faster within the 3207 routing protocol, GIST will change the upstream/downstream 3208 routing state to Tentative/Bad automatically, and this will cause 3209 the signaling application to propagate the notification further 3210 upstream. 3212 3. This process continues until the notification reaches node A. 3213 Here, there is no downstream routing change, so GIST only learns 3214 of the update via the signaling application trigger. Since the 3215 upstream status is still Good, it therefore begins the repair 3216 handshake immediately. 3218 4. The handshake initiated by node A causes its downstream routing 3219 state to be confirmed as Good and unchanged there; it also 3220 confirms the (Tentative) upstream routing state at B as Good. 3221 This is enough to identify B as the crossover router, and the 3222 signaling application and GIST can begin the local repair 3223 process. 3225 An alternative way to reach step (4) is that node B is able to 3226 determine autonomously that there is no likelihood of an upstream 3227 route change (e.g. it is an area border router and the route change 3228 is only intra-area). In this case, the signaling application and 3229 GIST will see that the upstream state is Good and can begin the local 3230 repair directly. 3232 After a route change, a signaling application may wish to remove 3233 state at another node which is no longer on the path. However, since 3234 it is no longer on the path, in principle GIST can no longer send 3235 messages to it. (In general, provided this state is soft, it will 3236 time out anyway; however, the timeouts involved may have been set to 3237 be very long to reduce signaling load.) The requirement to remove 3238 state in a specific peer node is identified in [28]. 3240 This requirement can be met provided that GIST is able to use the old 3241 path to the signaling application peer for some period while the 3242 signaling application still needs it. Since NSLP peers are a single 3243 GIST hop apart, the necessary information is just the old entry in 3244 the node's routing state table for that flow. Rather than requiring 3245 the GIST level to maintain multiple generations of this information, 3246 it can just be provided to the signaling application in the same node 3247 (in an opaque form), which can store it if necessary and provide it 3248 back to the GIST layer in case it needs to be used. This information 3249 is denoted as 'SII-Handle' in the abstract API of Appendix B. 3250 Messages sent this way MUST bypass the GIST routing state tables at 3251 the sender, and this is indicated by setting the E flag in the common 3252 header (Appendix A.1); at the receiver, GIST MUST NOT validate the 3253 MRI/SID/NSLPID against local routing state and instead indicates the 3254 mode of reception to signaling applications through the API 3255 (Appendix B.2). Signaling applications should validate the source 3256 and effect of the message themselves, and if appropriate should in 3257 particular indicate to GIST (see Appendix B.5) that routing state is 3258 no longer required for this flow. This is necessary to prevent GIST 3259 in nodes on the old path initiating routing state refresh and thus 3260 causing state conflicts at the crossover router. 3262 7.2. NAT Traversal 3264 GIST messages must carry packet addressing and higher layer 3265 information as payload data in order to define the flow signalled 3266 for. (This applies to all GIST messages, regardless of how they are 3267 encapsulated or which direction they are travelling in.) At an 3268 addressing boundary the data flow packets will have their headers 3269 translated; if the signaling payloads are not translated 3270 consistently, the signaling messages will refer to incorrect (and 3271 probably meaningless) flows after passing through the boundary. In 3272 addition, GIST handshake messages carry additional addressing 3273 information about the GIST nodes themselves, and this must also be 3274 processed appropriately when traversing a NAT. 3276 The simplest solution to this problem is to require that a NAT is 3277 GIST-aware, and to allow it to modify messages based on the contents 3278 of the MRI. (This makes the assumption that NATs only rewrite the 3279 header fields included in this payload, and not other higher layer 3280 identifiers.) Provided this is done consistently with the data flow 3281 header translation, signaling messages will be valid each side of the 3282 boundary, without requiring the NAT to be signaling application 3283 aware. (Note, however, that if the NAT does not understand the MRI, 3284 it should reject the message with an appropriate error.) 3286 This specification defines an additional object that a NAT can insert 3287 into Query-encapsulated messages and which is echoed back in any 3288 responses to those messages. The new object, the NAT-Traversal 3289 object (Appendix A.3.8), carries the translation between the 'public' 3290 and 'private' MRI. It also carries a list of which other objects in 3291 the message have been translated. This should always include the 3292 NLI, and the Stack-Configuration-Data (if present); if GIST is 3293 extended with further objects that carry addressing data, this list 3294 allows a message receiver to know if the new objects were supported 3295 by the NAT. Finally, the NAT-Traversal object MAY be used to carry 3296 data to be used in back-translating datagram mode responses; this 3297 could be the original NLI or SCD, or opaque equivalents in the case 3298 of topology hiding. 3300 A consequence of this approach is that the routing state tables at 3301 the signaling application peers (each side of the NAT) are no longer 3302 directly compatible. In particular, the values for Message-Routing- 3303 Information are different, which is why the unmodified MRI is 3304 propagated in the NAT-Traversal payload to allow subsequent C-mode 3305 messages to be interpreted correctly. 3307 This specification does not define normative behaviour for a NAT 3308 translating GIST messages, since much of this will depend on NAT 3309 policy about allocating bindings; the description is purely 3310 informative. However, it does define the behaviour of a GIST node 3311 receiving a message containing a NAT-Traversal object. 3313 A possible set of operations for a NAT to process a Query- 3314 encapsulated message is as follows: 3316 1. Verify that bindings for any data flow are actually in place. 3318 2. Create a new Message-Routing-Information object with fields 3319 modified according to the data flow bindings. 3321 3. Create bindings for subsequent C-mode signaling (based on the 3322 information in the Network-Layer-Information and Stack- 3323 Configuration-Data objects). 3325 4. Create new Network-Layer-Information and if necessary Stack- 3326 Configuration-Data objects with fields to force D-mode response 3327 messages through the NAT, and to allow C-mode exchanges using the 3328 C-mode signaling bindings. 3330 5. Add a NAT-Traversal payload, listing the objects which have been 3331 modified and including the unmodified MRI and any other data 3332 needed to interpret the response. (If a NAT-Traversal object is 3333 already present, in the case of a sequence of NATs, the list of 3334 modified objects may be updated and further opaque data added, 3335 but the MRI contained in it is left unchanged.) 3337 6. Encapsulate the message according to the normal rules of this 3338 specification for the Query-encapsulation. If the S-flag was set 3339 in the original message, the same IP source address selection 3340 policy should be applied to the forwarded message. 3342 7. Forward the message with these new payloads. 3344 A GIST node receiving such a message MUST verify that all mandatory 3345 objects containing addressing have been translated correctly, or else 3346 reject the message with an 'Object Type Error' message 3347 (Appendix A.4.4.9) with subcode 4 ('Untranslated Object'). The error 3348 message MUST include the NAT-Traversal object as the first TLV after 3349 the common header (this is true for any other error message generated 3350 as a response). Otherwise, the message is processed essentially as 3351 normal. If no state needs to be updated for the message, the NAT- 3352 Traversal object can be effectively ignored. The other possibility 3353 is that a Response must be returned, either because the message is 3354 the beginning of a handshake for a new flow, or it is a refresh for 3355 existing state. In both cases, the GIST node MUST create the 3356 Response message in the normal way using the 'local' form of the MRI, 3357 and its own NLI and (if necessary) SCD. It MUST also include the 3358 NAT-Traversal object as the first object in the Response after the 3359 common header. 3361 A NAT will intercept datagram mode messages with the normal 3362 encapsulation containing such echoed NAT-Traversal objects. (All 3363 other GIST messages, either in connection mode, or datagram mode 3364 messages with no NAT-Traversal object, should be treated as 'normal' 3365 data traffic by the NAT, i.e. with IP and transport layer translation 3366 but no GIST-specific processing.) The NAT processing is a subset of 3367 the processing for the Query-encapsulated case: 3369 1. Verify the existence of bindings for the data flow. 3371 2. Leave the Message-Routing-Information object unchanged. 3373 3. Modify the NLI and SCD objects for the Responding node if 3374 necessary, and create or update any bindings for C-mode signaling 3375 traffic. 3377 4. Forward the message. 3379 A GIST node receiving such a message MUST use the MRI from the NAT- 3380 Traversal object as the key to index its internal routing state; it 3381 MAY also store the 'translated' MRI for additional (e.g. diagnostic) 3382 information, but this is not used in the GIST processing. The 3383 remainder of GIST processing is unchanged. 3385 Note that Confirm messages are not translated. Thus, a Responding 3386 node has available only the untranslated MRI describing the flow, and 3387 the untranslated NLI as peer routing state. This would prevent the 3388 correct interpretation of the signaling messages; also, subsequent 3389 Query (refresh) messages would always be seen as route changes 3390 because of the NLI change. Therefore, a Responding node that wishes 3391 to delay state installation until receiving a Confirm must somehow 3392 reconstruct the translations when the Confirm arrives. How to do 3393 this is an implementation issue; one approach is to carry the 3394 translated objects as part of the Responder cookie which is echoed in 3395 the Confirm. (Indeed, for one of the cookie constructions in 3396 Section 8.5 this is automatic.) 3398 7.3. Interaction with IP Tunnelling 3400 The interaction between GIST and IP tunnelling is very simple. An IP 3401 packet carrying a GIST message is treated exactly the same as any 3402 other packet with the same source and destination addresses: in other 3403 words, it is given the tunnel encapsulation and forwarded with the 3404 other data packets. 3406 Tunnelled packets will not be identifiable as GIST messages until 3407 they leave the tunnel, since any router alert option and the standard 3408 GIST protocol encapsulation (e.g. port numbers) will be hidden within 3409 the standard tunnel encapsulation. If signaling is needed for the 3410 tunnel itself, this has to be initiated as a separate signaling 3411 session by one of the tunnel endpoints - that is, the tunnel counts 3412 as a new flow. Because the relationship between signaling for the 3413 'microflow' and signaling for the tunnel as a whole will depend on 3414 the signaling application in question, it is a signaling application 3415 responsibility to be aware of the fact that tunnelling is taking 3416 place and to carry out additional signaling if necessary; in other 3417 words, at least one tunnel endpoint must be signaling application 3418 aware. 3420 In some cases, it is the tunnel exit point (i.e. the node where 3421 tunnelled data and downstream signaling packets leave the tunnel) 3422 that will wish to carry out the tunnel signaling, but this node will 3423 not have knowledge or control of how the tunnel entry point is 3424 carrying out the data flow encapsulation. The information about how 3425 the inner MRI/SID relate to the tunnel MRI/SID needs to be carried in 3426 the signaling data from the tunnel entry point (this functionality is 3427 the equivalent to the RSVP SESSION_ASSOC object of [10]). In the 3428 NSIS protocol suite, these bindings are managed by the signaling 3429 applications, either implicitly (e.g. by SID re-use) or explicitly 3430 (by carrying objects that bind the inner and outer SIDs as part of 3431 the NSLP payload). 3433 7.4. IPv4-IPv6 Transition and Interworking 3435 GIST itself is essentially IP version neutral: version dependencies 3436 are isolated in the formats of the Message-Routing-Information, 3437 Network-Layer-Information and Stack-Configuration-Data objects, and 3438 GIST also depends on the version independence of the protocols that 3439 support messaging associations. In mixed environments, GIST 3440 operation will be influenced by the IP transition mechanisms in use. 3441 This section provides a high level overview of how GIST is affected, 3442 considering only the currently predominant mechanisms. 3444 Dual Stack: (As described in [29].) In mixed environments, GIST MUST 3445 use the same IP version for Query-encapsulated messages as the 3446 flow it is signaling for, and SHOULD do so for other signaling 3447 also (see Section 5.2.2). The IP version used in datagram mode is 3448 closely tied to the IP version used by the data flow, so it is 3449 intrinsically impossible for a IPv4-only or IPv6-only GIST node to 3450 support signaling for flows using the other IP version. Hosts 3451 which are dual stack for applications and routers which are dual 3452 stack for forwarding need GIST implementations which can support 3453 both IP versions. Applications with a choice of IP versions might 3454 select a version based on which could be supported in the network 3455 by GIST, which could be established by invoking parallel discovery 3456 procedures. 3458 Packet Translation: (Applicable to SIIT [5] and NAT-PT [11].) Some 3459 transition mechanisms allow IPv4 and IPv6 nodes to communicate by 3460 placing packet translators between them. From the GIST 3461 perspective, this should be treated essentially the same way as 3462 any other NAT operation (e.g. between 'public' and 'private' 3463 addresses) as described in Section 7.2. The translating node 3464 needs to be GIST-aware; it will have to translate the addressing 3465 payloads between IPv4 and IPv6 formats for flows which cross 3466 between the two. The translation rules for the fields in the MRI 3467 payload (including e.g. DiffServ-codepoint and flow-label) are as 3468 defined in [5]. 3470 Tunnelling: (Applicable to 6to4 [13].) Many transition mechanisms 3471 handle the problem of how an end to end IPv6 (or IPv4) flow can be 3472 carried over intermediate IPv4 (or IPv6) regions by tunnelling; 3473 the methods tend to focus on minimising the tunnel administration 3474 overhead. 3476 From the GIST perspective, the treatment should be as similar as 3477 possible to any other IP tunnelling mechanism, as described in 3478 Section 7.3. In particular, the end to end flow signaling will 3479 pass transparently through the tunnel, and signaling for the 3480 tunnel itself will have to be managed by the tunnel endpoints. 3481 However, additional considerations may arise because of special 3482 features of the tunnel management procedures. In particular, [14] 3483 is based on using an anycast address as the destination tunnel 3484 endpoint. GIST MAY use anycast destination addresses in the 3485 Query-encapsulation of D-mode messages if necessary, but MUST NOT 3486 use them in the Network-Layer-Information addressing field; normal 3487 unicast addresses MUST be used instead. Note that the addresses 3488 from the IP header are not used by GIST in matching requests and 3489 responses, so there is no requirement to use anycast source 3490 addresses. 3492 8. Security Considerations 3494 The security requirement for GIST is to protect the signaling plane 3495 against identified security threats. For the signaling problem as a 3496 whole, these threats have been outlined in [23]; the NSIS framework 3497 [22] assigns a subset of the responsibilities to the NTLP. The main 3498 issues to be handled can be summarised as: 3500 Message Protection: Signaling message content can be protected 3501 against eavesdropping, modification, injection and replay while in 3502 transit. This applies both to GIST payloads, and GIST should also 3503 provide such protection as a service to signaling applications 3504 between adjacent peers. 3506 Routing State Integrity Protection: It is important that signaling 3507 messages are delivered to the correct nodes, and nowhere else. 3508 Here, 'correct' is defined as 'the appropriate nodes for the 3509 signaling given the Message-Routing-Information'. In the case 3510 where the MRI is based on the Flow Identification for path-coupled 3511 signaling, 'appropriate' means 'the same nodes that the 3512 infrastructure will route data flow packets through'. (GIST has 3513 no role in deciding whether the data flow itself is being routed 3514 correctly; all it can do is ensure the signaling is routed 3515 consistently with it.) GIST uses internal state to decide how to 3516 route signaling messages, and this state needs to be protected 3517 against corruption. 3519 Prevention of Denial of Service Attacks: GIST nodes and the network 3520 have finite resources (state storage, processing power, 3521 bandwidth). The protocol tries to minimise exhaustion attacks 3522 against these resources and not allow GIST nodes to be used to 3523 launch attacks on other network elements. 3525 The main additional issue is handling authorisation for executing 3526 signaling operations (e.g. allocating resources). This is assumed to 3527 be done in each signaling application. 3529 In many cases, GIST relies on the security mechanisms available in 3530 messaging associations to handle these issues, rather than 3531 introducing new security measures. Obviously, this requires the 3532 interaction of these mechanisms with the rest of the GIST protocol to 3533 be understood and verified, and some aspects of this are discussed in 3534 Section 5.7. 3536 8.1. Message Confidentiality and Integrity 3538 GIST can use messaging association functionality, specifically in 3539 this version TLS (Section 5.7.3), to ensure message confidentiality 3540 and integrity. Implementation of this functionality is REQUIRED but 3541 its use for any given flow or signaling application is OPTIONAL. In 3542 some cases, confidentiality of GIST information itself is not likely 3543 to be a prime concern, in particular since messages are often sent to 3544 parties which are unknown ahead of time, although the content visible 3545 even at the GIST level gives significant opportunities for traffic 3546 analysis. Signaling applications may have their own mechanism for 3547 securing content as necessary; however, they may find it convenient 3548 to rely on protection provided by messaging associations, since it 3549 runs unbroken between signaling application peers. 3551 8.2. Peer Node Authentication 3553 Cryptographic protection (of confidentiality or integrity) requires a 3554 security association with session keys. These can be established by 3555 an authentication and key exchange protocol based on shared secrets, 3556 public key techniques or a combination of both. Authentication and 3557 key agreement is possible using the protocols associated with the 3558 messaging association being secured (TLS incorporates this 3559 functionality directly; IKE, IKEv2 or KINK could provide it for 3560 IPsec). GIST nodes rely on these protocols to authenticate the 3561 identity of the next hop, and GIST has no authentication capability 3562 of its own. 3564 With routing state discovery, there are few effective ways to know 3565 what is the legitimate next or previous hop as opposed to an 3566 impostor. In other words, cryptographic authentication here only 3567 provides assurance that a node is 'who' it is (i.e. the legitimate 3568 owner of identity in some namespace), not 'what' it is (i.e. a node 3569 which is genuinely on the flow path and therefore can carry out 3570 signaling for a particular flow). Authentication provides only 3571 limited protection, in that a known peer is unlikely to lie about its 3572 role. Additional methods of protection against this type of attack 3573 are considered in Section 8.3 below. 3575 It is an implementation issue whether peer node authentication should 3576 be made signaling application dependent; for example, whether 3577 successful authentication could be made dependent on presenting 3578 credentials related to a particular signaling role (e.g. "signaling 3579 for QoS"). The abstract API of Appendix B leaves open such policy 3580 and authentication interactions between GIST and the NSLP it is 3581 serving. However, it does allow applications to inspect the 3582 authenticated identity of the peer to which a message will be sent 3583 before transmission. 3585 8.3. Routing State Integrity 3587 Internal state in a node (see Section 4.2) is used to route messages. 3589 If this state is corrupted, signaling messages may be misdirected. 3591 In the case where the message routing method is path-coupled, the 3592 messages need to be routed identically to the data flow described by 3593 the MRI, and the routing state table is the GIST view of how these 3594 flows are being routed through the network in the immediate 3595 neighbourhood of the node. Routes are only weakly secured (e.g. 3596 there is no cryptographic binding of a flow to a route), and there is 3597 no authoritative information about flow routes other than the current 3598 state of the network itself. Therefore, consistency between GIST and 3599 network routing state has to be ensured by directly interacting with 3600 the routing mechanisms to ensure that the signaling peers are the 3601 appropriate ones for any given flow. An overview of security issues 3602 and techniques in this context is provided in [33]. 3604 In one direction, peer identification is installed and refreshed only 3605 on receiving a GIST-Response message (compare Figure 4). This MUST 3606 echo the cookie from a previous GIST-Query message, which will have 3607 been sent along the flow path (in datagram mode, i.e. end-to-end 3608 addressed). Hence, only the true next peer or an on-path attacker 3609 will be able to generate such a message, provided freshness of the 3610 cookie can be checked at the querying node. 3612 In the other direction, peer identification MAY be installed directly 3613 on receiving a GIST-Query message containing addressing information 3614 for the signaling source. However, any node in the network could 3615 generate such a message (indeed, many nodes in the network could be 3616 the genuine upstream peer for a given flow). To protect against 3617 this, three strategies are used: 3619 Filtering: the receiving node MAY reject signaling messages which 3620 claim to be for flows with flow source addresses which could be 3621 ruled out by ingress filtering. An extension of this technique 3622 would be for the receiving node to monitor the data plane and to 3623 check explicitly that the flow packets are arriving over the same 3624 interface and if possible from the same link layer neighbour as 3625 the datagram mode signaling packets. (If they are not, it is 3626 likely that at least one of the signaling or flow packets is being 3627 spoofed.) Signaling applications SHOULD only install state on the 3628 route taken by the data itself. 3630 Authentication (weak or strong): the receiving node MAY refuse to 3631 install upstream state until it has completed a GIST-Confirm 3632 handshake with the peer. This echoes the Response cookie of the 3633 GIST-Response, and discourages nodes from using forged source 3634 addresses. This also plays a role in denial of service 3635 prevention, see below. A stronger approach is to require full 3636 peer authentication within the messaging association, the 3637 reasoning being that an authenticated peer can be trusted not to 3638 pretend that it is on path when it is not. 3640 SID segregation: The routing state lookup for a given MRI and NSLPID 3641 MUST also take the SID into account. A malicious node can only 3642 overwrite existing routing state if it can guess the corresponding 3643 SID; it can insert state with random SID values, but generally 3644 this will not be used to route messages for which state has 3645 already been legitimately established. 3647 8.4. Denial of Service Prevention 3649 GIST is designed so that in general each Query message only generates 3650 at most one Response, so that a GIST node cannot become the source of 3651 a denial of service amplification attack. (There is a special case 3652 of retransmitted Response messages, see Section 5.3.3.) 3654 However, GIST can still be subjected to denial-of-service attacks 3655 where an attacker using forged source addresses forces a node to 3656 establish state without return routability, causing a problem similar 3657 to TCP SYN flood attacks. Furthermore, an adversary might use 3658 modified or replayed unprotected signaling messages as part of such 3659 an attack. There are two types of state attacks and one 3660 computational resource attack. In the first state attack, an 3661 attacker floods a node with messages that the node has to store until 3662 it can determine the next hop. If the destination address is chosen 3663 so that there is no GIST-capable next hop, the node would accumulate 3664 messages for several seconds until the discovery retransmission 3665 attempt times out. The second type of state-based attack causes GIST 3666 state to be established by bogus messages. A related computational/ 3667 network-resource attack uses unverified messages to cause a node to 3668 make AAA queries or attempt to cryptographically verify a digital 3669 signature. 3671 We use a combination of two defences against these attacks: 3673 1. The responding node need not establish a session or discover its 3674 next hop on receiving the GIST-Query message, but MAY wait for a 3675 GIST-Confirm message, possibly on a secure channel. If the 3676 channel exists, the additional delay is one one-way delay and the 3677 total is no more than the minimal theoretically possible delay of 3678 a three-way handshake, i.e., 1.5 node-to-node round-trip times. 3679 The delay gets significantly larger if a new connection needs to 3680 be established first. 3682 2. The Response to the Query message contains a cookie, which is 3683 repeated in the Confirm. State is only established for messages 3684 that contain a valid cookie. The setup delay is also 1.5 round- 3685 trip times. (This mechanism is similar to that in SCTP [12] and 3686 other modern protocols.) 3688 Once a node has decided to establish routing state, there may still 3689 be transport and security state to be established between peers. 3690 This state setup is also vulnerable to denial of service attacks. 3691 GIST relies on the lower layer protocols that make up messaging 3692 associations to mitigate such attacks. In the current specification, 3693 the querying node is always the one wishing to establish a messaging 3694 association, so it is the responding node that needs to be protected. 3696 Signaling applications can use the services provided by GIST to 3697 defend against certain (e.g. flooding) denial of service attacks. In 3698 particular, they can elect to process only messages from peers that 3699 have passed a return routability check or been authenticated at the 3700 messaging association level (see Appendix B.2). Signaling 3701 applications that accept messages under other circumstances (in 3702 particular, before routing state has been fully established at the 3703 GIST level) need to take this into account when designing their 3704 denial of service prevention mechanisms, for example by not creating 3705 local state as a result of processing such messages. 3707 8.5. Requirements on Cookie Mechanisms 3709 The requirements on the Query cookie can be summarised as follows: 3711 Liveness: The cookie must be live (must change from one handshake to 3712 the next). To prevent replay attacks. 3714 Unpredictability: The cookie must not be guessable (e.g. not from a 3715 sequence or timestamp). To prevent direct forgery based on seeing 3716 a history of captured messages. 3718 Easily validated: It must be efficient for the Q-Node to validate 3719 that a particular cookie matches an in-progress handshake, for a 3720 routing state machine which already exists. To discard spoofed 3721 responses, or responses to spoofed queries. 3723 Uniqueness: The cookie must be unique to a given handshake (since it 3724 is actually used to match the Response to a handshake anyway, e.g. 3725 during messaging association re-use). 3727 Likewise, the requirements on the Responder cookie can be summarised 3728 as follows: 3730 Liveness: The cookie must be live (must change from one handshake to 3731 the next). To prevent replay attacks. 3733 Creation simplicity: The cookie must be lightweight to generate. To 3734 avoid resource exhaustion at the responding node. 3736 Validation simplicity: It must be simple for the R-node to validate 3737 that an R-cookie was generated by itself (and no-one else), 3738 without storing state about the handshake it was generated for. 3740 Binding: The cookie must be bound to the routing state that will be 3741 installed. To prevent use with different routing state e.g. in a 3742 modified Confirm. The routing state here includes: 3744 The NLI of the Query 3746 The MRI/NSLPID for the messaging 3748 The interface on which the Query was received 3750 A suitable implementation for the Q-Cookie is a cryptographically 3751 strong random number which is unique for this routing state machine 3752 handshake. A node SHOULD implement this or an equivalently strong 3753 mechanism. 3755 A suitable implementation for the R-Cookie is as follows: 3757 R-Cookie = liveness data + hash (locally known secret, 3758 Q-Node NLI, MRI, NSLPID, 3759 reception interface, 3760 liveness data) 3762 A node SHOULD implement this or an equivalently strong mechanism. 3763 There are several alternatives for the liveness data. One is to use 3764 a timestamp like SCTP. Another is to give the local secret a (rapid) 3765 rollover, with the liveness data as the generation number of the 3766 secret, like IKEv2. In both cases, the liveness data has to be 3767 carried outside the hash, to allow the hash to be verified at the 3768 Responder. Another approach is to replace the hash with encryption 3769 under a locally known secret, in which case the liveness data does 3770 not need to be carried in the clear. Any symmetric cipher immune to 3771 known plaintext attacks can be used. 3773 To support the validation simplicity requirement, the Responder can 3774 check the liveness data to filter out some blind (flooding) attacks 3775 before beginning any cryptographic cookie verification. To support 3776 this usage, the liveness data must be carried in the clear and not be 3777 easily guessable; this rules out the timestamp approach, and suggests 3778 the use of sequence of secrets with the liveness data identifying the 3779 position in the sequence. The secret strength and rollover frequency 3780 must be high enough that the secret cannot be brute-forced during its 3781 lifetime. Note that any node can use a Query to discover the current 3782 liveness data, so it remains hard to defend against sophisticated 3783 attacks which disguise such 'probes' within a flood of Queries from 3784 forged source addresses. Therefore, it remains important to use an 3785 efficient hashing mechanism or equivalent. 3787 If a node receives a message for which cookie validation fails, it 3788 MAY return an "Object Value Error" error message (Appendix A.4.4.10) 3789 with subcode 4 ("Invalid Cookie") to the sender, as well as dropping 3790 the message. However, doing so in general makes a node a source of 3791 backscatter. Therefore, this SHOULD only be enabled selectively, 3792 e.g. during initial deployment or debugging. 3794 8.6. Security Protocol Selection Policy 3796 This specification defines a single mandatory-to-implement security 3797 protocol (TLS, Section 5.7.3). However, it is possible to define 3798 additional security protocols in the future, for example to allow re- 3799 use with other types of credentials, or migrate towards protocols 3800 with stronger security properties. In addition, use of any security 3801 protocol for a messaging association is optional. Security protocol 3802 selection is carried out as part of the GIST handshake mechanism 3803 (Section 4.4.1). 3805 The selection process may be vulnerable to downgrade attacks, where a 3806 man in the middle modifies the capabilities offered in the Query or 3807 Response to mislead the peers into accepting a lower level of 3808 protection than is achievable. There is a two part defence against 3809 such attacks (the following is based the same concepts as [18]): 3811 1. The Response does not depend on the Stack-Proposal in the Query 3812 (see Section 5.7.1). Therefore, tampering with the Query message 3813 has no effect on the resulting messaging association 3814 configuration. 3816 2. The Responding node's Stack-Proposal is echoed in the Confirm. 3817 The Responding node checks this to validate that the proposal it 3818 made in the Response is the same as the one received by the 3819 Querying node. (Note that as a consequence of the previous 3820 point, the Responding node does not have to remember the proposal 3821 explicitly, since it is a static function of local policy.) 3823 The validity of the second part depends on the strength of the 3824 security protection provided for the Confirm message. If the 3825 Querying node is prepared to create messaging associations with null 3826 security properties (e.g. TCP only), the defence is ineffective, 3827 since the man in the middle can re-insert the original Responder's 3828 Stack-Proposal, and the Responding node will assume that the minimal 3829 protection is a consequence of Querying node limitations. However, 3830 if the messaging association provides at least integrity protection 3831 that cannot be broken in real-time, the Confirm cannot be modified in 3832 this way. Therefore, provided that the Querying node applies a 3833 security policy on the messaging association protocols it will create 3834 that ensures at least this minimal level of protection is met, it can 3835 be assured that the capability discovery process will result in the 3836 setup of a messaging association with the correct security properties 3837 as appropriate for the two peers involved. 3839 8.7. Residual Threats 3841 Taking the above security mechanisms into account, the main residual 3842 threats against NSIS are three types of on-path attack. 3844 An on-path attacker who can intercept the initial Query can do most 3845 things it wants to the subsequent signaling. It is very hard to 3846 protect against this at the GIST level; the only defence is to use 3847 strong messaging association security to see whether the Responding 3848 node is authorised to take part in NSLP signaling exchanges. To some 3849 extent, this behaviour is logically indistinguishable from correct 3850 operation, so it is easy to see why defence is difficult. Note that 3851 an on-path attacker of this sort can do anything to the traffic as 3852 well as the signaling. Therefore, the additional threat induced by 3853 the signaling weakness seems tolerable. 3855 At the NSLP level, there is a concern about transitivity of trust of 3856 correctness of routing along the signaling chain. The NSLP at the 3857 querying node can have good assurance that it is communicating with 3858 an on-path peer (or a node delegated by the on-path node). However, 3859 it has no assurance that the node beyond the responder is also on- 3860 path, or that the MRI (in particular) is not being modified by the 3861 responder to refer to a different flow. Therefore, if it sends 3862 signaling messages with payloads (e.g. authorisation tokens) which 3863 are "valuable" to nodes beyond the adjacent hop, it is up to the NSLP 3864 to ensure that the appropriate chain of trust exists, which must in 3865 general use messaging association (strong) security. 3867 There is a further residual attack by a node which is not on the path 3868 of the flow, but is on the path of the Response, or is able to use a 3869 Response from one handshake to interfere with another. The attacker 3870 modifies the Response to cause the Querying node to form an adjacency 3871 with it rather than the true downstream node. In principle, this 3872 attack could be prevented by including an additional cryptographic 3873 object in the Response message which ties the Response to the initial 3874 Query and the routing state and can be verified by the Querying node. 3876 9. IANA Considerations 3878 This section defines the registries and initial codepoint assignments 3879 for GIST. It also defines the procedural requirements to be followed 3880 by IANA in allocating new codepoints. Guidelines on the technical 3881 criteria to be followed in evaluating requests for new codepoint 3882 assignments are given for the overall NSIS protocol suite in a 3883 separate NSIS extensibility document [36]. 3885 This specification allocates the following codepoints in existing 3886 registries: 3888 Well-known UDP port XXX as the destination port for Query- 3889 encapsulated GIST messages (Section 5.3). 3891 This specification creates the following registries with the 3892 structures as defined below: 3894 NSLP Identifiers: Each signaling application requires the assignment 3895 of one of more NSLPIDs. The following NSLPID is allocated by this 3896 specification: 3898 +---------+---------------------------------------------------------+ 3899 | NSLPID | Application | 3900 +---------+---------------------------------------------------------+ 3901 | 0 | Used for GIST messages not related to any signaling | 3902 | | application. | 3903 +---------+---------------------------------------------------------+ 3905 Every other NSLPID MUST be associated with a specific RAO value 3906 (multiple NSLPIDs MAY be associated with the same value). The 3907 NSLPID is a 16 bit integer, and allocation policies for further 3908 values are as follows: 3910 1-32703: IESG Approval 3912 32704-32767: Private/Experimental Use 3914 32768-65536: Reserved 3916 GIST Message Type: The GIST common header (Appendix A.1) contains a 1 3917 byte message type field. The following values are allocated by 3918 this specification: 3920 +---------+----------+ 3921 | MType | Message | 3922 +---------+----------+ 3923 | 0 | Query | 3924 | | | 3925 | 1 | Response | 3926 | | | 3927 | 2 | Confirm | 3928 | | | 3929 | 3 | Data | 3930 | | | 3931 | 4 | Error | 3932 | | | 3933 | 5 | MAHello | 3934 +---------+----------+ 3936 Allocation policies for further values are as follows: 3938 6-63: Standards Action 3940 64-119: Expert Review 3942 120-127: Private/Experimental Use 3944 128-255: Reserved 3946 Object Types: There is a 12-bit field in the object header 3947 (Appendix A.2). The following values for object type are defined 3948 by this specification: 3950 +---------+-----------------------------+ 3951 | OType | Object Type | 3952 +---------+-----------------------------+ 3953 | 0 | Message Routing Information | 3954 | | | 3955 | 1 | Session ID | 3956 | | | 3957 | 2 | Network Layer Information | 3958 | | | 3959 | 3 | Stack Proposal | 3960 | | | 3961 | 4 | Stack Configuration Data | 3962 | | | 3963 | 5 | Query Cookie | 3964 | | | 3965 | 6 | Responder Cookie | 3966 | | | 3967 | 7 | NAT Traversal | 3968 | | | 3969 | 8 | NSLP Data | 3970 | | | 3971 | 9 | Error | 3972 +---------+-----------------------------+ 3974 Allocation policies for further values are as follows: 3976 10-1023: Standards Action 3978 1024-1999: Specification Required 3980 2000-2047: Private/Experimental Use 3982 2048-4095: Reserved 3984 When a new object type is defined, the extensibility bits (A/B, 3985 see Appendix A.2.1) must also be defined. 3987 Message Routing Methods: GIST allows multiple message routing methods 3988 (see Section 3.3). The message routing method is indicated in the 3989 leading byte of the MRI object (Appendix A.3.1). This 3990 specification defines the following values: 3992 +---------+------------------------+ 3993 | MRM | Message Routing Method | 3994 +---------+------------------------+ 3995 | 0 | Path Coupled MRM | 3996 | | | 3997 | 1 | Loose End MRM | 3998 +---------+------------------------+ 4000 Allocation policies for further values are as follows: 4002 2-63: Standards Action 4004 64-119: Expert Review 4006 120-127: Private/Experimental Use 4008 128-255: Reserved 4010 When a new MRM is defined, the information described in 4011 Section 3.3 must be provided. 4013 MA-Protocol-IDs: Each upper layer protocol that can be used in a 4014 messaging association is identified by a 1-byte MA-Protocol-ID 4015 (Section 5.7). This is used as a tag in the Stack-Proposal and 4016 Stack-Configuration-Data objects (Appendix A.3.4 and 4017 Appendix A.3.5). The following values are defined by this 4018 specification: 4020 +---------------------+-----------------------------------------+ 4021 | MA-Protocol-ID | Higher Layer Protocol | 4022 +---------------------+-----------------------------------------+ 4023 | 1 | TCP opened in the forwards direction | 4024 | | | 4025 | 2 | TLS initiated in the forwards direction | 4026 +---------------------+-----------------------------------------+ 4028 Allocation policies for further values are as follows: 4030 3-63: Standards Action 4032 64-119: Expert Review 4034 120-127: Private/Experimental Use 4036 128-255: Reserved 4038 Allocating a new MA-Protocol-ID requires defining the format for 4039 the MA-protocol-options field (if any) in the Stack-Configuration- 4040 Data object that is needed to define its configuration. Note that 4041 the MA-Protocol-ID is not an IP Protocol number (indeed, some of 4042 the messaging association protocols - such as TLS - do not have an 4043 IP Protocol number). 4045 Error Codes/Subcodes: There is a 2 byte error code and 1 byte subcode 4046 in the Value field of the Error object (Appendix A.4.1). Error 4047 codes 1-12 are defined in Appendix A.4.4 together with subcodes 4048 0-3 for code 1, 0-4 for code 9, 0-5 for code 10, and 0-2 for code 4049 12. Additional codes and subcodes are allocated on a first-come, 4050 first served basis. When a new error code/subcode combination is 4051 allocated, the Error Class and the format of any associated error- 4052 specific information must also be defined. 4054 10. Acknowledgements 4056 This document is based on the discussions within the IETF NSIS 4057 working group. It has been informed by prior work and formal and 4058 informal inputs from: Cedric Aoun, Attila Bader, Roland Bless, Bob 4059 Braden, Marcus Brunner, Benoit Campedel, Luis Cordeiro, Elwyn Davies, 4060 Christian Dickmann, Pasi Eronen, Alan Ford, Xiaoming Fu, Ruediger 4061 Geib, Eleanor Hepworth, Thomas Herzog, Cheng Hong, Jia Jia, Cornelia 4062 Kappler, Georgios Karagiannis, Chris Lang, John Loughney, Allison 4063 Mankin, Jukka Manner, Pete McCann, Andrew McDonald, Glenn Morrow, 4064 Dave Oran, Andreas Pashalidis, Henning Peters, Tom Phelan, Takako 4065 Sanda, Charles Shen, Melinda Shore, Martin Stiemerling, Martijn 4066 Swanink, Mike Thomas, Hannes Tschofenig, Sven van den Bosch, Michael 4067 Welzl, Lars Westberg, and Mayi Zoumaro-djayoon. Parts of the TLS 4068 usage description (Section 5.7.3) were derived from the Diameter base 4069 protocol specification, RFC3588. In addition, Hannes Tschofenig 4070 provided a detailed set of review comments on the security section, 4071 and Andrew McDonald provided the formal description for the initial 4072 packet formats. Chris Lang's implementation work provided objective 4073 feedback on the clarity and feasibility of the specification, and he 4074 also provided the state machine description and the initial error 4075 catalogue and formats. 4077 11. References 4079 11.1. Normative References 4081 [1] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 4083 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4084 Levels", BCP 14, RFC 2119, March 1997. 4086 [3] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 4087 the Differentiated Services Field (DS Field) in the IPv4 and 4088 IPv6 Headers", RFC 2474, December 1998. 4090 [4] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 4091 RFC 2711, October 1999. 4093 [5] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 4094 RFC 2765, February 2000. 4096 [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 4097 RFC 2246, January 1999. 4099 [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax 4100 Specifications: ABNF", RFC 4234, October 2005. 4102 [8] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", 4103 draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005. 4105 11.2. Informative References 4107 [9] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 4108 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 4109 Specification", RFC 2205, September 1997. 4111 [10] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP 4112 Operation Over IP Tunnels", RFC 2746, January 2000. 4114 [11] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 4115 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 4117 [12] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 4118 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 4119 Paxson, "Stream Control Transmission Protocol", RFC 2960, 4120 October 2000. 4122 [13] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 4123 IPv4 Clouds", RFC 3056, February 2001. 4125 [14] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 4126 RFC 3068, June 2001. 4128 [15] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 4129 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 4130 September 2001. 4132 [16] Grossman, D., "New Terminology and Clarifications for 4133 Diffserv", RFC 3260, April 2002. 4135 [17] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 4136 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 4137 RFC 3320, January 2003. 4139 [18] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 4140 Haukka, "Security Mechanism Agreement for the Session 4141 Initiation Protocol (SIP)", RFC 3329, January 2003. 4143 [19] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 4144 - Simple Traversal of User Datagram Protocol (UDP) Through 4145 Network Address Translators (NATs)", RFC 3489, March 2003. 4147 [20] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 4148 draft-rosenberg-midcom-turn-08 (work in progress), 4149 September 2005. 4151 [21] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 4152 Security Mechanism (GTSM)", RFC 3682, February 2004. 4154 [22] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 4155 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 4156 June 2005. 4158 [23] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 4159 Steps in Signaling (NSIS)", RFC 4081, June 2005. 4161 [24] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 4162 Transport Layer Security (TLS)", RFC 4279, December 2005. 4164 [25] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 4165 draft-ietf-dccp-spec-13 (work in progress), December 2005. 4167 [26] Conta, A., "Internet Control Message Protocol (ICMPv6) for the 4168 Internet Protocol Version 6 (IPv6) Specification", 4169 draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005. 4171 [27] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 4172 (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in progress), 4173 February 2006. 4175 [28] Manner, J., "NSLP for Quality-of-Service signalling", 4176 draft-ietf-nsis-qos-nslp-09 (work in progress), February 2006. 4178 [29] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 4179 IPv6 Hosts and Routers", RFC 4213, October 2005. 4181 [30] Kent, S. and K. Seo, "Security Architecture for the Internet 4182 Protocol", RFC 4301, December 2005. 4184 [31] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 4185 draft-ietf-secsh-architecture-22 (work in progress), 4186 March 2005. 4188 [32] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-04 4189 (work in progress), October 2005. 4191 [33] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 4192 Nordmark, "Mobile IP Version 6 Route Optimization Security 4193 Design Background", RFC 4225, December 2005. 4195 [34] Floyd, S. and V. Jacobson, "The Synchronisation of Periodic 4196 Routing Messages", SIGCOMM Symposium on Communications 4197 Architectures and Protocols pp. 33--44, September 1993. 4199 [35] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4200 Security", draft-rescorla-dtls-05 (work in progress), 4201 June 2005. 4203 [36] Loughney, J., "NSIS Extensibility Model", 4204 draft-loughney-nsis-ext-01 (work in progress), July 2005. 4206 Appendix A. Bit-Level Formats and Error Messages 4208 This appendix provides formats for the various component parts of the 4209 GIST messages defined abstractly in Section 5.2. 4211 Each GIST message consists of a header and a sequence of objects. 4212 The GIST header has a specific format, described in more detail in 4213 Appendix A.1 below. An NSLP message is one object within a GIST 4214 message. Note that GIST itself provides the message length 4215 information and signaling application identification. General object 4216 formatting guidelines are provided in Appendix A.2 below, followed in 4217 Appendix A.3 by the format for each object. Finally, Appendix A.4 4218 provides the formats used for error reporting. 4220 In the following object diagrams, '//' is used to indicate a variable 4221 sized field and ':' is used to indicate a field that is optionally 4222 present. 4224 A.1. The GIST Common Header 4226 This header precedes all GIST messages. It has a fixed format, as 4227 shown below. 4229 0 1 2 3 4230 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 4231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4232 | Version | GIST hops | Message length | 4233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4234 | NSLPID | Type |S|R|E| Reserved| 4235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4237 Message length = the total number of words in the message after 4238 the common header itself 4239 Type = the GIST message type (Query, Response, etc.) 4240 S flag = S=1 if the IP source address is the same as the 4241 signaling source address, S=0 if it is different 4242 R flag = R=1 if a reply to this message is explicitly 4243 requested 4244 E flag = E=1 if the message was explicitly routed 4245 Section 7.1.4 4247 The rules governing the use of the R-flag depend on the GIST message 4248 type. It MUST always be set (R=1) in Query messages (these always 4249 elicit a Response), and never in Confirm, Data or Error messages. It 4250 is optional in a MA-Hello; if set, another MA-Hello is sent in reply. 4251 It is optional in a Response (but MUST be set if the Response 4252 contains a Responder cookie); if set, a Confirm is sent in reply. 4254 Parsing failures may be caused by unknown Version or Type values, 4255 inconsistent R flag setting, or a Message Length inconsistent with 4256 the set of objects carried. In all cases the receiver MUST if 4257 possible return a "Common Header Parse Error" message 4258 (Appendix A.4.4.1) with the appropriate subcode, and not process the 4259 message further. 4261 A.2. General Object Format 4263 Each object begins with a fixed header giving the object Type and 4264 object Length. This is followed by the object Value, which is a 4265 whole number of 32-bit words long. 4267 0 1 2 3 4268 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 4269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4270 |A|B|r|r| Type |r|r|r|r| Length | 4271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4272 // Value // 4273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4275 The individual components are as follows: 4277 o The bits marked 'A' and 'B' are extensibility flags which are 4278 defined below; the remaining bits marked 'r' are reserved. 4280 o Length has the units of 32 bit words, and measures the length of 4281 Value. If there is no Value, Length=0. If the Length is not 4282 consistent with the contents of the object, an "Object Value 4283 Error" message (Appendix A.4.4.10) with subcode 0 "Incorrect 4284 Length" MUST be returned and the message dropped. 4286 o Value is (therefore) a whole number of 32 bit words. If there is 4287 any padding required, the length and location must be defined by 4288 the object-specific format information; objects which contain 4289 variable length (e.g. string) types may need to include additional 4290 length subfields to do so. 4292 Any part of the object used for padding or defined as reserved 4293 (marked 'Reserved' or 'Rsv' in the diagrams below) MUST be set to 0 4294 on transmission and MUST be ignored on reception. 4296 A.2.1. Object Extensibility 4298 The leading two bits of the TLV header are used to signal the desired 4299 treatment for objects whose Type field is unknown at the receiver. 4300 The following three categories of object have been identified, and 4301 are described here. 4303 AB=00 ("Mandatory"): If the object is not understood, the entire 4304 message containing it MUST be rejected with an "Object Type Error" 4305 message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object"). 4307 AB=01 ("Ignore"): If the object is not understood, it MUST be deleted 4308 and the rest of the message processed as usual. 4310 AB=10 ("Forward"): If the object is not understood, it MUST be 4311 retained unchanged in any message forwarded as a result of message 4312 processing, but not stored locally. 4314 The combination AB=11 is reserved. 4316 A.3. GIST TLV Objects 4318 A.3.1. Message-Routing-Information 4320 Type: Message-Routing-Information 4322 Length: Variable (depends on message routing method) 4324 0 1 2 3 4325 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 4326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4327 | MRM-ID | Reserved | | 4328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4329 // Method-specific addressing information (variable) // 4330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4332 A.3.1.1. Path-Coupled MRM 4334 In the case of basic path-coupled routing, the addressing information 4335 takes the following format: 4337 0 1 2 3 4338 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 4339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4340 |IP-Ver |P|T|F|S|A|B|D|Reserved | 4341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4342 // Source Address // 4343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4344 // Destination Address // 4345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4346 | Source Prefix | Dest Prefix | Protocol | DS-field |Rsv| 4347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4348 : Reserved | Flow Label : 4349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4350 : SPI : 4351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4352 : Source Port : Destination Port : 4353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4355 The flags are: 4356 P - P=1 means that IP Protocol should be interpreted 4357 T - T=1 means that DS-Field should be interpreted; see [3] and [16] 4358 F - F=1 means that flow Label is present and should be interpreted 4359 S - S=1 means that SPI is present and should be interpreted; see [30] 4360 A/B - Source/Destination Port (see below) 4361 D - Direction of message relative to flow 4363 The source and destination addresses are always present and of the 4364 same type; their length depends on the value in the IP-Ver field. In 4365 the normal case where the MRI refers only to traffic between specific 4366 host addresses, the Source/Dest Prefix values would both be 32/128 4367 for IPv4/6 respectively. 4369 In the case of IPv6, the Protocol field refers to the true upper 4370 layer protocol carried by the packets, i.e. excluding any IP option 4371 headers. This is therefore not necessarily the same as the Next 4372 Header value from the base IPv6 header. 4374 F may only be set if IP-Ver is 6. If F is not set, the entire 32 bit 4375 word for the Flow Label is absent. 4377 The S/A/B flags can only be set if P is set. The SPI field is only 4378 present if the S flag is set. 4380 If either of A, B is set (value=1), the word containing the port 4381 numbers is included in the object. However, the contents of each 4382 field is only significant if the corresponding flag is set; 4383 otherwise, the contents of the field is regarded as padding, and the 4384 MRI refers to all ports (i.e. acts as a wildcard). If the flag is 4385 set and Port=0x0000, the MRI will apply to a specific port, whose 4386 value is not yet known. If neither of A or B is set, the word is 4387 absent. 4389 The Direction flag has the following meaning: the value 0 means 'in 4390 the same direction as the flow' (or "downstream"), and the value 1 4391 means 'in the opposite direction to the flow' (or "upstream"). 4393 A.3.1.2. Loose-End MRM 4395 In the case of the loose-end message routing method, the addressing 4396 information takes the following format: 4398 0 1 2 3 4399 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 4400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4401 |IP-Ver |D| Reserved | 4402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4403 // Source Address // 4404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4405 // Destination Address // 4406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4408 The only flag defined is: 4409 D - Direction (always 0 for "downstream") 4411 The source and destination addresses are always present and of the 4412 same type; their length depends on the value in the IP-Ver field. 4414 A.3.2. Session Identification 4416 Type: Session-Identification 4418 Length: Fixed (4 32-bit words) 4420 0 1 2 3 4421 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 4422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4423 | | 4424 + + 4425 | | 4426 + Session ID + 4427 | | 4428 + + 4429 | | 4430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4432 A.3.3. Network-Layer-Information 4434 Type: Network-Layer-Information 4436 Length: Variable (depends on length of Peer-Identity and IP version) 4438 0 1 2 3 4439 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 4440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4441 | PI-Length | IP-TTL |IP-Ver | Reserved | 4442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4443 | Routing State Validity Time | 4444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4445 // Peer Identity // 4446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4447 // Interface Address // 4448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4450 Routing State Validity Time = the time for which the routing state 4451 for this flow can be considered correct without a 4452 refresh. Given in milliseconds. 4453 PI-Length = the byte length of the Peer-Identity field 4454 (note that the Peer-Identity field itself is padded 4455 to a whole number of words) 4456 IP-TTL = initial or reported IP-TTL 4457 IP-Ver = the IP version for the Interface-Address field 4459 A.3.4. Stack Proposal 4461 Type: Stack-Proposal 4463 Length: Variable (depends on number of profiles and size of each 4464 profile) 4466 0 1 2 3 4467 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 4468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4469 | Prof-Count | Reserved | 4470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4471 // Profile 1 // 4472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4473 : : 4474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4475 // Profile 2 // 4476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4477 Prof-Count = The number of profiles in the proposal. MUST be > 0. 4479 Each profile is itself a sequence of protocol layers, and the profile 4480 is formatted as a list as follows: 4482 o The first byte is a count of the number of layers in the profile. 4484 o This is followed by a sequence of 1-byte MA-Protocol-IDs as 4485 described in Section 5.7. 4487 o The profile is padded to a word boundary with 0, 1, 2 or 3 zero 4488 bytes. 4490 If there are no profiles (i.e. all bytes are null), then a "Object 4491 Value Error" message (Appendix A.4.4.10) with subcode 3 ("Empty 4492 List") MUST be returned and the message dropped. 4494 A.3.5. Stack-Configuration-Data 4496 Type: Stack-Configuration-Data 4498 Length: Variable (depends on number of protocols and size of each MA- 4499 protocol-options field) 4501 0 1 2 3 4502 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 4503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4504 | MPO-Count | Reserved | 4505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4506 | MA-Hold-Time | 4507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4508 // MA-protocol-options 1 // 4509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4510 : : 4511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4512 // MA-protocol-options N // 4513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4514 MA-Hold-Time = the time for which the messaging association will 4515 be held open without traffic or a hello message. 4516 Given in milliseconds. 4517 MPO-Count = the number of MA-protocol-options fields present 4518 (these contain their own length information) 4520 The MA-protocol-options fields are formatted as follows: 4522 0 1 2 3 4523 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 4524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4525 |MA-Protocol-ID | Profile | Length |D| Reserved | 4526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4527 // Options Data // 4528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4529 MA-Protocol-ID = Protocol identifier as described in 4530 Section 5.7 4531 . 4532 Profile = Tag indicating which profile from the accompanying 4533 Stack-Proposal object this applies to. Profiles 4534 are numbered from 1 upwards; the special value 0 4535 indicates 'applies to all profiles'. 4536 Length = the byte length of MA-protocol-options field 4537 that follows. This will be zero-padded 4538 up to the next word boundary. 4539 D flag = If set (D=1), this protocol MUST not be used for a 4540 messaging association. 4542 Note that the format of the options data may differ depending on 4543 whether the field is in a GIST-Query or GIST-Response. 4545 A.3.6. Query Cookie 4547 Type: Query-Cookie 4549 Length: Variable (selected by querying node) 4551 0 1 2 3 4552 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 4553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4554 // Query Cookie // 4555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4557 The contents are implementation defined. See Section 8.5 for further 4558 discussion. 4560 A.3.7. Responder Cookie 4562 Type: Responder-Cookie 4564 Length: Variable (selected by responding node) 4565 0 1 2 3 4566 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 4567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4568 // Responder Cookie // 4569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4571 The contents are implementation defined. See Section 8.5 for further 4572 discussion. 4574 A.3.8. NAT Traversal 4576 Type: NAT-Traversal 4578 Length: Variable (depends on length of contained fields) 4580 This object is used to support the NAT traversal mechanisms described 4581 in Section 7.2. 4583 0 1 2 3 4584 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 4585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4586 | MRI-Length | Type-Count | NAT-Count | Reserved | 4587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4588 // Original Message-Routing-Information // 4589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4590 // List of translated objects // 4591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4592 | Length of opaque information | | 4593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 4594 // Information replaced by NAT #1 | 4595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4596 : : 4597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4598 | Length of opaque information | | 4599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 4600 // Information replaced by NAT #N | 4601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4603 MRI-Length = the word length of the included MRI payload 4604 Type-Count = the number of GIST payloads translated by the 4605 NAT; the Type numbers are included as a list 4606 (padded with 2 null bytes if necessary) 4607 NAT-Count = the number of NATs traversed by the message, and the 4608 number of opaque payloads at the end of the object 4610 The length fields in the body of the message are byte counts, not 4611 including the 2 bytes of the length field itself. Note that each 4612 opaque information field is zero-padded to the next 32-bit word 4613 boundary if necessary. 4615 A.3.9. NSLP Data 4617 Type: NSLP-Data 4619 Length: Variable (depends on NSLP) 4621 0 1 2 3 4622 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 4623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4624 // NSLP Data // 4625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4627 A.4. Errors 4629 A.4.1. Error Object 4631 Type: Error 4633 Length: Variable (depends on error) 4635 0 1 2 3 4636 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 4637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4638 | Error Class | Error Code | Error Subcode | 4639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4640 |S|M|C|D|Q| Reserved | MRI Length | Info Count | 4641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4642 | | 4643 + Common Header + 4644 | (of original message) | 4645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4646 : Session Id : 4647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4648 : Message Routing Information : 4649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4650 : Additional Information : 4651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4652 : Debugging Comment : 4653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4654 The flags are: 4655 S - S=1 means the Session ID object is present 4656 M - M=1 means MRI object is present 4657 C - C=1 means a debug Comment is present after header. 4658 D - D=1 means the original message was received in D-Mode 4659 Q - Q=1 means the original message was received Q-Mode encapsulated 4660 (can't be set if D=0). 4662 A GIST Error object contains an error-class (see Appendix A.4.3), an 4663 error-code, an error-subcode, and as much information about the 4664 message which triggered the error as is available. This information 4665 MUST include the Common header of the original message and SHOULD 4666 also include the Session Id and MRI objects if these could be decoded 4667 correctly. These objects are included in their entirety, except for 4668 their TLV Headers. 4670 The Info Count field contains the number of Additional Information 4671 fields in the object. This count is usually 0 or 1, but may be more 4672 for certain messages; the precise set of fields to include is defined 4673 with the error code/subcode. The field formats are given in 4674 Appendix A.4.2 and their use for the different errors is given in the 4675 error catalogue Appendix A.4.4. The Debugging Comment is a null- 4676 terminated UTF-8 string, padded if necessary to a whole number of 32- 4677 bit words with more null characters. 4679 A.4.2. Additional Information Fields 4681 The Common Error Header may be followed by some Additional 4682 Information objects. The possible formats of these objects are shown 4683 below. 4685 Message Length Info: 4687 0 1 2 3 4688 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 4689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4690 | Calculated Length | Reserved | 4691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4693 Calculated Length = the length of the original message calculated 4694 by adding up all the objects in the message. 4696 MTU Info: 4698 0 1 2 3 4699 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 4700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4701 | Link MTU | Reserved | 4702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4704 This object provides information about the MTU for a link along 4705 which a message could not be sent. 4707 Object Type Info: 4709 0 1 2 3 4710 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 4711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4712 | Object Type | Reserved | 4713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4715 This object provides information about the type of object which 4716 caused the error. 4718 Object Value Info: 4720 0 1 2 3 4721 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 4722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4723 | Rsv | Real Object Length | Offset | 4724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4725 // Object // 4726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4728 Real Object Length: Since the length in the original TLV header 4729 may be inaccurate, this field provides the actual 4730 length of the object (including the TLV Header) 4731 included in the error message. 4732 Offset: The byte in the object at which the GIST node 4733 found the error. 4734 Object: The invalid TLV object (including the TLV Header) 4736 This object carries information about a TLV object which was found 4737 to be invalid in the original message. An error message may contain 4738 more than one Object Value Info object. 4740 A.4.3. Error Classes 4742 The first byte of the error object, "Error Class", indicates the 4743 severity level. The currently defined severity levels are: 4745 0 (Informational): response data which should not be thought of as 4746 changing the condition of the protocol state machine. 4748 1 (Success): response data which indicates that the message being 4749 responded to has been processed successfully in some sense. 4751 2 (Protocol-Error): the message has been rejected because of a 4752 protocol error (e.g. an error in message format). 4754 3 (Transient-Failure): the message has been rejected because of a 4755 particular local node status which may be transient (i.e. it may 4756 be worthwhile to retry after some delay). 4758 4 (Permanent-Failure): the message has been rejected because of local 4759 node status which will not change without additional out of band 4760 (e.g. management) operations. 4762 Additional error class values are reserved. 4764 The allocation of error classes to particular errors is not precise; 4765 the above descriptions are deliberately informal. Actual error 4766 processing should take into account the specific error in question; 4767 the error class may be useful supporting information (e.g. in network 4768 debugging). 4770 A.4.4. Error Catalogue 4772 This section lists all the possible GIST errors, including when they 4773 are raised and what additional information fields should be carried 4774 in the error object. 4776 A.4.4.1. Common Header Parse Error 4778 Class: Protocol-Error 4779 Code: 1 4780 Additional Info: Depends on subcode 4782 This message is sent if a GIST node receives a message where the 4783 common header cannot be parsed correctly, or where an error in the 4784 overall message format is detected. Note that in this case the 4785 original MRI and Session ID are not included in the Error Object. 4786 This error code is split into subcodes as follows: 4788 0: Unknown Version: The GIST version is unknown. The (highest) 4789 supported version supported by the node can be inferred from the 4790 Common Header of the GIST-Error message itself. 4792 1: Unknown Type: The GIST message type is unknown. 4794 2: Invalid R-flag: The R flag in the header is inconsistent with the 4795 message type. 4797 3: Incorrect Message Length: The overall message length is not 4798 consistent with the set of objects carried. An Additional Info 4799 field of Message Length Info carries the calculated message 4800 length. 4802 A.4.4.2. Hop Limit Exceeded 4804 Class: Permanent-Failure 4805 Code: 2 4806 Additional Info: None 4808 This message is sent if a GIST node receives a message with a GIST 4809 Hop Limit of zero, or a GIST node decrements a packet's GIST Hop 4810 Limit to zero. This message indicates either a routing loop or too 4811 small an initial Hop Limit value. 4813 A.4.4.3. Incorrect Encapsulation 4815 Class: Protocol-Error 4816 Code: 3 4817 Additional Info: None 4819 This message is sent if a GIST node receives a message which uses an 4820 incorrect encapsulation method (e.g. a Query arrives over an MA). 4822 A.4.4.4. Incorrectly Delivered Message 4824 Class: Protocol-Error 4825 Code: 4 4826 Additional Info: None 4828 This message is sent if a GIST node receives a message over an MA 4829 which is not associated with the MRI/NSLPID/SID combination in the 4830 message. 4832 A.4.4.5. No Routing State 4834 Class: Protocol-Error 4835 Code: 5 4836 Additional Info: None 4838 This message is sent if a node receives a message for which routing 4839 state should exist, but has not yet been created (and thus there is 4840 no appropriate Q/R-SM). This can occur either on receiving a 4841 Response to an unknown Query, or on receiving a Data message at a 4842 node whose policy requires routing state to exist before such 4843 messages can be accepted. See also Section 6.1 and Section 6.3. 4845 A.4.4.6. Unknown NSLPID 4847 Class: Permanent-Failure 4848 Code: 6 4849 Additional Info: None 4851 This message is sent if a router receives a directly addressed 4852 message for an NSLP which it does not support. 4854 A.4.4.7. Endpoint Found 4856 Class: Informational 4857 Code: 7 4858 Additional Info: None 4860 This message is sent if a GIST node at a flow endpoint receives a 4861 Query message for an NSLP which it does not support. 4863 A.4.4.8. Message Too Large 4865 Class: Permanent-Failure 4866 Code: 8 4867 Additional Info: MTU Info 4869 A router receives a message which it can't forward because it exceeds 4870 the MTU on the next or subsequent hops. 4872 A.4.4.9. Object Type Error 4874 Class: Protocol-Error 4875 Code: 9 4876 Additional Info: Object Type Info 4878 This message is sent if a GIST node receives a message containing a 4879 TLV object with an invalid type. The message includes the type of 4880 the object at fault. This error code is split into subcodes as 4881 follows: 4883 0: Duplicate Object: This subcode is used if a GIST node receives a 4884 message containing multiple instances of an object which may only 4885 appear once in a message (in the current specification this 4886 applies to all objects). 4888 1: Unrecognised Object: This subcode is used if a GIST node receive a 4889 message containing an object which it does not support, and the 4890 extensibility flags AB=00. 4892 2: Missing Object: This subcode is used if a GIST node receives a 4893 message which is missing one or more mandatory objects. This 4894 message is also sent if a Stack-Proposal is sent without a 4895 matching Stack-Configuration-Data object when one was necessary, 4896 or vice versa. 4898 3: Invalid Object: This subcode is used if the object type is known, 4899 but it is not valid for this particular GIST message type. 4901 4: Untranslated Object: This subcode is used if the object type is 4902 known and is mandatory to interpret, but it contains addressing 4903 data which has not been translated by an intervening NAT. 4905 A.4.4.10. Object Value Error 4907 Class: Protocol-Error 4908 Code: 10 4909 Additional Info: Object Value Info 4911 This message is sent if a router receives a packet containing an 4912 object which cannot be properly parsed. The message contains a 4913 single Object Value Info object, unless otherwise stated below. This 4914 error code is split into subcodes as follows: 4916 0: Incorrect Length: The overall length does not match the object 4917 length calculated from the object contents. 4919 1: Value Not Supported: The value of a field is not supported by the 4920 GIST node. 4922 2: Invalid Flag-Field Combination: An object contains an invalid 4923 combination of flags and/or fields. At the moment this only 4924 relates to the Path-Coupled MRM object, but in future there may be 4925 more. 4927 3: Empty List: At the moment this only relates to Stack-Proposals. 4928 The error message is sent if a stack proposal with a length > 0 (a 4929 length of 0 is handled as "Value Not Supported") contains only 4930 null bytes. 4932 4: Invalid Cookie: The message contains a cookie which could not be 4933 verified by the node. 4935 5: SP-SCD Mismatch: This subcode is used if a GIST node receives a 4936 message in which the data in the Stack-Proposal object is 4937 inconsistent with the information in the Stack Configuration Data 4938 object. In this case, both the Stack-Proposal object and Stack- 4939 Configuration-Data object are included in the message, in separate 4940 Object Value Info fields. 4942 A.4.4.11. Invalid IP TTL 4944 Class: Permanent-Failure 4945 Code: 11 4946 Additional Info: None 4948 This error indicates that a message was received with an IP-TTL 4949 outside an acceptable range; for example, that an upstream Query was 4950 received with an IP-TTL of less than 254 (i.e. more than one IP hop 4951 from the sender). The actual IP distance can be derived from the IP- 4952 TTL information in the NLI object carried in the same message. 4954 A.4.4.12. MRI Validation Failure 4956 Class: Permanent-Failure 4957 Code: 12 4958 Additional Info: Object Value Info 4960 This error indicates that a message was received with an MRI that 4961 could not be accepted, e.g. because of too much wildcarding or 4962 failing some validation check (cf. Section 5.8.1.2). The Object 4963 Value Info includes the MRI so the error originator can indicate the 4964 part of the MRI which caused the problem. The error code is divided 4965 into subcodes as follows: 4967 0: MRI Too Wild: The MRI contained too much wildcarding (e.g. too 4968 short a destination address prefix) to be forwarded correctly down 4969 a single path. 4971 1: IP Version Mismatch: The MRI in a path-coupled Query message uses 4972 an IP version which is not implemented on the interface used. 4974 2: Ingress Filter Failure: The MRI in a path-coupled Query message 4975 describes a flow which would not pass ingress filtering on the 4976 interface used. 4978 Appendix B. API between GIST and Signaling Applications 4980 This appendix provides an abstract API between GIST and signaling 4981 applications. It should not constrain implementors, but rather help 4982 clarify the interface between the different layers of the NSIS 4983 protocol suite. In addition, although some of the data types carry 4984 the information from GIST information elements, this does not imply 4985 that the format of that data as sent over the API has to be the same. 4987 Conceptually the API has similarities to the sockets API, 4988 particularly that for unconnected UDP sockets. An extension for an 4989 API like that for UDP connected sockets could be considered. In this 4990 case, for example, the only information needed in a SendMessage 4991 primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle 4992 (which can be null). Other information which was persistent for a 4993 group of messages could be configured once for the socket. Such 4994 extensions may make a concrete implementation more efficient but do 4995 not change the API semantics, and so are not considered further here. 4997 B.1. SendMessage 4999 This primitive is passed from a signaling application to GIST. It is 5000 used whenever the signaling application wants to initiate sending a 5001 message. 5003 SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, 5004 NSLPID, Session-ID, MRI, 5005 SII-Handle, Transfer-Attributes, Timeout, IP-TTL, GHC ) 5007 The following arguments are mandatory. 5009 NSLP-Data: The NSLP message itself. 5011 NSLP-Data-Size: The length of NSLP-Data. 5013 NSLP-Message-Handle: A handle for this message, that can be used by 5014 GIST as a reference in subsequent MessageStatus notifications 5015 (Appendix B.3). Notifications could be about error conditions or 5016 about the security attributes that will be used for the message. 5017 A NULL handle may be supplied if the NSLP is not interested in 5018 such notifications. 5020 NSLPID: An identifier indicating which NSLP this is. 5022 Session-ID: The NSIS session identifier. Note that it is assumed 5023 that the signaling application provides this to GIST rather than 5024 GIST providing a value itself. 5026 MRI: Message routing information for use by GIST in determining the 5027 correct next GIST hop for this message. The MRI implies the 5028 message routing method to be used and the message direction. 5030 The following arguments are optional. 5032 SII-Handle: A handle, previously supplied by GIST, to a data 5033 structure that should be used to route the message explicitly to a 5034 particular GIST next hop. 5036 Transfer-Attributes: Attributes defining how the message should be 5037 handled (see Section 4.1.2). The following attributes can be 5038 considered: 5040 Reliability: Values 'unreliable' or 'reliable'. 5042 Security: This attribute allows the NSLP to specify what level of 5043 security protection is requested for the message (selected from 5044 'integrity' and 'confidentiality'), and can also be used to 5045 specify what authenticated signaling source and destination 5046 identities should be used to send the message. The 5047 possibilities can be learned by the signaling application from 5048 prior MessageStatus or RecvMessage notifications. If an NSLP- 5049 Message-Handle is provided, GIST will inform the signaling 5050 application of what values it has actually chosen for this 5051 attribute via a MessageStatus callback. This might take place 5052 either synchronously (where GIST is selecting from available 5053 messaging associations), or asynchronously (when a new 5054 messaging association needs to be created). 5056 Local Processing: This attribute contains hints from the signaling 5057 application about what local policy should be applied to the 5058 message; in particular, its transmission priority relative to 5059 other messages, or whether GIST should attempt to set up or 5060 maintain forward routing state. 5062 Timeout: Length of time GIST should attempt to send this message 5063 before indicating an error. 5065 IP-TTL: The value of the IP TTL that should be used when sending this 5066 message (may be overridden by GIST for particular messages). 5068 GHC: The value for the GIST hop count when sending the message. 5070 B.2. RecvMessage 5072 This primitive is passed from GIST to a signaling application. It is 5073 used whenever GIST receives a message from the network, including the 5074 case of 'null' messages (zero length NSLP payload), typically initial 5075 Query messages. For Queries, the results of invoking this primitive 5076 are used by GIST to check whether message routing state should be 5077 created (see the discussion of the 'Routing-State-Check' argument 5078 below). 5080 RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLPID, Session-ID, MRI, 5081 Routing-State-Check, SII-Handle, Transfer-Attributes, 5082 IP-TTL, IP-Distance, GHC ) 5084 NSLP-Data: The NSLP message itself (may be empty). 5086 NSLP-Data-Size: The length of NSLP-Data (may be zero). 5088 NSLPID: An identifier indicating which NSLP this is message is for. 5090 Session-ID: The NSIS session identifier. 5092 MRI: Message routing information that was used by GIST in forwarding 5093 this message. Implicitly defines the message routing method that 5094 was used and the direction of the message relative to the MRI. 5096 Routing-State-Check: This boolean is True if GIST is checking with 5097 the signaling application to see if routing state should be 5098 created with the peer or the message should be forwarded further 5099 (see Section 4.3.2). If True, the signaling application should 5100 return the following values via the RecvMessage call: 5102 A boolean indicating whether to set up the state. 5104 Optionally, an NSLP-Payload to carry in the generated GIST- 5105 Response or forwarded Query message respectively. 5107 This mechanism could be extended to enable the signaling 5108 application to indicate to GIST whether state installation should 5109 be immediate or deferred (see Section 5.3.3 and Section 6.3 for 5110 further discussion). 5112 SII-Handle: A handle to a data structure, identifying a peer address 5113 and interface. Can be used to identify route changes and for 5114 explicit routing to a particular GIST next hop. 5116 Transfer-Attributes: The reliability and security attributes that 5117 were associated with the reception of this particular message. As 5118 well as the attributes associated with SendMessage, GIST may 5119 indicate the level of verification of the addresses in the MRI. 5120 Three attributes can be indicated: 5122 * Whether the signaling source address is one of the flow 5123 endpoints (i.e. whether this is the first or last GIST hop); 5125 * Whether the signaling source address has been validated by a 5126 return routability check. 5128 * Whether the message was explicitly routed (and so has not been 5129 validated by GIST as delivered consistently with local routing 5130 state). 5132 IP-TTL: The value of the IP TTL this message was received with (if 5133 available). 5135 IP-Distance: The number of IP hops from the peer signaling node which 5136 sent this message along the path, or 0 if this information is not 5137 available. 5139 GHC: The value of the GIST hop count the message was received with, 5140 after being decremented in the GIST receive-side processing. 5142 B.3. MessageStatus 5144 This primitive is passed from GIST to a signaling application. It is 5145 used to notify the signaling application that a message that it 5146 requested to be sent could not be dispatched, or to inform the 5147 signaling application about the transfer attributes that have been 5148 selected for the message (specifically, security attributes). The 5149 signaling application can respond to this message with a return code 5150 to abort the sending of the message if the attributes are not 5151 acceptable. 5153 MessageStatus (NSLP-Message-Handle, Transfer-Attributes, Error-Type) 5155 NSLP-Message-Handle: A handle for the message provided by the 5156 signaling application in SendMessage. 5158 Transfer-Attributes: The reliability and security attributes that 5159 will be used to transmit this particular message. 5161 Error-Type: Indicates the type of error that occurred. For example, 5162 'no next node found'. 5164 B.4. NetworkNotification 5166 This primitive is passed from GIST to a signaling application. It 5167 indicates that a network event of possible interest to the signaling 5168 application occurred. 5170 NetworkNotification ( NSLPID, MRI, Network-Notification-Type ) 5172 NSLPID: An identifier indicating which NSLP this is message is for. 5174 MRI: Provides the message routing information to which the network 5175 notification applies. 5177 Network-Notification-Type: Indicates the type of event that caused 5178 the notification and associated additional data. Two events have 5179 been identified: 5181 Last Node: GIST has detected that this is the last NSLP-aware node 5182 in the path. See Section 4.3.4. 5184 Routing Status Change: GIST has installed new routing state, or 5185 has detected that the routing state may no longer be valid, or 5186 has re-established the routing state. See Section 7.1.3. The 5187 new status is reported; if the status is Good, the SII-Handle 5188 of the peer is also reported, as for RecvMessage. 5190 B.5. SetStateLifetime 5192 This primitive is passed from a signaling application to GIST. It 5193 indicates the duration for which the signaling application would like 5194 GIST to retain its routing state. It can also give a hint that the 5195 signaling application is no longer interested in the state. 5197 SetStateLifetime ( NSLPID, MRI, State-Lifetime ) 5199 NSLPID: Provides the NSLPID to which the routing state lifetime 5200 applies. 5202 MRI: Provides the message routing information to which the routing 5203 state lifetime applies; includes the direction (in the D flag). 5205 State-Lifetime: Indicates the lifetime for which the signaling 5206 application wishes GIST to retain its routing state (may be zero, 5207 indicating that the signaling application has no further interest 5208 in the GIST state). 5210 B.6. InvalidateRoutingState 5212 This primitive is passed from a signaling application to GIST. It 5213 indicates that the signaling application has knowledge that the next 5214 signaling hop known to GIST may no longer be valid, either because of 5215 changes in the network routing or the processing capabilities of 5216 signaling application nodes. See Section 7.1. 5218 InvalidateRoutingState ( NSLPID, MRI, Status, Urgent ) 5220 NSLPID: The NSLP originating the message. May be null (in which case 5221 the invalidation applies to all signaling applications). 5223 MRI: The flow for which routing state should be invalidated; includes 5224 the direction of the change (in the D flag). 5226 Status: The new status that should be assumed for the routing state, 5227 one of Bad or Tentative (see Section 7.1.3). 5229 Urgent: A hint as to whether rediscovery should take place 5230 immediately, or only with the next signaling message. 5232 Appendix C. Example Routing State Table and Handshake Message Sequence 5234 Figure 10 shows a signaling scenario for a single flow being managed 5235 by two signaling applications using the path-coupled message routing 5236 method. The flow sender and receiver and one router support both, 5237 two other routers support one each. The figure also shows the 5238 routing state table at node B. 5240 A B C D E 5241 +------+ +-----+ +-----+ +-----+ +--------+ 5242 | Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow | 5243 |Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver| 5244 | | +-+ +-+ |GIST | |GIST | |GIST | | | 5245 +------+ +-----+ +-----+ +-----+ +--------+ 5246 Flow Direction ------------------------------>> 5248 +------------------------------------+---------+--------+-----------+ 5249 | Message Routing Information | Session | NSLP | Routing | 5250 | | ID | ID | State | 5251 +------------------------------------+---------+--------+-----------+ 5252 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | IP-A | 5253 | {IP-A, IP-E, proto/ports}; D=up | | | | 5254 | | | | | 5255 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | (null) | 5256 | {IP-A, IP-E, proto/ports}; D=down | | | | 5257 | | | | | 5258 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | IP-A | 5259 | {IP-A, IP-E, proto/ports}; D=up | | | | 5260 | | | | | 5261 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | Points to | 5262 | {IP-A, IP-E, proto/ports}; D=down | | | B-D MA | 5263 +------------------------------------+---------+--------+-----------+ 5265 Figure 10: A Signaling Scenario 5267 The upstream state is just the same address for each application. 5268 For the downstream direction, NSLP1 only requires datagram mode 5269 messages and so no explicit routing state towards C is needed. NSLP2 5270 requires a messaging association for its messages towards node D, and 5271 node C does not process NSLP2 at all, so the peer state for NSLP2 is 5272 a pointer to a messaging association that runs directly from B to D. 5273 Note that E is not visible in the state table (except implicitly in 5274 the address in the message routing information); routing state is 5275 stored only for adjacent peers. (In addition to the peer 5276 identification, IP hop counts are stored for each peer where the 5277 state itself if not null; this is not shown in the table.) 5279 Figure 11 shows the message sequence for a GIST handshake that sets 5280 up the messaging association for B-D signaling. It shows the 5281 exchange of Stack Proposals and MA-protocol-options data in each 5282 direction. Then the Querying node selects TLS/TCP as the stack 5283 configuration to use and sets up the messaging association over which 5284 it sends the Confirm. 5286 -----------------------GIST-Query ---------------------> 5287 IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST) 5288 GIST(Header(Type=Query; NSLPID=NSLP2; R=1; S=0) 5289 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 5290 SessionID(0x1234) 5291 NLI(Peer='string1'; IA=IP#B) 5292 QueryCookie(0x139471239471923526) 5293 StackProposal(#Proposals=3;1=TLS/TCP; 2=TLS/SCTP; 3=TCP) 5294 StackConfigurationData(#MPO=2; 5295 TCP(Applicable: all; Data: null) 5296 SCTP(Applicable: all; Data: null))) 5298 <---------------------GIST-Response--------------------- 5299 IP(Src=IP#D; Dst=IP#B); UDP(Src=GIST; Dst=6789) 5300 GIST(Header(Type=Response; NSLPID=NSLP2; R=1; S=1) 5301 MRI(MRM=Path-Coupled; Flow=F; Direction=up) 5302 SessionID(0x1234) 5303 NLI(Peer='stringr2', IA=IP#D) 5304 QueryCookie(0x139471239471923526) 5305 ResponderCookie(0xacdefedcdfaeeeded) 5306 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP) 5307 StackConfigurationData(#MPO=3; 5308 TCP(Applicable: 3; Data: port=6123) 5309 TCP(Applicable: 1; Data: port=5438) 5310 SCTP(Applicable: all; Data: port=3333))) 5312 -------------------------TCP SYN-----------------------> 5313 <----------------------TCP SYN/ACK---------------------- 5314 -------------------------TCP ACK-----------------------> 5315 TCP connect(IP Src=IP#B; IP Dst=IP#D; Src Port=9166; Dst Port=6123) 5316 <-----------------------TLS INIT-----------------------> 5318 ----------------------GIST-Confirm---------------------> 5319 [Sent within messaging association] 5320 GIST(Header(Type=Confirm; NSLPID=NSLP2; R=0; S=1) 5321 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 5322 SessionID(0x1234) 5323 NLI(Peer='string1'; IA=IP#B) 5324 ResponderCookie(0xacdefedcdfaeeeded) 5325 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)) 5327 Figure 11: GIST Handshake Message Sequence 5329 Appendix D. Change History 5331 D.1. Changes In Version -09 5333 1. Added a new Section 3.5 clarifying the relationship between 5334 signaling applications and NSLPIDs; modified terminology in the 5335 remainder of the document likewise. 5337 2. Added a new Section 8.6 explaining the rationale behind the 5338 downgrade attack prevention mechanism. 5340 3. Re-wrote parts of Section 4.3.2, Section 6.1 and Appendix B.2 to 5341 clarify the way that GIST is assumed to interact with signaling 5342 applications to exercise policy control over whether or not two 5343 nodes become signaling peers during a GIST handshake. 5345 4. Generalised an error message Appendix A.4.4.12 to cover 5346 additional MRI validation checks in Section 4.3.4 and 5347 Section 5.8.1.2. 5349 5. Allowed an optional Stack-Configuration-Data object in Confirm 5350 messages to allow messaging association lifetime to be 5351 negotiated even in the case of late state installation at the 5352 Responding node (see Section 4.4.1 and Section 4.4.3). 5354 6. Removed the option in Section 4.4.2 of allowing a node to treat 5355 messaging associations with the same authenticated end points as 5356 equivalent. 5358 7. Include additional guidance in Section 4.4.3 to prevent routing 5359 state being erroneously refreshed in the case of rerouting 5360 events; also included general guidance notes on timer setting. 5362 8. Clarified that the Stack-Proposal lists protocols in top-to- 5363 bottom order (see Section 5.7.1). 5365 9. Enhanced the definition of TLS usage in Section 5.7.3 with 5366 details on ciphersuite requirements and authentication methods. 5368 10. Tidied up terminology and discussion of how protocol options 5369 data is carried in the SCD; renamed higher-layer-addressing to 5370 MA-protocol-options. 5372 D.2. Changes In Version -08 5374 1. Changed the protocol name from GIMPS to GIST (everywhere). 5376 2. Inserted RFC2119 language (MUST etc.) in the appropriate places. 5378 3. Added references to the actions to be taken in various error 5379 conditions, including the error messages to be send 5380 (throughout). 5382 4. Added legacy NAT traversal to the list of excluded functions in 5383 Section 1.1. 5385 5. Included some text at the end of Section 3.3 analysing the case 5386 of a GIST node which does not support a particular MRM. 5388 6. Added a flag to mark when messages have been explicitly routed, 5389 so they can bypass validation against current routing state (see 5390 Section 4.3.1, TBD). 5392 7. Re-wrote the discussion in Section 4.3.4 to cover all cases of 5393 nodes not hosting an NSLP (including end systems), in particular 5394 the validations that can be performed at intermediate GIST nodes 5395 (this replaces the old section 7.2). 5397 8. Clarified the rules about R and S flag setting in the common 5398 header and D flag in the MRI (Section 5). 5400 9. Included discussion of how a node with a choice of interfaces or 5401 IP versions should select one to use in the NLI (Section 5.2.2). 5403 10. Modified the description of messaging association protocol 5404 selections (Section 5.7 and elsewhere) to clarify that this is 5405 essentially capability discovery rather than an open ended 5406 protocol negotiation. 5408 11. Modified the description of how higher layer addressing 5409 information is carried (Section 5.7.1 and Appendix A.3.5) to 5410 allow the data to be tagged against a specific profile if 5411 necessary, or omitted if the protocol does not need it. 5413 12. Added a higher layer protocol definition for TLS in 5414 Section 5.7.3. 5416 13. Simplified and restructured the state machine presentation in 5417 Section 6, in particular using a single list for the events and 5418 eliminating the transition tables. Also modified the operation 5419 of the Responder machine to handle retransmitted Query messages 5420 correctly. 5422 14. Re-wrote the route change handling text in Section 7.1 to 5423 clarify the relative responsibilities of GIST and NSLPs and 5424 their interaction through the API. Notifications are now 5425 assumed to be a signaling application responsibility, and GIST 5426 behaviour is defined in terms of handling changes in a 3-state 5427 model of the correctness of the routing state for each 5428 direction. 5430 15. Updated the NAT traversal description in Section 7.2, including 5431 normative text about how GIST nodes should handle messages 5432 containing NAT-Traversal objects. 5434 16. Likewise, clarified that the responsibility for session/flow 5435 binding in the case of tunnelling is handled by NSLPs 5436 (Section 7.3). 5438 17. Formalised the IANA considerations (Section 9). 5440 18. Extended the routing state example (Appendix C) to include a 5441 message sequence for association setup. 5443 19. Re-arranged the sequence of sections, including placing this 5444 change history at the end. 5446 D.3. Changes In Version -07 5448 1. The open issues section has finally been removed in favour of the 5449 authoritative list of open issues in an online issue tracker at h 5450 ttp://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index. 5452 2. Clarified terminology on peering and adjacencies that there may 5453 be NSIS nodes between GIMPS peers that do some message 5454 processing, but that are not explicitly visible in the peer state 5455 tables. 5457 3. Added a description of the loose-end MRM (Section 5.8.2 and 5458 Appendix A.3.1.2). 5460 4. Added a description of an upstream Query encapsulation for the 5461 path-coupled MRM, Section 5.8.1.3, including rationale for and 5462 restrictions on its use. 5464 5. The formal description of the protocol in Section 6 has been 5465 significantly updated and extended in terms of detail. 5467 6. Modified the description of the interaction between NSLPs and 5468 GIMPS for handling inbound messages for which no routing state 5469 exists, to allow the NSLP to indicate whether state setup should 5470 proceed and to provide NSLP payloads for the Response or 5471 forwarded message (Section 3.6, Section 4.3.2 and Appendix B). 5473 7. Included new text, Section 5.6, on the processing and 5474 encapsulation of error messages. Also added formats and an error 5475 message catalogue in Appendix A.4, including a modified format 5476 for the overall GIMPS-Error message and the GIMPS-Error-Data 5477 object. 5479 8. Removed the old section 5.3.3 on NSLPID/RAO setting on the 5480 assumption that this will be covered in the extensibility 5481 document. 5483 9. Included a number of other minor corrections and clarifications. 5485 D.4. Changes In Version -06 5487 Version -06 does not introduce any major structural changes to the 5488 protocol definition, although it does clarify a number of details and 5489 resolve some outstanding open issues. The primary changes are as 5490 follows: 5492 1. Added a new high level Section 3.3 which gathers together the 5493 various aspects of the message routing method concept. 5495 2. Added a new high level Section 3.4 which explains the concept 5496 and significance of the session identifier. Also clarified that 5497 the routing state always depends on the session identifier. 5499 3. Added notes about the level of address validation performed by 5500 GIMPS in Section 4.1.2 and extensions to the API in Appendix B. 5502 4. Split the old Node-Addressing object into a Network-Layer- 5503 Information object and Stack-Configuration-Data object. The 5504 former refers to basic information about a node, and the latter 5505 carries information about messaging association configuration. 5506 Redefined the content of the various handshake messages 5507 accordingly in Section 4.4.1 and Section 5.1. 5509 5. Re-wrote Section 4.4.3 to clarify the rules on refresh and purge 5510 of routing state and messaging associations. Also, moved the 5511 routing state lifetime into the Network-Layer-Information object 5512 and added a messaging association lifetime to the Stack- 5513 Configuration-Data object (Section 5.2). 5515 6. Added specific message types for errors and MA-Refresh in 5516 Section 5.1. The error object is now GIMPS-specific 5517 (Appendix A.4.1). 5519 7. Moved the Flow-Identifier information about the message routing 5520 method from the general description of the object to the path- 5521 coupled MRM section (Section 5.8.1.1), and made a number of 5522 clarifications to the bit format (Appendix A.3.1.1). 5524 8. Removed text about assumptions on the version numbering of 5525 NSLPs, and restricted the scope of the description of TLV object 5526 formats and extensibility flags to GIMPS rather than the whole 5527 of NSIS (Appendix A). 5529 9. Added a new Section 5.5 explaining the possible relationships 5530 between message types and encapsulation formats. 5532 10. Added a new Section 6 in outline form, to capture the formal 5533 specification of the protocol operation. 5535 11. Added new security sections on cookie requirements (Section 8.5) 5536 and residual threats (Section 8.7). 5538 D.5. Changes In Version -05 5540 Version -05 reformulates the specification, to describe routing state 5541 maintenance in terms of exchanging explicitly identified Query/ 5542 Response/Confirm messages, leaving the upstream/downstream 5543 distinction as a specific detail of how Query messages are 5544 encapsulated. This necessitated widespread changes in the 5545 specification text, especially Section 4.2.1, Section 4.4, 5546 Section 5.1 and Section 5.3 (although the actual message sequences 5547 are unchanged). A number of other issues, especially in the area of 5548 message encapsulation, have also been closed. The main changes are 5549 the following: 5551 1. Added a reference to an individual draft on the Loose End MRM as 5552 a concrete example of an alternative message routing method. 5554 2. Added further text (particularly in Section 2) on what GIMPS 5555 means by the concept of 'session'. 5557 3. Firmed up the selection of UDP as the encapsulation choice for 5558 datagram mode, removing the open issue on this topic. 5560 4. Defined the interaction between GIMPS and signaling applications 5561 for communicating about the cryptographic security properties of 5562 how a message will be sent or has been received (see 5563 Section 4.1.2 and Appendix B). 5565 5. Closed the issue on whether Query messages should use the 5566 signaling or flow source address in the IP header; both options 5567 are allowed by local policy and a flag in the common header 5568 indicates which was used. (See Section 5.8.1.2.) 5570 6. Added the necessary information elements to allow the IP hop 5571 count between adjacent GIMPS peers to be measures and reported. 5572 (See Section 5.2.2 and Appendix A.3.3.) 5574 7. The old open-issue text on selection of IP router alert option 5575 values has been moved into the main specification to capture the 5576 technical considerations that should be used in assigning such 5577 values (in old section 5.3.3). 5579 8. Resolved the open issue on lost Confirm messages by allowing a 5580 choice of timer-based retransmission of the Response, or an 5581 error message from the responding node which causes the 5582 retransmission of the Confirm (see Section 5.3.3). 5584 9. Closed the open issue on support for message scoping (this is 5585 now assumed to be a NSLP function). 5587 10. Moved the authoritative text for most of the remaining open 5588 issues to an online issue tracker. 5590 D.6. Changes In Version -04 5592 Version -04 includes mainly clarifications of detail and extensions 5593 in particular technical areas, in part to support ongoing 5594 implementation work. The main details are as follows: 5596 1. Substantially updated Section 4, in particular clarifying the 5597 rules on what messages are sent when and with what payloads 5598 during routing and messaging association setup, and also adding 5599 some further text on message transfer attributes. 5601 2. The description of messaging association protocol setup 5602 including the related object formats has been centralised in a 5603 new Section 5.7, removing the old Section 6.6 and also closing 5604 old open issues 8.5 and 8.6. 5606 3. Made a number of detailed changes in the message format 5607 definitions (Appendix A), as well as incorporating initial rules 5608 for encoding message extensibility information. Also included 5609 explicit formats for a general purpose Error object, and the 5610 objects used to discover supported messaging association 5611 protocols. Updated the corresponding open issues section (old 5612 section 9.3) with a new item on NSLP versioning. 5614 4. Updated the GIMPS API (Appendix B), including more precision on 5615 message transfer attributes, making the NSLP hint about storing 5616 reverse path state a return value rather than a separate 5617 primitive, and adding a new primitive to allow signaling 5618 applications to invalidate GIMPS routing state. Also, added a 5619 new parameter to SendMessage to allow signaling applications to 5620 'bypass' a message statelessly, preserving the source of an 5621 input message. 5623 5. Added an outline for the future content of an IANA 5624 considerations section (Section 9). Currently, this is 5625 restricted to identifying the registries and allocations 5626 required, without defining the allocation policies and other 5627 considerations involved. 5629 6. Shortened the background design discussion in Section 3. 5631 7. Made some clarifications in the terminology section relating to 5632 how the use of C-mode does and does not mandate the use of 5633 transport or security protection. 5635 8. The ABNF for message formats in Section 5.1 has been re-written 5636 with a grammar structured around message purpose rather than 5637 message direction, and additional explanation added to the 5638 information element descriptions in Section 5.2. 5640 9. The description of the datagram mode transport in Section 5.3 5641 has been updated. The encapsulation rules (covering IP 5642 addressing and UDP port allocation) have been corrected, and a 5643 new subsection on message retransmission and rate limiting has 5644 been added, superseding the old open issue on the same subject 5645 (section 8.10). 5647 10. A new open issue on IP TTL measurement to detect non-GIMPS 5648 capable hops has been added (old section 9.5). 5650 D.7. Changes In Version -03 5652 Version -03 includes a number of minor clarifications and extensions 5653 compared to version -02, including more details of the GIMPS API and 5654 messaging association setup and the node addressing object. The full 5655 list of changes is as follows: 5657 1. Added a new section pinning down more formally the interaction 5658 between GIMPS and signaling applications (Section 4.1), in 5659 particular the message transfer attributes that signaling 5660 applications can use to control GIMPS (Section 4.1.2). 5662 2. Added a new open issue identifying where the interaction between 5663 the security properties of GIMPS and the security requirements of 5664 signaling applications should be identified (old section 9.10). 5666 3. Added some more text in Section 4.2.1 to clarify that GIMPS has 5667 the (sole) responsibility for generating the messages that 5668 refresh message routing state. 5670 4. Added more clarifying text and table to GHC and IP TTL handling 5671 discussion of Section 4.3.4. 5673 5. Split Section 4.4 into subsections for different scenarios, and 5674 added more detail on Node-Addressing object content and use to 5675 handle the case where association re-use is possible in 5676 Section 4.4.2. 5678 6. Added strawman object formats for Node-Addressing and Stack- 5679 Proposal objects in Section 5.1 and Appendix A. 5681 7. Added more detail on the bundling possibilities and appropriate 5682 configurations for various transport protocols in Section 5.4.1. 5684 8. Included some more details on NAT traversal in Section 7.2, 5685 including a new object to carry the untranslated address-bearing 5686 payloads, the NAT-Traversal object. 5688 9. Expanded the open issue discussion in old section 9.3 to include 5689 an outline set of extensibility flags. 5691 D.8. Changes In Version -02 5693 Version -02 does not represent any radical change in design or 5694 structure from version -01; the emphasis has been on adding details 5695 in some specific areas and incorporation of comments, including early 5696 review comments. The full list of changes is as follows: 5698 1. Added a new Section 1.1 which summarises restrictions on scope 5699 and applicability; some corresponding changes in terminology in 5700 Section 2. 5702 2. Closed the open issue on including explicit GIMPS state teardown 5703 functionality. On balance, it seems that the difficulty of 5704 specifying this correctly (especially taking account of the 5705 security issues in all scenarios) is not matched by the saving 5706 of state enabled. 5708 3. Removed the option of a special class of message transfer for 5709 reliable delivery of a single message. This can be implemented 5710 (inefficiently) as a degenerate case of C-mode if required. 5712 4. Extended Appendix A with a general discussion of rules for 5713 message and object formats across GIMPS and other NSLPs. Some 5714 remaining open issues are noted in old section 9.3 (since 5715 removed). 5717 5. Updated the discussion of RAO/NSLPID relationships to take into 5718 account the proposed message formats and rules for allocation of 5719 NSLP id, and propose considerations for allocation of RAO 5720 values. 5722 6. Modified the description of the information used to route 5723 messages (first given in Section 4.2.1 but also throughout the 5724 document). Previously this was related directly to the flow 5725 identification and described as the Flow-Routing-Information. 5726 Now, this has been renamed Message-Routing-Information, and 5727 identifies a message routing method and any associated 5728 addressing. 5730 7. Modified the text in Section 4.3 and elsewhere to impose sanity 5731 checks on the Message-Routing-Information carried in C-mode 5732 messages, including the case where these messages are part of a 5733 GIMPS-Query/Response exchange. 5735 8. Added rules for message forwarding to prevent message looping in 5736 a new Section 4.3.4, including rules on IP TTL and GIMPS hop 5737 count processing. These take into account the new RAO 5738 considerations described above. 5740 9. Added an outline mechanism for messaging association protocol 5741 stack setup, with the details in a new Section 6.6 and other 5742 changes in Section 4.4 and the various sections on message 5743 formats. 5745 10. Removed the open issue on whether storing reverse routing state 5746 is mandatory or optional. This is now explicit in the API 5747 (under the control of the local NSLP). 5749 11. Added an informative annex describing an abstract API between 5750 GIMPS and NSLPs in Appendix B. 5752 D.9. Changes In Version -01 5754 The major change in version -01 is the elimination of 5755 'intermediaries', i.e. imposing the constraint that signaling 5756 application peers are also GIMPS peers. This has the consequence 5757 that if a signaling application wishes to use two classes of 5758 signaling transport for a given flow, maybe reaching different 5759 subsets of nodes, it must do so by running different signaling 5760 sessions; and it also means that signaling adaptations for passing 5761 through NATs which are not signaling application aware must be 5762 carried out in datagram mode. On the other hand, it allows the 5763 elimination of significant complexity in the connection mode handling 5764 and also various other protocol features (such as general route 5765 recording). 5767 The full set of changes is as follows: 5769 1. Added a worked example in Section 3.6. 5771 2. Stated that nodes which do not implement the signaling 5772 application should bypass the message (Section 4.3). 5774 3. Decoupled the state handling logic for routing state and 5775 messaging association state in Section 4.4. Also, allow 5776 messaging associations to be used immediately in both directions 5777 once they are opened. 5779 4. Added simple ABNF for the various GIMPS message types in a new 5780 Section 5.1, and more details of the common header and each 5781 object in Section 5.2, including bit formats in Appendix A. The 5782 common header format means that the encapsulation is now the 5783 same for all transport types (Section 5.4.1). 5785 5. Added some further details on datagram mode encapsulation in 5786 Section 5.3, including more explanation of why a well known port 5787 is needed. 5789 6. Removed the possibility for fragmentation over DCCP 5790 (Section 5.4.1), mainly in the interests of simplicity and loss 5791 amplification. 5793 7. Removed all the tunnel mode encapsulations (old sections 5.3.3 5794 and 5.3.4). 5796 8. Fully re-wrote the route change handling description 5797 (Section 7.1), including some additional detection mechanisms 5798 and more clearly distinguishing between upstream and downstream 5799 route changes. Included further details on GIMPS/NSLP 5800 interactions, including where notifications are delivered and 5801 how local repair storms could be avoided. Removed old 5802 discussion of propagating notifications through signaling 5803 application unaware nodes (since these are now bypassed 5804 automatically). Added discussion on how to route messages for 5805 local state removal on the old path. 5807 9. Revised discussion of policy-based forwarding (old Section 7.2) 5808 to account for actual Flow-Routing-Information definition, and 5809 also how wildcarding should be allowed and handled. 5811 10. Removed old route recording section (old Section 6.3). 5813 11. Extended the discussion of NAT handling (Section 7.2) with an 5814 extended outline on processing rules at a GIMPS-aware NAT and a 5815 pointer to implications for C-mode processing and state 5816 management. 5818 12. Clarified the definition of 'correct routing' of signaling 5819 messages in Section 8 and GIMPS role in enforcing this. Also, 5820 opened the possibility that peer node authentication could be 5821 signaling application dependent. 5823 13. Removed old open issues on Connection Mode Encapsulation 5824 (section 8.7); added new open issues on Message Routing (old 5825 Section 9.3 of version -05, later moved to Section 3.3) and 5826 Datagram Mode congestion control. 5828 14. Added this change history. 5830 Authors' Addresses 5832 Henning Schulzrinne 5833 Columbia University 5834 Department of Computer Science 5835 450 Computer Science Building 5836 New York, NY 10027 5837 US 5839 Phone: +1 212 939 7042 5840 Email: hgs+nsis@cs.columbia.edu 5841 URI: http://www.cs.columbia.edu 5843 Robert Hancock 5844 Siemens/Roke Manor Research 5845 Old Salisbury Lane 5846 Romsey, Hampshire SO51 0ZN 5847 UK 5849 Email: robert.hancock@roke.co.uk 5850 URI: http://www.roke.co.uk 5852 Intellectual Property Statement 5854 The IETF takes no position regarding the validity or scope of any 5855 Intellectual Property Rights or other rights that might be claimed to 5856 pertain to the implementation or use of the technology described in 5857 this document or the extent to which any license under such rights 5858 might or might not be available; nor does it represent that it has 5859 made any independent effort to identify any such rights. Information 5860 on the procedures with respect to rights in RFC documents can be 5861 found in BCP 78 and BCP 79. 5863 Copies of IPR disclosures made to the IETF Secretariat and any 5864 assurances of licenses to be made available, or the result of an 5865 attempt made to obtain a general license or permission for the use of 5866 such proprietary rights by implementers or users of this 5867 specification can be obtained from the IETF on-line IPR repository at 5868 http://www.ietf.org/ipr. 5870 The IETF invites any interested party to bring to its attention any 5871 copyrights, patents or patent applications, or other proprietary 5872 rights that may cover technology that may be required to implement 5873 this standard. Please address the information to the IETF at 5874 ietf-ipr@ietf.org. 5876 Disclaimer of Validity 5878 This document and the information contained herein are provided on an 5879 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5880 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 5881 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 5882 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 5883 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5884 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5886 Copyright Statement 5888 Copyright (C) The Internet Society (2006). This document is subject 5889 to the rights, licenses and restrictions contained in BCP 78, and 5890 except as set forth therein, the authors retain all their rights. 5892 Acknowledgment 5894 Funding for the RFC Editor function is currently provided by the 5895 Internet Society.