idnits 2.17.1 draft-ietf-nsis-ntlp-10.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 6336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 6313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6326. ** 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 32. Fixed rfc2119 capitalisation of MUST not in Appendix A.3.5 [AD review comment N8]. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 25, 2006) is 6485 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 255 -- Looks like a reference, but probably isn't: 'Flow' on line 269 -- Looks like a reference, but probably isn't: 'Adjacent' on line 279 -- Looks like a reference, but probably isn't: 'Initialisation' on line 3014 ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2765 (ref. '6') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2246 (ref. '7') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4234 (ref. '9') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4346 (ref. '10') (Obsoleted by RFC 5246) -- Possible downref: Normative reference to a draft: ref. '11' -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '15') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '16') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. '18') (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '23') (Obsoleted by RFC 5389) == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-01 -- Obsolete informational reference (is this intentional?): RFC 3682 (ref. '25') (Obsoleted by RFC 5082) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-12 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-11 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-06 == Outdated reference: A later version (-05) exists of draft-pashalidis-nsis-gimps-nattraversal-03 -- Obsolete informational reference (is this intentional?): RFC 4347 (ref. '41') (Obsoleted by RFC 6347) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Next Steps in Signaling H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: January 26, 2007 R. Hancock 5 Siemens/RMR 6 July 25, 2006 8 GIST: General Internet Signaling Transport 9 draft-ietf-nsis-ntlp-10 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 26, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies protocol stacks for the routing and transport 43 of per-flow signaling messages along the path taken by that flow 44 through the network. The design uses existing transport and security 45 protocols under a common messaging layer, the General Internet 46 Signaling Transport (GIST), which provides a universal service for 47 diverse signaling applications. GIST does not handle signaling 48 application state itself, but manages its own internal state and the 49 configuration of the underlying transport and security protocols to 50 enable the transfer of messages in both directions along the flow 51 path. The combination of GIST and the lower layer transport and 52 security protocols provides a solution for the base protocol 53 component of the "Next Steps in Signaling" framework. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Restrictions on Scope . . . . . . . . . . . . . . . . . . 5 59 2. Requirements Notation and Terminology . . . . . . . . . . . . 6 60 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 9 62 3.2. Modes and Messaging Associations . . . . . . . . . . . . 10 63 3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 11 64 3.4. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 13 65 3.5. Signaling Sessions . . . . . . . . . . . . . . . . . . . 14 66 3.6. Signaling Applications and NSLPIDs . . . . . . . . . . . 15 67 3.7. Example of Operation . . . . . . . . . . . . . . . . . . 15 68 4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 18 69 4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 18 70 4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 20 71 4.3. Basic GIST Message Processing . . . . . . . . . . . . . . 21 72 4.4. Routing State and Messaging Association Maintenance . . . 27 73 5. Message Formats and Transport . . . . . . . . . . . . . . . . 34 74 5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 34 75 5.2. Information Elements . . . . . . . . . . . . . . . . . . 36 76 5.3. D-mode Transport . . . . . . . . . . . . . . . . . . . . 40 77 5.4. C-mode Transport . . . . . . . . . . . . . . . . . . . . 43 78 5.5. Message Type/Encapsulation Relationships . . . . . . . . 45 79 5.6. Error Message Processing . . . . . . . . . . . . . . . . 46 80 5.7. Messaging Association Setup . . . . . . . . . . . . . . . 47 81 5.8. Specific Message Routing Methods . . . . . . . . . . . . 51 82 6. Formal Protocol Specification . . . . . . . . . . . . . . . . 56 83 6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 57 84 6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 59 85 6.3. Responder Node Processing . . . . . . . . . . . . . . . . 62 86 6.4. Messaging Association Processing . . . . . . . . . . . . 65 87 7. Advanced Protocol Features . . . . . . . . . . . . . . . . . 69 88 7.1. Route Changes and Local Repair . . . . . . . . . . . . . 69 89 7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 75 90 7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 79 91 7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 79 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 81 93 8.1. Message Confidentiality and Integrity . . . . . . . . . . 81 94 8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 82 95 8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 82 96 8.4. Denial of Service Prevention . . . . . . . . . . . . . . 84 97 8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 85 98 8.6. Security Protocol Selection Policy . . . . . . . . . . . 87 99 8.7. Residual Threats . . . . . . . . . . . . . . . . . . . . 88 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 101 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95 103 11.1. Normative References . . . . . . . . . . . . . . . . . . 95 104 11.2. Informative References . . . . . . . . . . . . . . . . . 95 105 Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 98 106 A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 98 107 A.2. General Object Format . . . . . . . . . . . . . . . . . . 99 108 A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 100 109 A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 109 110 Appendix B. API between GIST and Signaling Applications . . . . 117 111 B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 117 112 B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 119 113 B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 120 114 B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 121 115 B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 121 116 B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 122 117 Appendix C. Example Routing State Table and Handshake Message 118 Sequence . . . . . . . . . . . . . . . . . . . . . . 123 119 Appendix D. Change History . . . . . . . . . . . . . . . . . . . 125 120 D.1. Changes In Version -10 . . . . . . . . . . . . . . . . . 125 121 D.2. Changes In Version -09 . . . . . . . . . . . . . . . . . 128 122 D.3. Changes In Version -08 . . . . . . . . . . . . . . . . . 129 123 D.4. Changes In Version -07 . . . . . . . . . . . . . . . . . 131 124 D.5. Changes In Version -06 . . . . . . . . . . . . . . . . . 132 125 D.6. Changes In Version -05 . . . . . . . . . . . . . . . . . 133 126 D.7. Changes In Version -04 . . . . . . . . . . . . . . . . . 134 127 D.8. Changes In Version -03 . . . . . . . . . . . . . . . . . 135 128 D.9. Changes In Version -02 . . . . . . . . . . . . . . . . . 136 129 D.10. Changes In Version -01 . . . . . . . . . . . . . . . . . 137 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 140 131 Intellectual Property and Copyright Statements . . . . . . . . . 141 133 1. Introduction 135 Signaling involves the manipulation of state held in network 136 elements. 'Manipulation' could mean setting up, modifying and 137 tearing down state; or it could simply mean the monitoring of state 138 which is managed by other mechanisms. 140 This specification concentrates mainly on path-coupled signaling, 141 which involves network elements which are located on the path taken 142 by a particular data flow, possibly including but not limited to the 143 flow endpoints. Indeed, there are almost always more than two 144 participants in a path-coupled signaling session, although there is 145 no need for every node on the path to participate. Path-coupled 146 signaling thus excludes end-to-end higher-layer application 147 signaling. 149 In the context of path-coupled signaling, examples of state 150 management include network resource reservation, firewall 151 configuration, and state used in active networking; examples of state 152 monitoring are the discovery of instantaneous path properties, such 153 as available bandwidth or cumulative queuing delay. Each of these 154 different uses of signaling is referred to as a signaling 155 application. 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 [26] 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 three or four 218 interdependent addresses which all have to be consistently 219 translated, and existing generic NAT traversal techniques such as 220 STUN [23] or TURN [24] 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 RFC 2119 [2]. 229 The terminology used in this specification is defined in this 230 section. The basic entities relevant at the GIST level are shown in 231 Figure 1. In particular, this diagram distinguishes the different 232 address types as being associated with a flow (end-to-end addresses) 233 or signaling (addresses of adjacent signaling peers). 235 Source GIST (adjacent) peer nodes Destination 237 IP address IP addresses = Signaling IP address 238 = Flow Source/Destination Addresses = Flow 239 Source (depending on signaling direction) Destination 240 Address | | Address 241 V V 242 +--------+ +------+ Data Flow +------+ +--------+ 243 | Flow |-----------|------|-------------|------|-------->| Flow | 244 | Sender | | | | | |Receiver| 245 +--------+ | GIST |============>| GIST | +--------+ 246 | Node |<============| Node | 247 +------+ Signaling +------+ 248 GN1 Flow GN2 250 >>>>>>>>>>>>>>>>> = Downstream direction 251 <<<<<<<<<<<<<<<<< = Upstream direction 253 Figure 1: Basic Terminology 255 [Data] Flow: A set of packets identified by some fixed combination of 256 header fields. Flows are unidirectional; a bidirectional 257 communication is considered a pair of unidirectional flows. 259 Session: A single application layer flow of information for which 260 some state information is to be manipulated or monitored. See 261 Section 3.5 for further detailed discussion. 263 Session Identifier (SID): A long, opaque identifier for a session. 265 [Flow] Sender: The node in the network which is the source of the 266 packets in a flow. A sender could be a host, or a router if for 267 example the flow is actually an aggregate. 269 [Flow] Receiver: The node in the network which is the sink for the 270 packets in a flow. 272 Downstream: In the same direction as the data flow. 274 Upstream: In the opposite direction to the data flow. 276 GIST Node: Any node along the data path supporting GIST, regardless 277 of what signaling applications it supports. 279 [Adjacent] Peer: The next node along the data path, in the upstream 280 or downstream direction, with which a GIST node explicitly 281 interacts. The GIST peer discovery mechanisms implicitly 282 determine whether two nodes will be adjacent. It is possible for 283 adjacencies to skip over intermediate nodes which decide not to 284 take part in the signaling exchange at the NTLP layer; even if 285 such nodes process parts of the signaling messages, they store no 286 state about the session and are never visible at the GIST level to 287 the nodes on either side. 289 Datagram Mode (D-mode): A mode of sending GIST messages between nodes 290 without using any transport layer state or security protection. 291 Datagram mode uses UDP encapsulation, with source and destination 292 IP addresses derived either from the flow definition or previously 293 discovered adjacency information. 295 Connection Mode (C-mode): A mode of sending GIST messages directly 296 between nodes using point-to-point messaging associations (see 297 below). Connection mode allows the re-use of existing transport 298 and security protocols where such functionality is required. 300 Messaging Association (MA): A single connection between two 301 explicitly identified GIST adjacent peers, i.e. between a given 302 signaling source and destination address. A messaging association 303 may use a specific transport protocol and known ports. If 304 security protection is required, it may use a specific network 305 layer security association, or use a transport layer security 306 association internally. A messaging association is bidirectional; 307 signaling messages can be sent over it in either direction, and 308 can refer to flows of either direction. 310 Message Routing Method (MRM): There can be different algorithms for 311 discovering the route that signaling messages should take. These 312 are referred to as message routing methods, and GIST supports 313 alternatives within a common protocol framework. See Section 3.3. 315 Message Routing Information (MRI): The set of data item values which 316 is used to route a signaling message according to a particular 317 MRM; for example, for routing along a flow path, the MRI includes 318 flow source and destination addresses, protocol and port numbers. 319 See Section 3.3. 321 Transfer Attributes: A description of the requirements which a 322 signaling application has for the delivery of a particular 323 message; for example, whether the message should be delivered 324 reliably. See Section 4.1.2. 326 Router Alert Option (RAO): An option that can be included in IP v4 327 and v6 headers to assist in the packet interception process; see 328 [1] and [5]. 330 3. Design Overview 332 3.1. Overall Design Approach 334 The generic requirements identified in the NSIS framework [26] for 335 transport of signaling messages are essentially two-fold: 337 Routing: Determine how to reach the adjacent signaling node along 338 each direction of the data path (the GIST peer), and if necessary 339 explicitly establish addressing and identity information about 340 that peer; 342 Transport: Deliver the signaling information to that peer. 344 To meet the routing requirement, one possibility is for the node to 345 use local routing state information to determine the identity of the 346 GIST peer explicitly. GIST defines a three-way handshake which 347 probes the network to set up the necessary routing state between 348 adjacent peers, during which signaling applications can also exchange 349 data. Once the routing decision has been made, the node has to 350 select a mechanism for transport of the message to the peer. GIST 351 divides the transport problems into two categories, the easy and the 352 difficult. It handles the easy cases internally, and uses well- 353 understood transport protocols for the harder cases. Here, with 354 details discussed later, "easy" messages are those that are sized 355 well below the lowest maximum transmission unit (MTU) along a path, 356 are infrequent enough not to cause concerns about congestion and flow 357 control, and do not need security protection or guaranteed delivery. 359 In [26] all of these routing and transport requirements are assigned 360 to a single notional protocol, the NSIS Transport Layer Protocol 361 (NTLP). The strategy of splitting the transport problem leads to a 362 layered structure for the NTLP, of a specialised GIST messaging layer 363 running over standard transport and security protocols, as shown in 364 Figure 2. This also shows GIST offering its services to upper layers 365 at an abstract interface, the GIST API, further discussed in 366 Section 4.1. 368 ^^ +-------------+ 369 || | Signaling | 370 NSIS +------------|Application 2| 371 Signaling | Signaling +-------------+ 372 Application |Application 1| | 373 Level +-------------+ | 374 || | | 375 VV | | 376 ========|===================|===== <-- GIST API 377 | | 378 ^^ +------------------------------------------------+ 379 || |+-----------------------+ +--------------+ | 380 || || GIST | | GIST State | | 381 || || Encapsulation |<<<>>>| Maintenance | | 382 || |+-----------------------+ +--------------+ | 383 || | GIST: Messaging Layer | 384 || +------------------------------------------------+ 385 NSIS | | | | 386 Transport .................................. 387 Level . Transport Layer Security (TLS) . 388 (NTLP) .................................. 389 || | | | | 390 || +----+ +----+ +----+ +----+ 391 || |UDP | |TCP | |SCTP| |DCCP| ... other 392 || +----+ +----+ +----+ +----+ protocols 393 || | | | | 394 || ............................. 395 || . IP Layer Security . 396 || ............................. 397 VV | | | | 398 ========================|=======|=======|=======|=============== 399 | | | | 400 +----------------------------------------------+ 401 | IP | 402 +----------------------------------------------+ 404 Figure 2: Protocol Stacks for Signaling Transport 406 3.2. Modes and Messaging Associations 408 Internally, GIST has two modes of operation: 410 Datagram mode (D-mode): used for small, infrequent messages with 411 modest delay constraints and no security requirements; it must 412 also be used when no routing state exists. 414 Connection mode (C-mode): used for larger data objects or where fast 415 state setup in the face of packet loss is desirable, or where 416 channel security is required. 418 D-mode uses UDP, as this is the only encapsulation which does not 419 require per-message shared state to be maintained between the peers. 420 C-mode can in principle use any stream or message-oriented transport 421 protocol; this specification defines TCP as the initial choice. It 422 can in principle employ specific network layer security associations, 423 or an internal transport layer security association; this 424 specification defines TLS as the initial choice. When GIST messages 425 are carried in C-mode, they are treated just like any other traffic 426 by intermediate routers between the GIST peers. Indeed, it would be 427 impossible for intermediate routers to carry out any processing on 428 the messages without terminating the transport and security protocols 429 used. 431 It is possible to mix these two modes along a path. This allows, for 432 example, the use of D-mode at the edges of the network and C-mode in 433 the core of the network. Such combinations may make operation more 434 efficient for mobile endpoints, while allowing multiplexing of 435 signaling messages across shared security associations and transport 436 connections between core routers. 438 It must be understood that the routing and transport decisions made 439 by GIST are not independent. If the message transfer has 440 requirements that require C-mode, for example if the message is so 441 large that fragmentation is required, this can only be used between 442 explicitly identified nodes. In such cases, GIST carries out the 443 three-way handshake initially in D-mode to identify the peer and then 444 sets up the necessary connections if they do not already exist. It 445 must also be understood that the signaling application does not make 446 the D-mode/C-mode selection directly; rather, this decision is made 447 by GIST on the basis of the message characteristics and the transfer 448 attributes stated by the application. The distinction is not visible 449 at the GIST service interface. 451 In general, the state associated with C-mode messaging to a 452 particular peer (signaling destination address, protocol and port 453 numbers, internal protocol configuration and state information) is 454 referred to as a messaging association (MA). There may be any number 455 of MAs between two GIST peers although the usual case is zero or one. 456 They are set up and torn down by management actions within GIST 457 itself. 459 3.3. Message Routing Methods 461 The baseline message routing functionality in GIST is that signaling 462 messages follow a route defined by an existing flow in the network, 463 visiting a subset of the nodes through which it passes. This is the 464 appropriate behaviour for application scenarios where the purpose of 465 the signaling is to manipulate resources for that flow. However, 466 there are scenarios for which other behaviours are applicable. Two 467 examples are: 469 Predictive Routing: Here, the intent is to signal along a path that 470 the data flow may follow in the future. Possible cases are pre- 471 installation of state on the backup path that would be used in the 472 event of a link failure, and predictive installation of state on 473 the path that will be used after a mobile node handover. 475 NAT Address Reservations: This applies to the case where a node 476 behind a NAT wishes to reserve an address at which it can be 477 reached by a sender on the other side. This requires a message to 478 be sent outbound from what will be the flow receiver although no 479 reverse routing state for the flow yet exists. 481 Most of the details of GIST operation are independent of which 482 alternative is being used. Therefore, the GIST design encapsulates 483 the routing-dependent details as a message routing method (MRM), and 484 allows multiple MRMs to be defined. The default is the path-coupled 485 MRM, which corresponds to the baseline functionality described above; 486 a second MRM for the NAT Address Reservation case is also defined. 488 The content of a MRM definition is as follows, using the path-coupled 489 MRM as an example: 491 o The format of the information that describes the path that the 492 signaling should take, the Message Routing Information (MRI). For 493 the path-coupled MRM, this is just the Flow Identifier (see 494 Section 5.8.1.1) and some additional control information. 495 Specifically, the MRI always includes a flag to distinguish 496 between the two directions that signaling messages can take, 497 denoted 'upstream' and 'downstream'. 499 o A specification of the IP-level encapsulation of the messages 500 which probe the network to discover the adjacent peers. A 501 downstream encapsulation must be defined; an upstream 502 encapsulation is optional. For the path-coupled MRM, this 503 information is given in Section 5.8.1.2 and Section 5.8.1.3. 505 o A specification of what validation checks GIST should apply to the 506 probe messages, for example to protect against IP address spoofing 507 attacks. The checks may be dependent on the direction (upstream 508 or downstream) of the message. For the path-coupled MRM, the 509 downstream validity check is basically a form of ingress 510 filtering, also discussed in Section 5.8.1.2. 512 o The mechanism(s) available for route change detection, i.e. any 513 change in the neighbour relationships that the MRM discovers. The 514 default case for any MRM is soft-state refresh, but additional 515 supporting techniques may be possible; see Section 7.1.2. 517 In addition, it should be noted that NAT traversal may require 518 translation of fields in the MRI object carried in GIST messages (see 519 Section 7.2). The generic MRI format includes a flag that must be 520 given as part of the MRM definition, to indicate if some kind of 521 translation is necessary. Development of a new MRM therefore 522 includes updates to the GIST specification, and may include updates 523 to specifications of NAT behaviour. These updates may be done in 524 separate documents as is the case for the base GIST specification, as 525 described in Section 7.2.2. 527 The MRI is passed explicitly between signaling applications and GIST; 528 therefore, signaling application specifications must define which 529 MRMs they require. Signaling applications may use fields in the MRI 530 in their packet classifiers; if they use additional information for 531 packet classification, this would be carried at the NSLP level and so 532 would be invisible to GIST. Any node hosting a particular signaling 533 application MUST use a GIST implementation that supports the 534 corresponding MRMs. The GIST processing rules enforce that nodes 535 which do not host the signaling application are not forced to handle 536 messages for it at the GIST level, so it does not matter if they 537 support the MRM or not. 539 3.4. GIST Messages 541 GIST has six message types: Query, Response, Confirm, Data, Error, 542 and MA-Hello. Apart from the invocation of the messaging association 543 protocols, all GIST communication consists of these messages. In 544 addition, all signaling application data is carried as additional 545 payloads in these messages, alongside the GIST information. 547 The first three messages implement the handshake that GIST uses to 548 set up routing state and messaging associations. The handshake is 549 initiated from the Querying node towards the Responding node. The 550 first message is the Query, which is encapsulated in a special way 551 depending on the message routing method, in order to probe the 552 network infrastructure so that the correct peer will intercept it and 553 become the Responding node. A Query always triggers a Response in 554 the reverse direction as the second message of the handshake. As 555 part of the defence against denial of service attacks, the Responding 556 node can delay state installation until a return routability check, 557 and require the Querying node to complete the handshake with the 558 Confirm. All of these three messages can optionally carry signaling 559 application data. 561 The Data message is used purely to encapsulate signaling application 562 data. Usually it is sent using pre-established routing state. 563 However, if there are no security or transport requirements and no 564 need for persistent reverse routing state, it can also be sent in the 565 same way as the Query. Finally, Error messages are used to indicate 566 error conditions at the GIST level, and the MA-Hello message can be 567 used as a keepalive for the messaging association protocols. 569 3.5. Signaling Sessions 571 GIST allows signaling applications to associate each of their 572 messages with a signaling session. Informally, given an application 573 layer exchange of information for which some network control state 574 information is to be manipulated or monitored, the corresponding 575 signaling messages should be associated with the same session. 576 Signaling applications provide the session identifier (SID) whenever 577 they wish to send a message, and GIST reports the SID when a message 578 is received. 580 Most GIST processing and state information is related to the flow 581 (defined by the MRI, see above) and signaling application (given by 582 the NSLP identifier, see below). There are several possible 583 relationships between flows and sessions, for example: 585 o The simplest case is that all messages for the same flow have the 586 same SID. 588 o Messages for more than one flow may use the same SID, for example 589 because one flow is replacing another in a mobility or multihoming 590 scenario. 592 o A single flow may have messages for different SIDs, for example 593 from independently operating signaling applications. 595 Because of this range of options, GIST does not perform any 596 validation on how signaling applications map between flows and 597 sessions, nor does it perform any validation on the properties of the 598 SID itself. In particular, when a new SID is needed, logically it 599 should be generated by the signaling application. NSIS 600 implementations could provide common functionality to generate SIDs 601 for use by any signaling application, but this is not part of GIST. 602 GIST only defines the syntax of the SID as an opaque 128-bit 603 identifier. 605 The SID assignment has the following impact on GIST processing: 607 o Messages with the same SID that are to be delivered reliably 608 between the same GIST peers are delivered in order. 610 o All other messages are handled independently. 612 o GIST identifies routing state (upstream and downstream peer) by 613 the triplet (MRI, NSLP, SID). 615 Strictly, the routing state should not depend on the SID. However, 616 if the routing state is keyed only by (MRI, NSLP), there is a trivial 617 denial of service attack (see Section 8.3) where a malicious off-path 618 node asserts that it is the peer for a particular flow. Instead, the 619 routing state is also segregated between different SIDs, which means 620 that the attacking node can only disrupt a signaling session if it 621 can guess the corresponding SID. A consequence of this design is 622 that signaling applications SHOULD choose SIDs so that they are 623 cryptographically random, and SHOULD NOT use several SIDs for the 624 same flow, to avoid additional load from routing state maintenance. 625 Guidance on secure randomness generation can be found in [28]. 627 3.6. Signaling Applications and NSLPIDs 629 The functionality for signaling applications is supported by NSIS 630 signaling layer protocols (NSLPs). Each NSLP is identified by a 16 631 bit NSLP identifier (NSLPID), assigned by IANA (Section 9). A single 632 signaling application, such as resource reservation, may define a 633 family of NSLPs to implement its functionality, for example to carry 634 out signaling operations at different levels in a hierarchy (cf. 635 [19]). However, the interactions between the different NSLPs (for 636 example, to relate aggregation levels or aggregation region 637 boundaries in the resource management case) are handled at the 638 signaling application level; the NSLPID is the only information 639 visible to GIST about the signaling application being used. 641 3.7. Example of Operation 643 This section presents an example of GIST usage in a relatively simple 644 (in particular, NAT-free) signaling scenario, to illustrate its main 645 features. 647 Consider the case of an RSVP-like signaling application which 648 allocates resources for a single unicast flow. We will consider how 649 GIST transfers messages between two adjacent peers along the path, 650 GN1 and GN2 (see Figure 1 in Section 2). In this example, the end- 651 to-end exchange is initiated by the signaling application instance in 652 the sender; we take up the story at the point where the first message 653 is being processed above the GIST layer by the signaling application 654 in GN1. 656 1. The signaling application in GN1 determines that this message is 657 a simple description of resources that would be appropriate for 658 the flow. It determines that it has no special security or 659 transport requirements for the message, but simply that it should 660 be transferred to the next downstream signaling application peer 661 on the path that the flow will take. 663 2. The message payload is passed to the GIST layer in GN1, along 664 with a definition of the flow and description of the message 665 transfer attributes {unsecured, unreliable}. GIST determines 666 that this particular message does not require fragmentation and 667 that it has no knowledge of the next peer for this flow and 668 signaling application; however, it also determines that this 669 application is likely to require secured upstream and downstream 670 transport of large messages in the future. This determination is 671 a function of node-local policy interactions between GIST and the 672 signaling application. 674 3. GN1 therefore constructs a GIST Query carrying the NSLP payload, 675 and additional payloads at the GIST level to be used to initiate 676 a messaging association. The Query is encapsulated in a UDP 677 datagram and injected into the network, addressed towards the 678 flow destination and with an IP Router Alert Option (RAO) 679 included. 681 4. The Query passes through the network towards the flow receiver, 682 and is seen by each router in turn. GIST-unaware routers will 683 not recognise the RAO value and will forward the message 684 unchanged; GIST-aware routers which do not support the NSLP in 685 question will also forward the message basically unchanged, 686 although they may need to process more of the message to decide 687 this. 689 5. The message is intercepted at GN2. The GIST layer identifies the 690 message as relevant to a local signaling application, and passes 691 the NSLP payload and flow description upwards to it. The 692 signaling application in GN2 indicates to GIST that it will peer 693 with GN1 and so GIST should proceed to set up any routing state. 694 In addition, the signaling application continues to process the 695 message as in GN1 (compare step 1), forwarding the message 696 downstream, and this will eventually result in the message 697 reaching the flow receiver. 699 6. In parallel, the GIST instance in GN2 now knows that it should 700 maintain routing state and a messaging association for future 701 signaling with GN1. This is recognised because the message is a 702 Query, and because the local signaling application has indicated 703 that it will peer with GN1. There are two possible cases for 704 sending back the necessary GIST Response: 706 Association Exists: GN1 and GN2 already have an appropriate MA. 707 GN2 simply records the identity of GN1 as its upstream peer 708 for that flow and NSLP, and sends a Response back to GN1 over 709 the MA identifying itself as the peer for this flow. 711 No Association: No MA exists. GN2 sends the Response in D-mode 712 directly to GN1, identifying itself and agreeing to the 713 association setup. The protocol exchanges needed to complete 714 this will proceed in parallel with the following stages. 716 7. Eventually, another NSLP message works its way upstream from the 717 receiver to GN2. This message contains a description of the 718 actual resources requested, along with authorisation and other 719 security information. The signaling application in GN2 passes 720 this payload to the GIST level, along with the flow definition 721 and transfer attributes {secured, reliable}. 723 8. The GIST layer in GN2 identifies the upstream peer for this flow 724 and NSLP as GN1, and determines that it has an MA with the 725 appropriate properties. The message is queued on the MA for 726 transmission; this may incur some delay if the procedures begun 727 in step 6.B have not yet completed. 729 Further messages can be passed in each direction in the same way. 730 The GIST layer in each node can in parallel carry out maintenance 731 operations such as route change detection (see Section 7.1). 733 It should be understood that several of these details of GIST 734 operations can be varied, either by local policy or according to 735 signaling application requirements. The authoritative details are 736 contained in the remainder of this document. 738 4. GIST Processing Overview 740 This section defines the basic structure and operation of GIST. 741 Section 4.1 describes the way in which GIST interacts with local 742 signaling applications in the form of an abstract service interface. 743 Section 4.2 describes the per-flow and per-peer state that GIST 744 maintains for the purpose of transferring messages. Section 4.3 745 describes how messages are processed in the case where any necessary 746 messaging associations and routing state already exist; this includes 747 the simple scenario of pure D-mode operation, where no messaging 748 associations are necessary in the first place. Finally, Section 4.4 749 describes how routing state and messaging associations are created 750 and managed. 752 4.1. GIST Service Interface 754 This section defines the service interface that GIST presents to 755 signaling applications in terms of abstract properties of the message 756 transfer. Note that the same service interface is presented at every 757 GIST node; however, applications may invoke it differently at 758 different nodes, depending for example on local policy. In addition, 759 the service interface is defined independently of any specific 760 transport protocol, or even the distinction between D-mode and 761 C-mode. The initial version of this specification defines how to 762 support the service interface using a C-mode based on TCP; if 763 additional protocol support is added, this will support the same 764 interface and so the change will be invisible to applications, except 765 as a possible performance improvement. A more detailed description 766 of this service interface is given in Appendix B. 768 4.1.1. Message Handling 770 Fundamentally, GIST provides a simple message-by-message transfer 771 service for use by signaling applications: individual messages are 772 sent, and individual messages are received. At the service 773 interface, the NSLP payload, which is opaque to GIST, is accompanied 774 by control information expressing the application's requirements 775 about how the message should be routed, and the application also 776 provides the session identifier (see Section 3.5). Additional 777 message transfer attributes control the specific transport and 778 security properties that the signaling application desires. 780 The distinction between GIST D- and C-mode is not visible at the 781 service interface. In addition, the functionality to handle 782 fragmentation and reassembly, bundling together of small messages for 783 efficiency, and congestion control are not directly visible at the 784 service interface; GIST will take whatever action is necessary based 785 on the properties of the messages and local node state. 787 4.1.2. Message Transfer Attributes 789 Message transfer attributes are used to define certain performance 790 and security related aspects of message processing. The attributes 791 available are as follows: 793 Reliability: This attribute may be 'true' or 'false'. When 'true', 794 messages MUST be delivered to the signaling application in the 795 peer exactly once or not at all; if there is a chance that the 796 message was not delivered, an error MUST be indicated to the local 797 signaling application identifying the routing information for the 798 message in question. GIST implements reliability by using an 799 appropriate transport protocol within a messaging association, so 800 mechanisms for the detection of message loss depend on the 801 protocol in question; for the current specification, the case of 802 TCP is considered in Section 5.7.2. Messages with the same SID to 803 the same peer MUST be delivered in order. When 'false', a message 804 may be delivered, once, several times or not at all, with no error 805 indications in any case. 807 Security: This attribute defines the security properties that the 808 signaling application requires for the message, including the type 809 of protection required, and what authenticated identities should 810 be used for the signaling source and destination. This 811 information maps onto the corresponding properties of the security 812 associations established between the peers in C-mode. It can be 813 specified explicitly by the signaling application, or reported by 814 GIST to the signaling application. The latter can take place 815 either on receiving a message, or just before sending a message 816 but after configuring or selecting the messaging association to be 817 used for it. This attribute can also be used to convey 818 information about any address validation carried out by GIST, such 819 as whether a return routability check has been carried out. 820 Further details are discussed in Appendix B. 822 Local Processing: An NSLP may provide hints to GIST to enable more 823 efficient or appropriate processing. For example, the NSLP may 824 select a priority from a range of locally defined values to 825 influence the sequence in which messages leave a node. Any 826 priority mechanism MUST respect the ordering requirements for 827 reliable messages within a session, and priority values are not 828 carried in the protocol or available at the signaling peer or 829 intermediate nodes. An NSLP may also indicate that reverse path 830 routing state will not be needed for this flow, to inhibit the 831 node requesting its downstream peer to create it. 833 4.2. GIST State 835 4.2.1. Message Routing State 837 For each flow, the GIST layer can maintain message routing state to 838 manage the processing of outgoing messages. This state is 839 conceptually organised into a table with the following structure. 840 The primary key (index) for the table is the combination of the 841 information about how the message is to be routed, the session being 842 signaled for, and the signaling application itself: 844 Message Routing Information (MRI): This defines the method to be used 845 to route the message, the direction in which to send the message, 846 and any associated addressing information; see Section 3.3. 848 Session Identification (SID): The signaling session with which this 849 message should be associated; see Section 3.5. 851 NSLP Identification (NSLPID): This is an IANA-assigned identifier 852 associated with the NSLP which is generating messages for this 853 flow. The inclusion of this identifier allows the routing state 854 to be different for different NSLPs, for example because of 855 different adjacencies. 857 The information associated with a given key consists of the routing 858 state to reach the peer in the direction given by the MRI. For any 859 flow, there will usually be two entries, one each for the upstream 860 and downstream MRI. The routing state includes information about the 861 peer identity (see Section 4.4.2), and a UDP port number for D-mode, 862 or a reference to one or more MAs for C-mode. All of this 863 information is learned from prior GIST exchanges. 865 It is also possible for the state information for either direction to 866 be empty. There are several possible cases: 868 o The signaling application has indicated that no messages will 869 actually be sent in that direction. 871 o The node is a flow endpoint, so there can be no signaling peer in 872 one or other direction. 874 o The node is the endpoint of the signaling path, for example 875 because it is acting as a proxy, or because it has determined that 876 there are no further signaling nodes in that direction. 878 o The node is using other techniques to route the message. For 879 example, it can encapsulate it the same way as a Query and rely on 880 the peer to intercept it. 882 Each entry in the routing state table has an associated validity 883 timer for how long it can be considered accurate; when this timer 884 expires, the entry MUST be purged if it has not been refreshed. 885 Installation and maintenance of routing state is described in more 886 detail in Section 4.4. 888 Note also that the routing state is described as a table of per-flow 889 entries, but that there is no implied constraint on how the 890 information is stored. However, in general, and especially if GIST 891 peers are several IP hops away, there is no way to identify the 892 correct downstream peer for a flow and signaling application from the 893 local forwarding table using prefix matching, and the same applies 894 always to upstream peer state because of the possibility of 895 asymmetric routing: prefix aggregation is not possible, and per-flow 896 state has to be stored, just as for RSVP [12]. 898 4.2.2. Peer-Peer Messaging Association State 900 The per-flow message routing state is not the only state stored by 901 GIST. There is also the state required to manage the MAs. Since 902 these are not per-flow, they are stored separately from the routing 903 state, including the following per-MA information: 905 o a queue of messages pending transmission while an MA is being 906 established; 908 o a timer for how long since the peer re-stated its desire to keep 909 the MA open (see Section 4.4.3). 911 In addition, per-MA state is held in the messaging association 912 protocols themselves. However, the details of this state are not 913 directly visible to GIST, and they do not affect the rest of the 914 protocol description. 916 4.3. Basic GIST Message Processing 918 This section describes how signaling application messages are 919 processed in the case where any necessary messaging associations and 920 routing state are already in place. The description is divided into 921 several parts. Firstly, message reception, local processing and 922 message transmission are described for the case where the node hosts 923 the NSLPID identified in the message. Secondly, the case where the 924 message is handled directly in the IP or GIST layer (because there is 925 no matching signaling application on the node) is given. An overview 926 is given in Figure 3. 928 +---------------------------------------------------------+ 929 | >> Signaling Application Processing >> | 930 | | 931 +--------^---------------------------------------V--------+ 932 ^ V 933 ^ NSLP Payloads V 934 ^ V 935 +--------^---------------------------------------V--------+ 936 | >> GIST >> | 937 | ^ ^ ^ Processing V V V | 938 +--x-----------N--Q---------------------Q--N-----------x--+ 939 x N Q Q N x 940 x N Q>>>>>>>>>>>>>>>>>>>>>Q N x 941 x N Q Bypass at Q N x 942 +--x-----+ +--N--Q--+ GIST level +--Q--N--+ +-----x--+ 943 | C-mode | | D-mode | | D-mode | | C-mode | 944 |Handling| |Handling| |Handling| |Handling| 945 +--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+ 946 x N Q Q N x 947 x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x 948 x N Q Bypass at Q N x 949 +--x--N--+ +-----Q--+ IP (router +--Q-----+ +--N--x--+ 950 |IP Host | | RAO | alert) level | RAO | |IP Host | 951 |Handling| |Handling| |Handling| |Handling| 952 +--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+ 953 x N Q Q N x 954 +--x--N-----------Q--+ +--Q-----------N--x--+ 955 | IP Layer | | IP Layer | 956 | (Receive Side) | | (Transmit Side) | 957 +--x--N-----------Q--+ +--Q-----------N--x--+ 958 x N Q Q N x 959 x N Q Q N x 961 NNNNNNNNNNNNNN = Normal D-mode messages 962 QQQQQQQQQQQQQQ = D-mode messages which are Q-mode encapsulated 963 xxxxxxxxxxxxxx = C-mode messages 964 RAO = Router Alert Option 966 Figure 3: Message Paths through a GIST Node 968 4.3.1. Message Reception 970 Messages can be received in C-mode or D-mode. In the D-mode case, 971 there are two possible message encapsulations, described below. 973 Reception in C-mode is simple: incoming packets undergo the security 974 and transport treatment associated with the MA, and the MA provides 975 complete messages to the GIST layer for further processing. 977 Reception in D-mode depends on the message type. 979 Normal encapsulation: Normal messages arrive UDP-encapsulated and 980 addressed directly to the receiving signaling node, at an address 981 and port learned previously. Each datagram contains a single 982 message which is passed to the GIST layer for further processing, 983 just as in the C-mode case. 985 Q-mode encapsulation: Where GIST is sending messages to be 986 intercepted by the appropriate peer rather than directly addressed 987 to it (in particular, Query messages), these are UDP encapsulated 988 with an IP router alert option. Each signaling node will 989 therefore see all such messages. Several RAO values may be used 990 by NSIS; the assignment rationale is discussed in [11]. The case 991 where the NSLPID does not match a local signaling application at 992 all is considered below in Section 4.3.4; otherwise, the message 993 is again passed up to the GIST layer for further processing. 995 4.3.2. Local Processing and Validation 997 Once a message has been received, it is processed locally within the 998 GIST layer. The GIST hop count, which every message contains to 999 prevent looping, MUST be checked and decremented immediately the 1000 message has been received. Further processing depends on the message 1001 type and payloads carried; most of the GIST payloads are associated 1002 with state maintenance and details are covered in Section 4.4. 1004 In the case of a Query, there is an interaction with signaling 1005 application policy to determine which of two courses to follow: 1007 1. The receiving signaling application wishes to become a signaling 1008 peer with the Querying node. GIST MUST continue with the 1009 handshake process to set up message routing state, as described 1010 in Section 4.4.1. The application MAY provide an NSLP payload 1011 for the same NSLPID, which GIST will transfer in the Response. 1013 2. The signaling application does not wish to set up state with the 1014 Querying node and become its peer. GIST MUST propagate the 1015 Query, similar to the case described in Section 4.3.4. No 1016 message is sent back to the Querying node. The application MAY 1017 provide an updated NSLP payload for the same NSLPID, which will 1018 be used in the Query forwarded by GIST. 1020 This interaction with the signaling application, including the 1021 generation or update of an NSLP payload, SHOULD take place 1022 synchronously as part of the Query processing. In terms of the GIST 1023 service interface, this can be implemented by providing appropriate 1024 return values for the primitive that is triggered when such a message 1025 is received; see Appendix B.2 for further discussion. 1027 For all other message types, the GIST payloads are processed as 1028 described in Section 4.4. The remainder of the GIST message consists 1029 of an NSLP payload, which is delivered locally to the signaling 1030 application identified by the NSLPID. The format of the payload is 1031 not constrained by GIST, and the content is not interpreted. 1032 Delivery is subject to the following validation checks: 1034 o if the message was explicitly routed (see Section 7.1.4) or is a 1035 Data message delivered without routing state (see Section 5.3.2), 1036 the payload is delivered but flagged to the receiving NSLP to 1037 indicate that routing state was not validated; 1039 o else, if there is no routing state for the MRI/SID/NSLPID the 1040 message MUST be rejected with a "No Routing State" error message 1041 (Appendix A.4.4.5); 1043 o else, if the message arrived on an association which is not 1044 associated with the MRI/NSLPID/SID combination given in the 1045 message, the message MUST be rejected with an "Incorrectly 1046 Delivered Message" error message (Appendix A.4.4.4); 1048 o else, the payload is delivered as normal. 1050 4.3.3. Message Transmission 1052 Signaling applications can generate their messages for transmission, 1053 either asynchronously, or in response to a normal input message, and 1054 GIST can also generate messages autonomously. When a message is 1055 available for transmission, GIST uses internal policy and the stored 1056 routing state to determine how to handle it. The following 1057 processing applies equally to locally generated messages and messages 1058 forwarded from within the GIST or signaling application levels. 1059 However, see Section 5.6 for special rules applying to the 1060 transmission of error messages by GIST. 1062 The main decision is whether the message must be sent in C-mode or 1063 D-mode. Reasons for using the former are: 1065 o signaling application requirements: for example, it has requested 1066 channel secured delivery, or reliable delivery; 1068 o protocol specification: a message that requires fragmentation MUST 1069 be sent over a messaging association; 1071 o local policy: for example, a node MAY send messages over a 1072 messaging association to benefit from adaptive congestion control. 1074 In principle, as well as determining that some messaging association 1075 must be used, GIST MAY select between a set of alternatives, e.g. for 1076 load sharing or because different messaging associations provide 1077 different transport or security attributes. 1079 If the use of a messaging association is selected, the message is 1080 queued on the association found from the routing state table, and 1081 further output processing is carried out according to the details of 1082 the protocol stacks used. If no appropriate association exists, the 1083 message is queued while one is created (see Section 4.4.1). If no 1084 association can be created, this is an error condition, and should be 1085 indicated back to the local signaling application. 1087 If a messaging association is not required, the message is sent in 1088 D-mode. The processing in this case depends on the message type and 1089 whether routing state exists or not. 1091 o If the message is not a Query, and routing state exists, it is UDP 1092 encapsulated and sent directly to the address from the routing 1093 state table. 1095 o If the message is a Query, then it is UDP encapsulated with IP 1096 address and router alert option determined from the MRI and 1097 NSLPID; further details depend on the message routing method. 1099 o If no routing state exists, GIST can attempt to use the same 1100 Q-mode encapsulation as in the Query case. If this is not 1101 possible, e.g. because the encapsulation for the MRM is only 1102 defined for one message direction, then this is an error condition 1103 which is reported back to the local signaling application. 1105 4.3.4. Nodes not Hosting the NSLP 1107 A node may receive messages where it has no signaling application 1108 corresponding to the message NSLPID. There are several possible 1109 cases depending mainly on the encapsulation: 1111 1. A Q-mode encapsulated message contains an RAO value which is 1112 relevant to NSIS but not to the specific node, but the IP layer 1113 is unable to recognise whether it needs to be passed to GIST for 1114 further processing or whether the packet should be forwarded just 1115 like a normal IP datagram. 1117 2. A Q-mode encapsulated message contains an RAO value which is 1118 relevant to the node, but the specific signaling application for 1119 the NSLPID in the message is not processed there. 1121 3. A directly addressed message (in D-mode or C-mode) is delivered 1122 to a node for which there is no corresponding signaling 1123 application. With the current specification, this should never 1124 happen. While future versions might find a use for such a 1125 feature, currently this MUST cause an "Unknown NSLPID" error 1126 message, Appendix A.4.4.6. 1128 4. A Q-mode encapsulated message arrives at the end-system which 1129 does not handle the signaling application. This is possible in 1130 normal operation, and MUST be indicated to the sender with an 1131 "Endpoint Found" informational message (Appendix A.4.4.7). The 1132 end-system includes the MRI and SID from the original message in 1133 the error message without interpreting them. 1135 5. The node is GIST-aware NAT. See Section 7.2. 1137 In cases (1) and (2), the role of GIST is to forward the message 1138 essentially unchanged, and it will not become a peer to the node 1139 sending the message. Forwarding with modified NSLP payloads is 1140 covered above in Section 4.3.2. However, a GIST implementation must 1141 ensure that the IP-layer TTL field and GIST hop count are managed 1142 correctly to prevent message looping, and this should be done 1143 consistently independently of whether the processing takes place on 1144 the fast path or in GIST-specific code. The rules are that in cases 1145 (1) and (2), the IP-layer TTL MUST be decremented just as if the 1146 message was a normal IP forwarded packet; in case (2) the GIST hop 1147 count MUST be decremented as in the case of normal input processing, 1148 which indeed applies to cases (3) and (4). 1150 A GIST node processing Q-mode encapsulated messages in this way 1151 SHOULD make the routing decision based on the full contents of the 1152 MRI and not only the IP destination address. It MAY also apply a 1153 restricted set of sanity checks and under certain conditions return 1154 an error message rather than forward the message. These conditions 1155 are: 1157 1. The message is so large that it would be fragmented on downstream 1158 links, for example because the downstream MTU is very small. The 1159 error "Message Too Large" (Appendix A.4.4.8) SHOULD be returned 1160 to the sender, which SHOULD begin messaging association setup. 1162 2. The GIST hop count has reached zero. The error "Hop Limit 1163 Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender, 1164 which MAY retry with a larger initial hop count if it is clear 1165 that a loop has not been formed. 1167 3. The MRI represents a flow definition which is too general to be 1168 forwarded along a unique path (e.g. the destination address 1169 prefix is too short). The error "MRI Validation Failure" 1170 (Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be 1171 returned to the sender, which MAY retry with restricted MRIs, 1172 possibly starting additional signaling sessions to do so. If the 1173 GIST node does not understand the MRM in question it MUST NOT 1174 apply this check, instead forwarding the message transparently. 1176 In the first two cases, only the common header of the GIST message is 1177 examined; in the third case, the MRI is also examined. The rest of 1178 the message MUST never be inspected or modified. 1180 Note that the GIST hop count is only intended to prevent message 1181 looping at the GIST level, and by default NSLPs must take their own 1182 measures to prevent looping at the application level. However, the 1183 GIST API (Appendix B) provides the incoming hop count to the NSLPs, 1184 which can preserve it on outgoing messages as they are forwarded 1185 further along the path. This provides a lightweight loop-prevention 1186 mechanism for NSLPs which do not define anything more sophisticated. 1188 4.4. Routing State and Messaging Association Maintenance 1190 The main responsibility of GIST is to manage the routing state and 1191 messaging associations which are used in the message processing 1192 described above. Routing state is installed and maintained by 1193 specific GIST messages. Messaging associations depend on the 1194 existence of routing state, but are actually set up by the normal 1195 procedures of the transport and security protocols that comprise 1196 them. Timers control routing state and messaging association refresh 1197 and expiration. 1199 There are two different cases for state installation and refresh: 1201 1. Where routing state is being discovered or a new association is 1202 to be established; and 1204 2. Where an existing association can be re-used, including the case 1205 where routing state for the flow is being refreshed. 1207 These cases are now considered in turn, followed by the case of 1208 background general management procedures. 1210 4.4.1. State Setup 1212 The complete sequence of possible messages for GIST state setup 1213 between adjacent peers is shown in Figure 4 and described in detail 1214 in the following text. The figure informally summarises the contents 1215 of each message, including optional elements in []. An example is 1216 given in Appendix C. 1218 +----------+ +----------+ 1219 | Querying | |Responding| 1220 | Node | | Node | 1221 +----------+ +----------+ 1222 Query 1223 ----------------------> ............. 1224 Router Alert Option . Routing . 1225 MRI/SID/NSLPID . state . 1226 Q-Node Network Layer Info . installed . 1227 Query Cookie . at . 1228 [Q-Node Stack-Proposal . R-node(1) . 1229 Q-Node Stack-Config-Data] ............. 1230 [NSLP Payload] 1232 ...................................... 1233 . The responder can use an existing . 1234 . messaging association if available . 1235 . from here onwards to short-circuit . 1236 . messaging association setup . 1237 ...................................... 1239 Response 1240 ............. <---------------------- 1241 . Routing . MRI/SID/NSLPID 1242 . state . R-Node Network Layer Info (D-mode only) 1243 . installed . Query cookie 1244 . at . [Responder Cookie 1245 . Q-Node . [R-Node Stack-Proposal 1246 ............. R-Node Stack-Config-Data]] 1247 [NSLP Payload] 1249 .................................... 1250 . If a messaging association needs . 1251 . to be created, it is set up here . 1252 . and the Confirm uses it . 1253 .................................... 1255 Confirm 1256 ----------------------> 1257 MRI/SID/NSLPID ............. 1258 Q-Node Network Layer Info . Routing . 1259 [Responder Cookie . state . 1260 [R-Node Stack-Proposal . installed . 1261 [Q-Node Stack-Config-Data]]] . at . 1262 [NSLP Payload] . R-node(2) . 1263 ............. 1265 Figure 4: Message Sequence at State Setup 1266 The initial message in any routing state maintenance operation is a 1267 Query, sent from the querying node and intercepted at the responding 1268 node. This message has addressing and other identifiers appropriate 1269 for the flow and signaling application that state maintenance is 1270 being done for, addressing information about the node itself, and it 1271 MAY contain an NSLP payload. It also includes a Query Cookie, and 1272 optionally capability information about messaging association 1273 protocol stacks. The role of the cookies in this and subsequent 1274 messages is to protect against certain denial of service attacks and 1275 to correlate the various events in the message sequence (see 1276 Section 8.5 for further details). 1278 Provided that the signaling application has indicated that message 1279 routing state should be set up (see Section 4.3.2), reception of a 1280 Query MUST elicit a Response. This is a normally encapsulated D-mode 1281 message with additional payloads. It contains network layer 1282 information about the responding node, echoes the Query Cookie, and 1283 MAY contain an NSLP payload, possibly a response to the NSLP payload 1284 in the initial message. In case a messaging association was 1285 requested, it MUST also contain a Responder Cookie and its own 1286 capability information about messaging association protocol stacks. 1287 Even if a messaging association is not requested, the Response MAY 1288 still include a Responder Cookie if the node's routing state setup 1289 policy requires it (see below). 1291 Setup of a new messaging association begins when peer addressing 1292 information is available and a new messaging association is actually 1293 needed. Any setup MUST take place immediately after the specific 1294 Query/Response exchange, because the addressing information used may 1295 have a limited lifetime, either because it depends on limited 1296 lifetime NAT bindings or because it refers to agile destination ports 1297 for the transport protocols. The Stack-Proposal and Stack- 1298 Configuration-Data objects carried in the exchange carry capability 1299 information about what messaging association protocols can be used, 1300 and the processing of these objects is described in more detail in 1301 Section 5.7. With the protocol options currently defined, setup of 1302 the messaging association always starts from the Querying node, 1303 although more flexible configurations are possible within the overall 1304 GIST design. In any case, once set up, the association itself can be 1305 used equally in both directions. 1307 Finally, after any necessary messaging association setup has 1308 completed, a Confirm MUST be sent if the Response requested it. If a 1309 messaging association is being used, the Confirm MUST be sent over it 1310 before any other messages for the same flow, and it echoes the 1311 Responder Cookie and Stack-Proposal from the Response. The former is 1312 used to allow the receiver to validate the contents of the message 1313 (see Section 8.5), and the latter is to prevent certain bidding-down 1314 attacks on messaging association security (see Section 8.6). The 1315 Confirm MAY also contain an abbreviated form of the original Stack- 1316 Configuration-Data to finalise details of the messaging association 1317 configuration. The association can be used in the upstream direction 1318 for the MRI and NSLPID carried in the Confirm, after the Confirm has 1319 been received. 1321 The querying node MUST install the responder address as routing state 1322 information after verifying the Query Cookie in the Response. The 1323 responding node MAY install the querying address as peer state 1324 information at two points in time: 1326 1. after the receipt of the initial Query, or 1328 2. after a Confirm containing the Responder Cookie. 1330 The precise constraints on when state information is installed are a 1331 matter of security policy considerations on prevention of denial-of- 1332 service attacks and state poisoning attacks, which are discussed 1333 further in Section 8. Because the responding node MAY choose to 1334 delay state installation as in case (2), the Confirm must contain 1335 sufficient information to allow it to be processed in the same way as 1336 the original Query. This places some special requirements on NAT 1337 traversal and cookie functionality, which are discussed in 1338 Section 7.2 and Section 8 respectively. 1340 4.4.2. Messaging Association Re-use 1342 It is a design goal of GIST that, as far as possible, messaging 1343 associations should be re-used for multiple flows and sessions, 1344 rather than setting up a new MA for each. This is to ensure that the 1345 MA cost scales only with the number of peers, and to avoid the 1346 latency of new MA setup where possible. 1348 However, re-use requires the identification of an existing MA which 1349 matches the same routing state and desired properties that would be 1350 the result of a full handshake in D-mode, and this identification 1351 must be done as reliably and securely as continuing with the full 1352 procedure. Note that this requirement is complicated by the fact 1353 that NATs may remap the node addresses in D-mode messages, and also 1354 interacts with the fact that some nodes may peer over multiple 1355 interfaces (and thus with different addresses). 1357 MA re-use is controlled by the Network-Layer-Information (NLI) 1358 object, which is carried in Query/Confirm and optionally Response 1359 messages. The NLI object includes: 1361 Peer-Identity: For a given node, this is an interface independent 1362 value with opaque syntax. It MUST be chosen so as to have a high 1363 probability of uniqueness between peers, and SHOULD be stable at 1364 least until the next node restart. Note that there is no 1365 cryptographic protection of this identity; attempting to provide 1366 this would essentially duplicate the functionality in the 1367 messaging association security protocols. 1369 Interface-Address: This is an IP address through which the signaling 1370 node can be reached. There may be several choices available for 1371 the Interface-Address, and further discussion of this is contained 1372 in Section 5.2.2. 1374 By default, a messaging association is associated with the NLI object 1375 that was provided by the peer in the Query/Response/Confirm at the 1376 time the association was set up. There may be more than one 1377 association for a given NLI object, for example with different 1378 security or transport properties. 1380 MA re-use is controlled by matching the NLI provided in a GIST 1381 message with those associated with existing MAs. This can be done on 1382 receiving either a Query or Response, although the former is more 1383 likely: 1385 o If there is a perfect match to the NLI of an existing association, 1386 that association SHOULD be re-used, provided it has the 1387 appropriate properties in other respects. This is indicated by 1388 sending the remaining messages in the handshake over that 1389 association. This will only fail, that is, lead to re-use of an 1390 association to the wrong node, if signaling nodes have colliding 1391 Peer-Identities and one is reachable at the same Interface-Address 1392 as another. This could be done by an on-path attacker. 1394 o In all other cases, the full handshake MUST be executed in D-mode 1395 as usual. There are in fact four possibilities: 1397 1. Nothing matches: this is clearly a new peer. 1399 2. Only the Peer-Identity matches: this may be either a new 1400 interface on an existing peer, or a changed address mapping 1401 behind a NAT, or an attacker attempting to hijack the Peer- 1402 Identity. These should be rare events, so the expense of a 1403 new association setup is acceptable. 1405 3. Only the Interface-Address matches: this is probably a new 1406 peer behind the same NAT as an existing one. A new 1407 association setup is required. 1409 4. The full NLI object matches: this is a degenerate case, where 1410 one node recognises an existing peer, but wishes to allow the 1411 option to set up a new association in any case, for example to 1412 create an association with different properties. 1414 4.4.3. State Maintenance Procedures 1416 Refresh and expiration of all types of GIST state is controlled by 1417 timers. 1419 Each item of routing state expires after a lifetime which is 1420 negotiated during the Query/Response/Confirm handshake. The Network 1421 Layer Info (NLI) object in the Query contains a proposal for the 1422 lifetime value, and the NLI in the Response contains the value the 1423 Responding node requires. A default timer value of 30 seconds is 1424 RECOMMENDED. Nodes which can exploit alternative, more powerful, 1425 route change detection methods such as those described in 1426 Section 7.1.2 MAY choose to use much longer times. Nodes MAY use 1427 shorter times to provide more rapid change detection, but MUST take 1428 into account the fact that the Query messages generated may stress 1429 the rate limits applied to D-mode traffic (Section 5.3.3). 1431 The Querying node MUST generate a Query before this timer expires, if 1432 it believes that the signaling session is still active; otherwise, 1433 the Responding node MAY delete the state. Receipt of the message at 1434 the Responding node will refresh peer addressing state for one 1435 direction, and receipt of a Response at the querying node will 1436 refresh it for the other. There is no mechanism at the GIST level 1437 for explicit teardown of routing state. However, GIST MUST NOT 1438 refresh routing state if a signaling session is known to be inactive, 1439 either because upstream state has expired, or because the signaling 1440 application has indicated via the GIST API (Appendix B.5) that the 1441 state is no longer required, because this would prevent correct state 1442 repair in the case of network rerouting. 1444 Unneeded MAs are torn down by GIST, using the teardown mechanisms of 1445 the underlying transport or security protocols if available, for 1446 example by simply closing a TCP connection. The teardown can be 1447 initiated by either end. Whether an MA is needed is a combination of 1448 two factors: 1450 o local policy, which could take into account the cost of keeping 1451 the messaging association open, the level of past activity on the 1452 association, and the likelihood of future activity, e.g. if there 1453 is routing state still in place which might generate messages to 1454 use it. 1456 o whether the peer still wants the MA in place. During MA setup, 1457 each node indicates its own MA-Hold-Time as part of the Stack- 1458 Configuration-Data. A node MUST NOT tear down the MA if it has 1459 received traffic from its peer over that period. A peer which has 1460 generated no traffic but still wants the MA retained may use a 1461 special null message (MA-Hello) to indicate the fact. A default 1462 value for MA-Hold-Time of 30 seconds is RECOMMENDED. Nodes MAY 1463 use shorter times to achieve more rapid peer failure detection, 1464 but need to take into account the load on the network created by 1465 the MA-Hello messages. Nodes MAY use longer times, but need to 1466 take into account the cost of retaining idle MAs for extended 1467 periods. 1469 Because the Responding node can choose not to retain state until a 1470 Confirm, an abbreviated Stack-Configuration-Data object containing 1471 just this information MUST be repeated by the Querying node in the 1472 first Confirm sent on a new MA. 1474 Messaging associations can always be set up on demand, and messaging 1475 association status is not made directly visible outside the GIST 1476 layer. Therefore, even if GIST tears down and later re-establishes a 1477 messaging association, signaling applications cannot distinguish this 1478 from the case where the MA is kept permanently open. To maintain the 1479 transport semantics described in Section 4.1, GIST MUST close 1480 transport connections carrying reliable messages gracefully or report 1481 an error condition, and MUST NOT open a new association for a given 1482 session and peer while messages on a previous association may still 1483 be outstanding. 1485 This specification defines precisely only the time at which routing 1486 state or messaging associations expire; it does not define when 1487 refresh handshakes or keepalives should be initiated. 1488 Implementations MUST select timer settings which take at least the 1489 following into account: 1491 o The transmission latency between source and destination; 1493 o The need for retransmissions, either explicitly or within the 1494 messaging association protocols; 1496 o The need to avoid network synchronisation of control traffic (cf. 1497 [39]). 1499 In most cases, a reasonable policy is to initiate the refresh process 1500 when between 1/2 and 3/4 of the appropriate validity time has elapsed 1501 since the last successful refresh. The actual moment is chosen 1502 randomly within this interval to avoid synchronisation effects. 1504 5. Message Formats and Transport 1506 5.1. GIST Messages 1508 All GIST messages begin with a common header, followed by a sequence 1509 of type-length-value (TLV) objects. This subsection describes the 1510 various GIST messages and their contents at a high level in ABNF [9]; 1511 a more detailed description of the header and each object is given in 1512 Section 5.2. Note that the NAT traversal mechanism for GIST involves 1513 the insertion of an additional NAT-Traversal-Object in Query, 1514 Response and Error messages; the rules for this are given in 1515 Section 7.2. 1517 GIST-Message: The primary messages are either one of the stages in 1518 the three-way handshake, or a simple message carrying NSLP data. 1519 Additional types are defined for errors and keeping messaging 1520 associations alive. 1522 GIST-Message = Query / Response / Confirm / 1523 Data / Error / MA-Hello 1525 The common header includes a version number, message type and size, 1526 and NSLPID. It also carries a hop count to prevent message looping 1527 and various control flags, including one (the R flag) to indicate if 1528 a reply of some sort is requested. The objects following the common 1529 header MUST be carried in a fixed order, depending on message type. 1530 Messages with missing, duplicate or invalid objects for the message 1531 type MUST be rejected with an "Object Type Error" error message with 1532 the appropriate subcode (Appendix A.4.4.9). 1534 Query: A Query MUST be sent in D-mode, in fact with the special 1535 Q-mode encapsulation. In addition to the common header, it contains 1536 certain mandatory control objects, and MAY contain a signaling 1537 application payload. A stack proposal and configuration data MUST be 1538 included if the message exchange relates to setup of a messaging 1539 association. The R flag MUST always be set (R=1) in a Query, since 1540 this message always elicits a Response. 1542 Query = Common-Header 1543 [ NAT-Traversal-Object ] 1544 Message-Routing-Information 1545 Session-Identification 1546 Network-Layer-Information 1547 Query-Cookie 1548 [ Stack-Proposal Stack-Configuration-Data ] 1549 [ NSLP-Data ] 1551 Response: A Response may be sent in D-mode, or C-mode if a messaging 1552 association is being re-used. It MUST echo the MRI SID and Query- 1553 Cookie of the Query, and in D-mode carries its own Network-Layer- 1554 Information; if the message exchange relates to setup of a messaging 1555 association, which can only take place in D-mode, a Responder cookie 1556 MUST be included, as well as its own stack proposal and configuration 1557 data. The R flag MUST be set (R=1) if a Responder cookie is present 1558 but otherwise is optional; if the R flag is set, a Confirm MUST be 1559 sent as a reply. Note that the direction of this MRI will be 1560 inverted compared to that in the Query, that is, an upstream MRI 1561 becomes downstream and vice versa (see Section 3.3). 1563 Response = Common-Header 1564 [ NAT-Traversal-Object ] 1565 Message-Routing-Information 1566 Session-Identification 1567 [ Network-Layer-Information ] 1568 Query-Cookie 1569 [ Responder-Cookie 1570 [ Stack-Proposal Stack-Configuration-Data ] ] 1571 [ NSLP-Data ] 1573 Confirm: A Confirm may be sent in D-mode, or C-mode if a messaging 1574 association has been re-used. It MUST echo the MRI (with inverted 1575 direction), SID, and Responder-Cookie if the Response carried one; if 1576 the message exchange relates to setup of a new messaging association 1577 or re-use of an existing one (which can only take place in C-mode), 1578 the message MUST also echo the Stack-Proposal from the Response so it 1579 can be verified that this has not been tampered with. The first 1580 message on an association MUST also repeat the Stack-Configuration- 1581 Data from the original Query in an abbreviated form, just containing 1582 the MA-Hold-Time. 1584 Confirm = Common-Header 1585 Message-Routing-Information 1586 Session-Identification 1587 Network-Layer-Information 1588 [ Responder-Cookie 1589 [ Stack-Proposal 1590 [ Stack-Configuration-Data ] ] ] 1591 [ NSLP-Data ] 1593 Data: The Data message is used to transport NSLP data without 1594 modifying GIST state. It contains no control objects, but only the 1595 MRI and SID associated with the NSLP data being transferred. 1596 Network-Layer-Information (NLI) MUST be carried in the D-mode case, 1597 but MUST NOT be included otherwise. 1599 Data = Common-Header 1600 Message-Routing-Information 1601 Session-Identification 1602 [ Network-Layer-Information ] 1603 NSLP-Data 1605 Error: An Error message reports a problem determined at the GIST 1606 level. (Errors generated by signaling applications are reported in 1607 NSLP-Data payloads and are not treated specially by GIST.) The 1608 message includes a Network-Layer-Information object for the 1609 originator of the error message if it is being sent in D-mode; all 1610 other information related to the error is carried in a GIST-Error- 1611 Data object. 1613 Error = Common-Header 1614 [ NAT-Traversal-Object ] 1615 [ Network-Layer-Information ] 1616 GIST-Error-Data 1618 MA-Hello: This message MUST be sent only in C-mode to indicate that a 1619 node wishes to keep a messaging association open. It contains only 1620 the common header, with a NSLPID of zero. The R flag MAY be set 1621 (R=1); if so, the peer MUST send another message back along the 1622 messaging association. This allows a node to test the liveness of 1623 the peer. 1625 MA-Hello = Common-Header 1627 5.2. Information Elements 1629 This section describes the content of the various objects that can be 1630 present in each GIST message, both the common header, and the 1631 individual TLVs. The bit formats are provided in Appendix A. 1633 5.2.1. The Common Header 1635 Each message begins with a fixed format common header, which contains 1636 the following information: 1638 Version: The version number of the GIST protocol. This specification 1639 defines GIST version 1. 1641 Length: The number of 32 bit words in the message following the 1642 common header. 1644 Upper layer identifier (NSLPID): This gives the specific NSLP that 1645 this message is used for. 1647 GIST hop count: A hop count to prevent a message from looping. 1649 Message type: The message type (Query, Response, etc.) 1651 Source addressing mode: If set (S=1), this indicates that the IP 1652 source address of the message is the same as the IP address of the 1653 signaling peer, so replies to this message can be sent safely to 1654 this address. S is always set in C-mode. It is cleared (S=0) if 1655 the IP source address was derived from the message routing 1656 information in the payload and this is different from the 1657 signaling source address. 1659 Response requested: A flag which if set (R=1) indicates that a GIST 1660 message should be sent in response to this message. The 1661 appropriate message type for the response depends on the type of 1662 the initial message. 1664 Explicit routing: A flag which if set (E=1) indicates that the 1665 message was explicitly routed (see Section 7.1.4). 1667 5.2.2. TLV Objects 1669 All data following the common header is encoded as a sequence of 1670 type-length-value objects. Currently, each object can occur at most 1671 once; the set of required and permitted objects is determined by the 1672 message type and encapsulation (D-mode or C-mode). 1674 Message-Routing-Information (MRI): Information sufficient to define 1675 how the signaling message should be routed through the network. 1677 Message-Routing-Information = message-routing-method 1678 method-specific-information 1680 The format of the method-specific-information depends on the 1681 message-routing-method requested by the signaling application. 1682 Note that it always includes a flag defining the direction as 1683 either 'upstream' or 'downstream' (see Section 3.3). It is 1684 provided by the NSLP in the message sender and used by GIST to 1685 select the message routing. 1687 Session-Identification (SID): The GIST session identifier is a 128 1688 bit, cryptographically random identifier chosen by the node which 1689 originates the signaling exchange. See Section 3.5. 1691 Network-Layer-Information (NLI): This object carries information 1692 about the network layer attributes of the node sending the 1693 message, including data related to the management of routing 1694 state. This includes a peer identity and IP address for the 1695 sending node. It also includes IP-TTL information to allow the IP 1696 hop count between GIST peers to be measured and reported, and a 1697 validity time (RS-validity-time) for the routing state. 1699 Network-Layer-Information = peer-identity 1700 interface-address 1701 RS-validity-time 1702 IP-TTL 1704 The use of the RS-validity-time field is described in 1705 Section 4.4.3. The peer-identity and interface-address are used 1706 for matching existing associations, as discussed in Section 4.4.2. 1708 The interface-address must be routable, i.e. it MUST be usable as 1709 a destination IP address for packets to be sent back to the node 1710 generating the signaling message, whether in D-mode or C-mode. If 1711 this object is carried in a Query or Confirm, the interface- 1712 address MUST specifically be set to an address bound to the 1713 interface associated with the MRI, to allow its use in route 1714 change handling as discussed in Section 7.1. A suitable choice is 1715 the interface that is carrying the outbound flow. A node may have 1716 several choices for which of its addresses to use as the 1717 interface-address. For example, there may be a choice of IP 1718 versions, or addresses of limited scope (e.g. link-local), or 1719 addresses bound to different interfaces in the case of a router or 1720 multi-homed host. However, some of these interface addresses may 1721 not be usable by the peer. A node MUST follow a policy of using a 1722 global address of the same IP version as in the MRI, unless it can 1723 establish that an alternative address would also be usable. 1725 The setting and interpretation of the IP-TTL field depends on the 1726 message direction (upstream/downstream as determined from the MRI 1727 as described above) and encapsulation. 1729 * If the message is sent downstream, if the TTL that will be set 1730 in the IP header for the message can be determined, the IP-TTL 1731 value MUST be set to this value, or else set to 0. 1733 * On receiving a downstream message in D-mode, a non-zero IP-TTL 1734 is compared to the TTL in the IP header, and the difference is 1735 stored as the IP-hop-count-to-peer for the upstream peer in the 1736 routing state table for that flow. Otherwise, the field is 1737 ignored. 1739 * If the message is sent upstream, the IP-TTL MUST be set to the 1740 value of the IP-hop-count-to-peer stored in the routing state 1741 table, or 0 if there is no value yet stored. 1743 * On receiving an upstream message, the IP-TTL is stored as the 1744 IP-hop-count-to-peer for the downstream peer. 1746 In all cases, the IP-TTL value reported to signaling applications 1747 is the one stored with the routing state for that flow, after it 1748 has been updated if necessary from processing the message in 1749 question. 1751 Stack-Proposal: This field contains information about which 1752 combinations of transport and security protocols are available for 1753 use in messaging associations, and is also discussed further in 1754 Section 5.7. 1756 Stack-Proposal = 1*stack-profile 1758 stack-profile = 1*protocol-layer 1760 Each protocol-layer field identifies a protocol with a unique tag; 1761 any additional data, such as higher-layer addressing or other 1762 options data associated with the protocol, will be carried in a 1763 MA-protocol-options field in the Stack-Configuration-Data TLV (see 1764 below). 1766 Stack-Configuration-Data (SCD): This object carries information about 1767 the overall configuration of a messaging association. 1769 Stack-Configuration-Data = MA-Hold-Time 1770 0*MA-protocol-options 1772 The MA-Hold-Time field indicates how long a node will hold open an 1773 inactive association; see Section 4.4.3 for more discussion. The 1774 MA-protocol-options fields give the configuration of the protocols 1775 (e.g. TCP, TLS) to be used for new messaging associations, and 1776 they are described in more detail in Section 5.7. 1778 Query-Cookie/Responder-Cookie: A Query-Cookie is contained in a Query 1779 and MUST be echoed in a Response; a Responder-Cookie MAY be sent 1780 in a Response, and if present MUST be echoed in the following 1781 Confirm. Cookies are variable length bit strings, chosen by the 1782 cookie generator. See Section 8.5 for further details on 1783 requirements and mechanisms for cookie generation. 1785 NSLP-Data: The NSLP payload to be delivered to the signaling 1786 application. GIST does not interpret the payload content. 1788 GIST-Error-Data: This contains all the information to determine the 1789 cause and context of an error. 1791 GIST-Error-Data = error-class error-code error-subcode 1792 common-error-header 1793 [ Message-Routing-Information-content ] 1794 [ Session-Identification-content ] 1795 0*additional-information 1796 [ comment ] 1798 The error-class indicates the severity level, and the error-code 1799 and error-subcode identify the specific error itself. A full list 1800 of GIST errors and their severity levels is given in Appendix A.4. 1801 The common-error-header carries the Common-Header from the 1802 original message, and contents of the Message-Routing-Information 1803 (MRI) and Session-Identification (SID) objects are also included 1804 if they were successfully decoded. For some errors, additional 1805 information fields must be included according to a fixed format; 1806 finally, an optional free-text comment may be added. 1808 5.3. D-mode Transport 1810 This section describes the various encapsulation options for D-mode 1811 messages. Although there are several possibilities, depending on 1812 message type, MRM, and local policy, the general design principle is 1813 that the sole purpose of the encapsulation is to ensure that the 1814 message is delivered to or intercepted at the correct peer. Beyond 1815 that, minimal significance is attached to the type of encapsulation 1816 or the values of addresses or ports used for it. This allows new 1817 options to be developed in the future to handle particular deployment 1818 requirements without modifying the overall protocol specification. 1820 5.3.1. Normal Encapsulation 1822 Normal encapsulation MUST be used for all D-mode messages where the 1823 signaling peer is already known from previous signaling. This 1824 includes Response and Confirm messages, and Data messages except if 1825 these are being sent without using local routing state. Normal 1826 encapsulation is simple: the complete set of GIST payloads is 1827 concatenated together with the common header, and placed in the data 1828 field of a UDP datagram. UDP checksums MUST be enabled. The message 1829 is IP addressed directly to the adjacent peer; the UDP port numbering 1830 MUST be compatible with that used on Query messages (see below), that 1831 is, the same for messages in the same direction and with port numbers 1832 swapped for messages in the opposite direction. 1834 5.3.2. Q-mode Encapsulation 1836 Q-mode encapsulation MUST be used for messages where no routing state 1837 is available or where the routing state is being refreshed, in 1838 particular for Query messages. Q-mode encapsulation is similar to 1839 normal encapsulation, with changes in IP address selection, IP 1840 options, and a defined method for selecting UDP ports. 1842 In general, the IP addresses are derived from information in the MRI; 1843 the exact rules depend on the MRM. In addition, the IP header is 1844 given a Router Alert Option ([1] and [5]) to assist the peer in 1845 intercepting the message depending on the NSLPID. Each NSLPID maps 1846 to a unique RAO value, but one RAO value may refer to multiple 1847 NSLPIDs; further details are discussed in [11]. 1849 The source UDP port is selected by the message sender as the port at 1850 which it is prepared to receive UDP messages in reply, and a 1851 destination UDP port is allocated for GIST by IANA (see Section 9). 1852 Note that for some MRMs, GIST nodes anywhere along the path can 1853 generate GIST packets with source addresses that spoof the source 1854 address of the data flow. Therefore, destinations cannot distinguish 1855 these packets from genuine end-to-end data purely on address 1856 analysis. Instead, it must be possible to distinguish such GIST 1857 packets by port analysis; furthermore, the mechanism to do so must 1858 remain valid even if the destination is GIST-unaware. GIST solves 1859 this problem by using a fixed destination UDP port from the "well 1860 known" space for the Q-mode encapsulation. This port should never be 1861 allocated on a GIST-unaware host, and therefore Q-mode encapsulated 1862 messages will always be rejected with an ICMP error. 1864 5.3.3. Retransmission and Rate Control 1866 D-mode uses UDP, and hence has no automatic reliability or congestion 1867 control capabilities. Signaling applications requiring reliability 1868 should be serviced using C-mode, which should also carry the bulk of 1869 signaling traffic. However, some form of messaging reliability is 1870 required for the GIST control messages themselves, as is rate control 1871 to handle retransmissions and also bursts of unreliable signaling or 1872 state setup requests from the signaling applications. 1874 Query messages which do not receive Responses MAY be retransmitted; 1875 retransmissions MUST use a binary exponential backoff. The initial 1876 timer value is T1, which the backoff process can increase up to a 1877 maximum value of T2 seconds. The default value for T1 is 500 ms. T1 1878 is an estimate of the round-trip time between the querying and 1879 responding nodes. Elements MAY use smaller values of T1 if it is 1880 known that the Query should be answered within the local network. T1 1881 MAY be chosen larger, and this is RECOMMENDED if it is known in 1882 advance (such as on high latency access links) that the round-trip 1883 time is larger. The default value of T2 is 64*T1. 1885 Note that Queries may go unanswered either because of message loss 1886 (in either direction), or because there is no reachable GIST peer. 1887 Therefore, implementations MAY trade off reliability (large T2) 1888 against promptness of error feedback to applications (small T2). If 1889 the NSLP has indicated a timeout on the validity of this payload (see 1890 Appendix B.1), T2 MUST be chosen so that the process terminates 1891 within this timeout. 1893 Retransmitted Queries MUST use different Query-Cookie values. If the 1894 Query carries NSLP data, it may be delivered multiple times to the 1895 signaling application. These rules apply equally to the message that 1896 first creates routing state, and those that refresh it. 1898 This algorithm is sufficient to handle lost Queries and Responses. 1899 The case of a lost Confirm is more subtle. Notionally, we can 1900 distinguish between two cases: 1902 1. Where the Responding node is already prepared to store per-flow 1903 state after receiving a single (Query) message. This would 1904 include any cases where the node has NSLP data queued to send. 1905 Here, the Responding node MAY run a retransmission timer to 1906 resend the Response until a Confirm is received, since the node 1907 is already managing state for that flow. The problem of an 1908 amplification attack stimulated by a malicious Query is handled 1909 by requiring the cookie mechanism to enable the node receiving 1910 the Response to discard it efficiently if it does not match a 1911 previously sent Query. 1913 2. Where the responding node is not prepared to store per-flow state 1914 until receiving a properly formed Confirm. 1916 Case (2) should be handled without requiring a retransmission timer, 1917 since this would require per-flow state at the Responding node. 1918 However, we can assume that the next signaling message will be in the 1919 direction Querying Node -> Responding Node (if there is no next 1920 signaling message, the fact that the Confirm has been lost is moot). 1921 In this case, the responding node will start to receive messages at 1922 the GIST level for a MRI/NSLP combination for which there is no 1923 stored routing state, since this state is only created on receipt of 1924 a Confirm. 1926 Therefore, the error condition is detected at the Responding node 1927 when such a message arrives, without the need for a specific timer. 1928 Recovery requires a Confirm to be transmitted and successfully 1929 received. The mechanism to cause this is that the Responding node 1930 MUST reject the incoming message with a "No Routing State" error 1931 message (Appendix A.4.4.5) back to the Querying node, which MUST 1932 interpret this as caused by a lost Confirm; the Querying node MUST 1933 regenerate the Confirm purely from local state. In particular, it 1934 needs to remember a valid Responder Cookie. 1936 In all cases, Responses MUST be sent promptly to avoid spurious 1937 retransmissions. Nodes generating any type of retransmission MUST be 1938 prepared to receive and match a reply to any of them, not just the 1939 one most recently sent. 1941 The basic rate-control requirements for D-mode traffic are 1942 deliberately minimal. A single rate limiter applies to all traffic, 1943 for all interfaces and message types. It applies to retransmissions 1944 as well as new messages, although an implementation MAY choose to 1945 prioritise one over the other. Rate-control applies only to locally 1946 generated D-mode messages, not to messages which are being forwarded. 1947 When the rate limiter is in effect, D-mode messages MUST be queued 1948 until transmission is re-enabled, or an error condition MAY be 1949 indicated back to local signaling applications. The rate limiting 1950 mechanism is implementation-defined, but it is RECOMMENDED that a 1951 token bucket limiter as described in [31] be used. The token bucket 1952 MUST be sized to ensure that a node cannot saturate the network with 1953 D-mode traffic, for example when re-probing the network for multiple 1954 flows after a route change. A suitable approach is to restrict the 1955 token bucket parameters so that the mean output rate is a small 1956 fraction, such as 5%, of the node's lowest-speed interface. 1958 5.4. C-mode Transport 1960 Encapsulation in C-mode is more complex, because of the variation in 1961 available transport functionality. This issue is treated in 1962 Section 5.4.1. The actual encapsulation is given in Section 5.4.2. 1964 5.4.1. Choice of Transport Protocol 1966 It is a general requirement of the NTLP defined in [26] that it 1967 should be able to support bundling of small messages, fragmentation 1968 of large messages, and message boundary delineation. Not all 1969 transport protocols natively support all these features. 1971 TCP provides both bundling and fragmentation, but not message 1972 boundaries. However, the length information in the GIST common 1973 header allows the message boundary to be discovered during 1974 parsing. 1976 SCTP [16] satisfies all requirements. 1978 DCCP [30] is message-based but does not provide bundling or 1979 fragmentation, nor does it provide reliability. Bundling can be 1980 carried out by the GIST layer sending multiple messages in a 1981 single datagram; because the common header includes length 1982 information, the message boundaries within the datagram can be 1983 discovered during parsing. Fragmentation of GIST messages over 1984 multiple datagrams should be avoided, because of amplification of 1985 message loss rates that this would cause. 1987 The bundling together of small messages is either built into the 1988 transport protocol or can be carried out by the GIST layer during 1989 message construction. Either way, two approaches can be 1990 distinguished: 1992 1. As messages arrive for transmission they are gathered into a 1993 bundle until a size limit is reached or a timeout expires (cf. 1994 the Nagle algorithm of TCP or similar optional functionality in 1995 SCTP). This provides maximal efficiency at the cost of some 1996 latency. 1998 2. Messages awaiting transmission are gathered together while the 1999 node is not allowed to send them, for example because it is 2000 congestion controlled. 2002 The second type of bundling is always appropriate. For GIST, the 2003 first type MUST NOT be used for trigger messages (i.e. messages that 2004 update GIST or signaling application state), but may be appropriate 2005 for refresh messages (i.e. messages that just extend timers). These 2006 distinctions are known only to the signaling applications, but MAY be 2007 indicated (as an implementation issue) by setting the priority 2008 transfer attribute (Section 4.1.2). 2010 It can be seen that all of these transport protocol options can be 2011 supported by the basic GIST message format already presented. GIST 2012 messages requiring fragmentation must be carried using a reliable 2013 transport protocol, TCP or SCTP. This specification defines only the 2014 use of TCP, but other possibilities could be included without 2015 additional work on message formatting. 2017 5.4.2. Encapsulation Format 2019 The GIST message, consisting of common header and TLVs, is carried 2020 directly in the transport protocol, possibly incorporating transport 2021 layer security protection. Further messages can be carried in a 2022 continuous stream (for TCP), or up to the next transport layer 2023 message boundary (for SCTP, DCCP, or UDP). This is shown in 2024 Figure 5. 2026 +---------------------------------------------+ 2027 | L2 Header | 2028 +---------------------------------------------+ 2029 | IP Header | ^ 2030 | Source address = signaling source | ^ 2031 | Destination address = signaling destination | . 2032 +---------------------------------------------+ . 2033 | L4 Header | . ^ 2034 | (Standard TCP/SCTP/DCCP/UDP header) | . ^ 2035 +---------------------------------------------+ . . 2036 | GIST Message | . . ^ 2037 | (Common header and TLVs as in section 5.1) | . . ^ Scope of 2038 +---------------------------------------------+ . . . security 2039 | Additional GIST messages, each with its | . . . protection 2040 | own common header, either as a continuous | . . . (depending 2041 | stream, or continuing to the next L4 | . . . on channel 2042 . message boundary . . . . security 2043 . . V V V mechanism 2044 . . V V V in use) 2046 Figure 5: C-mode Encapsulation 2048 5.5. Message Type/Encapsulation Relationships 2050 GIST has four primary message types (Query, Response, Confirm, and 2051 Data) and three possible encapsulation methods (normal D-mode, 2052 Q-mode, and C-mode). The possible combinations of message type and 2053 encapsulation are given in the table below. In some cases there are 2054 several possible choices, depending on the existence of routing state 2055 or messaging associations. The rules governing GIST policy, 2056 including whether or not to create such state to handle a message, 2057 are described normatively in the other sections of this 2058 specification. If a message arrives with an invalid encapsulation 2059 (e.g. a Query arrives over a messaging association), this MUST be 2060 rejected with an "Incorrect Encapsulation" error message 2061 (Appendix A.4.4.3). However, it should be noted that the processing 2062 of the message at the receiver is not otherwise affected by the 2063 encapsulation method used, except that that the decapsulation process 2064 may provide additional information, such as translated addresses or 2065 IP hop count to be used in the subsequent message processing. 2067 +----------+----------------+----------------------+----------------+ 2068 | Message | Normal D-mode | Query D-mode | C-mode | 2069 | | | (Q-mode) | | 2070 +----------+----------------+----------------------+----------------+ 2071 | Query | Never | Always | Never | 2072 | | | | | 2073 | Response | Unless a | Never | If a messaging | 2074 | | messaging | | association is | 2075 | | association is | | being re-used | 2076 | | being re-used | | | 2077 | | | | | 2078 | Confirm | Unless a | Never | If a messaging | 2079 | | messaging | | association | 2080 | | association | | has been set | 2081 | | has been set | | up or is being | 2082 | | up or is being | | re-used | 2083 | | re-used | | | 2084 | | | | | 2085 | Data | If routing | If no routing state | If a messaging | 2086 | | state exists | exists and the MRI | association | 2087 | | for the flow | can be used to | exists | 2088 | | but no | derive the Q-mode | | 2089 | | messaging | encapsulation | | 2090 | | association | | | 2091 +----------+----------------+----------------------+----------------+ 2093 5.6. Error Message Processing 2095 Special rules apply to the encapsulation and transmission of error 2096 messages. 2098 GIST only generates error messages in response to incoming messages. 2099 Error messages MUST NOT be generated in response to incoming error 2100 messages. The routing and encapsulation of the error message is 2101 derived from that of the message that caused the error; in 2102 particular, local routing state is not consulted. Routing state and 2103 messaging association state MUST NOT be created to handle the error, 2104 and error messages MUST NOT be retransmitted explicitly by GIST, 2105 although they are subject to the same rate control as other messages. 2107 o If the incoming message was received in D-mode, the error MUST be 2108 sent in D-mode using the normal encapsulation, using the 2109 addressing information from the NLI object in the incoming 2110 message. If the NLI could not be determined, the error MUST be 2111 sent to the IP source of the incoming message if the S flag was 2112 set in it. The NLI object in the Error message reports 2113 information about the originator of the error. 2115 o If the incoming message was received over a messaging association, 2116 the error MUST be sent back over the same messaging association. 2118 The NSLPID in the common header of the Error message has the value 2119 zero. If for any reason the message cannot be sent, for example, 2120 because it is too large to send in D-mode, an error SHOULD be logged 2121 locally. 2123 5.7. Messaging Association Setup 2125 5.7.1. Overview 2127 A key attribute of GIST is that it is flexible in its ability to use 2128 existing transport and security protocols. Different transport 2129 protocols may have performance attributes appropriate to different 2130 environments; different security protocols may fit appropriately with 2131 different authentication infrastructures. Even given an initial 2132 default mandatory protocol set for GIST, the need to support new 2133 protocols in the future cannot be ruled out, and secure feature 2134 negotiation cannot be added to an existing protocol in a backwards- 2135 compatible way. Therefore, some sort of capability discovery is 2136 required. 2138 Capability discovery is carried out in Query and Response messages, 2139 using Stack-Proposal and Stack-Configuration-Data objects. If a new 2140 messaging association is required it is then set up, followed by a 2141 Confirm. Messaging association re-use is achieved by short- 2142 circuiting this exchange by sending the Response or Confirm messages 2143 on an existing association (Section 4.4.2); whether to do this is a 2144 matter of local policy. The end result of this process is a 2145 messaging association which is a stack of protocols. If multiple 2146 associations exist, it is a matter of local policy how to distribute 2147 messages over them, subject to respecting the transfer attributes 2148 requested for each message. 2150 Every possible protocol for a messaging association has the following 2151 attributes: 2153 o MA-Protocol-ID, a 1-byte IANA assigned value (see Section 9). 2155 o A specification of the (non-negotiable) policies about how the 2156 protocol should be used; for example, in which direction a 2157 connection should be opened. 2159 o [Depending on the specific protocol:] Formats for an MA-protocol- 2160 options field to carry the protocol addressing and other 2161 configuration information in the Stack-Configuration-Data object. 2162 The format may differ depending on whether the field is present in 2163 the Query or Response. Some protocols do not require the 2164 definition of such additional data, in which case no corresponding 2165 MA-protocol-options field will occur in the SCD object. 2167 A Stack-Proposal object is simply a list of profiles; each profile is 2168 a sequence of MA-Protocol-IDs. A profile lists the protocols in 'top 2169 to bottom' order (e.g. TLS over TCP, or TCP over IPsec). A Stack- 2170 Proposal is generally accompanied by a Stack-Configuration-Data 2171 object which carries an MA-protocol-options field for any protocol 2172 listed in the Stack-Proposal which needs it. An MA-protocol-options 2173 field may apply globally, to all instances of the protocol in the 2174 Stack-Proposal; or it can be tagged as applying to a specific 2175 instance. The latter approach can be used to carry different port 2176 numbers for TCP depending on whether it is to be used with or without 2177 TLS. An MA-protocol-options field may also be flagged as not usable; 2178 for example, a NAT which could not handle SCTP would set this in an 2179 MA-protocol-options field about SCTP. A protocol flagged this way 2180 MUST NOT be used for a messaging association. If the Stack-Proposal 2181 and Stack-Configuration-Data are both present but not consistent, for 2182 example, if they refer to different protocols, or an MA-protocol- 2183 options field refers to a non-existent profile, an "Object Value 2184 Error" error message (Appendix A.4.4.10) with subcode 5 ("Stack- 2185 Proposal - Stack-Configuration-Data Mismatch") MUST be returned and 2186 the message dropped. 2188 A node generating a Stack-Configuration-Data object MUST honour the 2189 implied protocol configurations for the period during which a 2190 messaging association might be set up; in particular, it MUST be 2191 immediately prepared to accept incoming datagrams or connections at 2192 the protocol/port combinations advertised. This MAY require the 2193 creation of listening endpoints for the transport and security 2194 protocols in question, or a node MAY keep a pool of such endpoints 2195 open for extended periods. However, the received object contents 2196 MUST be retained only for the duration of the Query/Response exchange 2197 and to allow any necessary association setup to complete. They may 2198 become invalid because of expired bindings at intermediate NATs, or 2199 because the advertising node is using agile ports. Once the setup is 2200 complete, or if it is not necessary, or fails for some reason, the 2201 object contents MUST be discarded. A default time of 30 seconds to 2202 keep the contents is RECOMMENDED. 2204 A Query requesting association setup always contains a Stack-Proposal 2205 and Stack-Configuration-Data object. The Stack-Proposal MUST only 2206 include protocol configurations that are suitable for the transfer 2207 attributes of the messages that the Querying node wishes use the 2208 messaging association for. For example, it should not simply include 2209 all configurations that the Querying node is capable of supporting. 2211 The Response always contains a Stack-Proposal and Stack- 2212 Configuration-Data object, unless re-use (where the Responder decides 2213 to use an existing association) occurs. For such a Response, the 2214 Stack-Proposal MUST NOT depend on the Query. A node MAY make 2215 different proposals depending on the combination of interface and 2216 NSLPID. If re-use does occur, which is indicated by sending the 2217 Response over an existing messaging association, the following rules 2218 apply: 2220 o The re-used messaging association MUST NOT have weaker security 2221 properties than would have been offered in the full Response that 2222 would have been sent without re-use. 2224 o The re-used messaging association MUST have equivalent or better 2225 transport and security characteristics as at least one of the 2226 protocol configurations that was offered in the Query. 2228 Once the messaging association is set up, the querying node repeats 2229 the responder's Stack-Proposal over it in the Confirm. The 2230 responding node MUST verify that this has not been changed as part of 2231 bidding-down attack prevention. If a difference is detected, the 2232 responding node MUST terminate the messaging association and SHOULD 2233 log an error condition locally. See Section 8.6 for further 2234 discussion. 2236 5.7.2. Protocol Definition: Forwards-TCP 2238 This MA-Protocol-ID denotes a basic use of TCP between peers. 2239 Support for this protocol is REQUIRED. If this protocol is offered, 2240 MA-protocol-options data MUST also be carried in the SCD object. The 2241 MA-protocol-options field formats are: 2243 o in a Query: no information apart from the field header. 2245 o in a Response: 2 byte port number at which the connection will be 2246 accepted, followed by 2 pad bytes. 2248 The connection is opened in the forwards direction, from the querying 2249 node towards the responder. The querying node MAY use any source 2250 address and source port. The destination information MUST be derived 2251 from information in the Response: the address from the interface- 2252 address from the Network-Layer-Information object and the port from 2253 the SCD object as described above. 2255 Associations using Forwards-TCP can carry messages with the transfer 2256 attribute Reliable=True. If an error occurs on the TCP connection 2257 such as a reset, as can be detected for example by a socket exception 2258 condition, GIST MUST report this to NSLPs as discussed in 2259 Section 4.1.2. 2261 5.7.3. Protocol Definition: Transport Layer Security 2263 This MA-Protocol-ID denotes a basic use of transport layer channel 2264 security. Support for this protocol is mandatory; associations using 2265 it can carry messages with the transfer attribute Secure=True. For 2266 use with TCP, implementation of TLS1.0 [7] is REQUIRED and 2267 implementation of TLS1.1 [10] is RECOMMENDED. (If an unreliable 2268 transport such as DCCP or UDP is defined for GIST in the future, this 2269 MA-Protocol-ID would be implemented for it using DTLS [41].) GIST 2270 nodes supporting TLS1.0 or TLS1.1 MUST be able to negotiate the TLS 2271 ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD be able to 2272 negotiate the TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. 2274 The default mode of TLS authentication, which applies in particular 2275 to the above ciphersuites, uses a client/server certificate exchange. 2276 The Querying node acts as a TLS client, and the Responding node acts 2277 as a TLS server. Where one of the above ciphersuites is negotiated, 2278 the GIST node acting as a server MUST provide a certificate, and MUST 2279 request one from the GIST node acting as a TLS client. This allows 2280 either server-only or mutual authentication, depending on the 2281 certificates available to the client and the policy applied at the 2282 server. 2284 GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the 2285 negotiation of alternative ciphersuites is used to trigger 2286 alternative authentication procedures, such as the use of pre-shared 2287 keys [29]. The use of other authentication procedures may require 2288 additional specification work to define how they can be used as part 2289 of TLS within the GIST framework, and may or may not require the 2290 definition of additional MA-Protocol-IDs. 2292 No MA-protocol-options field is required for this use of TLS. 2294 5.7.4. Additional Protocol Options 2296 Further protocols or configurations could be defined in the future 2297 for additional performance or flexibility. Examples are: 2299 o SCTP or DCCP as alternatives to TCP, with essentially the same 2300 configuration. 2302 o SigComp [21] for message compression. 2304 o IPsec [35], ssh [36], or HIP/IPsec [37] for channel security. 2306 o Alternative modes of TCP operation, for example where it is set up 2307 from the responder to the querying node. 2309 5.8. Specific Message Routing Methods 2311 Each message routing method (see Section 3.3) requires the definition 2312 of the format of the message routing information (MRI) and Q-mode 2313 encapsulation rules. These are given in the following subsections 2314 for the various possible MRMs. 2316 5.8.1. The Path-Coupled MRM 2318 5.8.1.1. Message Routing Information 2320 For the path-coupled MRM, this is conceptually the Flow Identifier as 2321 in the NSIS Framework [26]. Minimally, this could just be the flow 2322 destination address; however, to account for policy based forwarding 2323 and other issues a more complete set of header fields SHOULD be 2324 specified if possible (see Section 4.3.4 and Section 7.2 for further 2325 discussion). 2327 MRI = network-layer-version 2328 source-address prefix-length 2329 destination-address prefix-length 2330 IP-protocol 2331 diffserv-codepoint 2332 [ flow-label ] 2333 [ ipsec-SPI / L4-ports] 2335 Additional control information defines whether the flow-label, IPsec 2336 Security Parameters Index (SPI), and port information are present, 2337 and whether the IP-protocol and diffserv-codepoint fields should be 2338 interpreted as significant. The source and destination addresses 2339 MUST be real node addresses, but prefix lengths other than 32/128 2340 (for IPv4/6) MAY be used to implement address wildcarding, allowing 2341 the MRI to refer to traffic to or from a wider address range. 2343 The MRI format allows a potentially very large number of different 2344 flag and field combinations. A GIST implementation that cannot 2345 interpret the MRI in a message MUST return an "Object Value Error" 2346 message (Appendix A.4.4.10) with subcodes 1 ("Value Not Supported") 2347 or 2 ("Invalid Flag-Field Combination") and drop the message. 2349 5.8.1.2. Downstream Q-mode Encapsulation 2351 Where the signaling message is travelling in the same ('downstream') 2352 direction as the flow defined by the MRI, the IP addressing for 2353 Q-mode encapsulated messages is as follows. Support for this 2354 encapsulation is REQUIRED. 2356 o The destination IP address MUST be the flow destination address as 2357 given in the MRI of the message payload. 2359 o By default, the source address is the flow source address, again 2360 from the MRI. This provides the best likelihood that the message 2361 will be correctly routed through any region performing per-packet 2362 policy-based forwarding or load balancing which takes the source 2363 address into account. However, there may be circumstances where 2364 the use of the signaling source address is preferable, such as: 2366 * In order to receive ICMP error messages about the signaling 2367 message (such as unreachable port or address). If these are 2368 delivered to the flow source rather than the signaling source, 2369 it will be very difficult for the querying node to detect that 2370 it is the last GIST node on the path. 2372 * In order to receive GIST Error messages where the error message 2373 sender could not interpret the NLI in the original message. 2375 * In order to attempt to run GIST through an unmodified NAT, 2376 which will only process and translate IP addresses in the IP 2377 header. 2379 Because of these considerations, use of the signaling source 2380 address is allowed as an option, with use based on local policy. 2381 A node SHOULD use the flow source address for initial Query 2382 messages, but SHOULD transition to the signaling source address 2383 for some retransmissions or as a matter of static configuration, 2384 for example if a NAT is known to be in the path out of a certain 2385 interface. The S-flag in the common header tells the message 2386 receiver which option was used. 2388 It is vital that the Query mimics the actual data flow as closely as 2389 possible, since this is the basis of how the signaling message is 2390 attached to the data path. To this end, GIST SHOULD set the DiffServ 2391 codepoint and (for IPv6) flow label to match the values in the MRI. 2393 Any message sent in D-mode MUST have a size below a conservative 2394 estimate of the path MTU, for which this specification takes the 2395 value 512 bytes as a default. It is possible that fragmented 2396 datagrams including an RAO will not be correctly handled in the 2397 network, so the sender MAY set the Don't Fragment (DF) bit in the 2398 IPv4 header in order to detect that a message has encountered a link 2399 with an unusually low MTU. If the sender sets DF for any reason, it 2400 SHOULD use the signaling source address for the IP source address in 2401 order to receive the ICMP error. 2403 A GIST implementation SHOULD apply validation checks to the MRI, to 2404 reject Query messages that are being injected by nodes with no 2405 legitimate interest in the flow being signalled for. In general, if 2406 the GIST node can detect that no flow could arrive over the same 2407 interface as the Query, it MUST be rejected with an appropriate error 2408 message. Such checks apply only to messages with the Q-mode 2409 encapsulation, since only those messages are required to track the 2410 flow path. The main checks are that the IP version should match the 2411 version(s) used on that interface, and that the full range of source 2412 addresses (the source-address masked with its prefix-length) would 2413 pass ingress filtering checks. For these cases, the error message is 2414 "MRI Validation Failure" (Appendix A.4.4.12) with subcodes 1 or 2 2415 ("IP Version Mismatch" or "Ingress Filter Failure") respectively. 2417 5.8.1.3. Upstream Q-mode Encapsulation 2419 In some deployment scenarios it is desirable to set up routing state 2420 in the upstream direction, (i.e. from flow receiver towards the 2421 sender). This could be used to support firewall signaling to control 2422 traffic from an un-cooperative sender, or signaling in general where 2423 the flow sender was not NSIS-capable. This capability is 2424 incorporated into GIST by defining an encapsulation and processing 2425 rules for sending Query messages upstream. 2427 In general, it is not possible to determine the hop-by-hop route 2428 upstream because of asymmetric routing. However, in particular 2429 cases, the upstream peer can be discovered with a high degree of 2430 confidence, for example: 2432 o The upstream GIST peer is 1 IP hop away, and can be reached by 2433 tracing back through the interface on which the flow arrives. 2435 o The upstream peer is a border router of a single-homed (stub) 2436 network. 2438 This section defines an upstream Q-mode encapsulation and validation 2439 checks for when it can be used. The functionality to generate 2440 upstream Queries is OPTIONAL, but if received they MUST be processed 2441 in the normal way. No special functionality is needed for this. 2443 It is possible for routing state at a given node, for a specific MRI 2444 and NSLPID, to be created by both an upstream Query exchange 2445 (initiated by the node itself), and a downstream Query exchange 2446 (where the node is the responder). If the SIDs are different, these 2447 items of routing state MUST be considered as independent; if the SIDs 2448 match, the routing state installed by the downstream exchange MUST 2449 take precedence, provided that the downstream Query passed ingress 2450 filtering checks. The rationale for this is that the downstream 2451 Query is in general a more reliable way to install state, since it 2452 directly probes the routing infrastructure along the flow path, 2453 whereas use of the upstream Query depends on the correctness of the 2454 Querying node's understanding of the topology. 2456 The details of the encapsulation are as follows: 2458 o The destination address SHOULD be the flow source address as given 2459 in the MRI of the message payload. An implementation with more 2460 detailed knowledge of local routing MAY use an alternative 2461 destination address (e.g. the address of its default router). 2463 o The source address SHOULD be the signaling node address. 2465 o The DiffServ codepoint and (for IPv6) flow label MAY be set to 2466 match the values from the MRI, as in the downstream case. The 2467 same considerations about message size and fragmentation also 2468 apply as in the downstream case, and RAO setting and UDP port 2469 selection are also the same. 2471 o The IP layer TTL of the message MUST be set to 255. 2473 The sending GIST implementation SHOULD attempt to send the Query via 2474 the same interface and to the same link layer neighbour from which 2475 the data packets of the flow are arriving. 2477 The receiving GIST node MAY apply validation checks to the message 2478 and MRI, to reject Query messages which have reached a node at which 2479 they can no longer be trusted. In particular, a node SHOULD reject a 2480 message which has been propagated more than one IP hop, with an 2481 "Invalid IP layer TTL" error message (Appendix A.4.4.11). This can 2482 be determined by examining the received IP layer TTL, similar to the 2483 generalised IP TTL security mechanism described in [25]. 2484 Alternatively, receipt of an upstream Query at the flow source MAY be 2485 used to trigger setup of GIST state in the downstream direction. 2486 These restrictions may be relaxed in a future version. 2488 5.8.2. The Loose-End MRM 2490 The Loose-End MRM is used to discover GIST nodes with particular 2491 properties in the direction of a given address, for example to 2492 discover a NAT along the upstream data path as in [32]. 2494 5.8.2.1. Message Routing Information 2496 For the loose-end MRM, only a simplified version of the Flow 2497 Identifier is needed. 2499 MRI = network-layer-version 2500 source-address 2501 destination-address 2503 The source address is the address of the node initiating the 2504 discovery process, for example the node that will be the data 2505 receiver in the NAT discovery case. The destination address is the 2506 address of a node which is expected to be the other side of the node 2507 to be discovered. Additional control information defines the 2508 direction of the message relative to this flow as in the path-coupled 2509 case. 2511 5.8.2.2. Downstream Q-mode Encapsulation 2513 Only one encapsulation is defined for the loose-end MRM; by 2514 convention, this is referred to as the downstream encapsulation, and 2515 is defined as follows: 2517 o The IP destination address MUST be the destination address as 2518 given in the MRI of the message payload. 2520 o By default, the IP source address is the source address, again 2521 from the MRI. However, the use of the signaling source address is 2522 allowed as in the case of the path-coupled MRM. 2524 There are no special requirements on the setting of the DiffServ 2525 codepoint, IP layer TTL, or (for IPv6) the flow label. Nor are any 2526 special validation checks applied. Restrictions on message size and 2527 setting of the Don't Fragment (DF) bit apply as in the case of the 2528 path-coupled MRM. 2530 6. Formal Protocol Specification 2532 This section provides a more formal specification of the operation of 2533 GIST processing, in terms of rules for transitions between states of 2534 a set of communicating state machines within a node. The following 2535 description captures only the basic protocol specification; 2536 additional mechanisms can be used by an implementation to accelerate 2537 route change processing, and these are captured in Section 7.1. 2539 Conceptually, GIST processing at a node may be seen in terms of four 2540 types of cooperating state machine: 2542 1. There is a top-level state machine which represents the node 2543 itself (Node-SM). It is responsible for the processing of events 2544 which cannot be directed towards a more specific state machine, 2545 for example, inbound messages for which no routing state 2546 currently exists. This machine exists permanently, and is 2547 responsible for creating per-MRI state machines to manage the 2548 GIST handshake and routing state maintenance procedures. 2550 2. For each flow and signaling direction where the node is 2551 responsible for the creation of routing state, there is an 2552 instance of a Query-Node state machine (Querying-SM). This 2553 machine sends Query and Confirm messages and waits for Responses, 2554 according to the requirements from local API commands or timer 2555 processing, such as message repetition or routing state refresh. 2557 3. For each flow and signaling direction where the node has accepted 2558 the creation of routing state by a peer, there is an instance of 2559 a Responding-Node state machine (Responding-SM). This machine is 2560 responsible for managing the status of the routing state for that 2561 flow. Depending on policy, it MAY be responsible for 2562 [re]transmission of Response messages, or this MAY be handled by 2563 the Node-SM, and a Responding-SM is not even created for a flow 2564 until a properly formatted Confirm has been accepted. 2566 4. Messaging associations have their own lifecycle, represented by 2567 MA-SM, from when they are first created (in an incomplete state, 2568 listening for an inbound connection or waiting for outbound 2569 connections to complete), to when they are active and available 2570 for use. 2572 Apart from the fact that the various machines can be created and 2573 destroyed by each other, there is almost no interaction between them. 2574 The machines for different flows do not interact; the Querying-SM and 2575 Responding-SM for a single flow and signaling direction do not 2576 interact. That is, the Responding-SM which accepts the creation of 2577 routing state for a flow on one interface has no direct interaction 2578 with the Querying-SM which sets up routing state on the next 2579 interface along the path. This interaction is mediated instead 2580 through the NSLP. 2582 The state machine descriptions use the terminology rx_MMMM, tg_TTTT 2583 and er_EEEE for incoming messages, API/lower layer triggers and error 2584 conditions respectively. The possible events of these types are 2585 given in the table below. In addition, timeout events denoted 2586 to_TTTT may also occur; the various timers are listed independently 2587 for each type of state machine in the following subsections. 2589 +---------------------+---------------------------------------------+ 2590 | Name | Meaning | 2591 +---------------------+---------------------------------------------+ 2592 | rx_Query | A Query has been received. | 2593 | | | 2594 | rx_Response | A Response has been received. | 2595 | | | 2596 | rx_Confirm | A Confirm has been received. | 2597 | | | 2598 | rx_Data | A Data message has been received. | 2599 | | | 2600 | rx_Message | rx_Query||rx_Response||rx_Confirm||rx_Data. | 2601 | | | 2602 | rx_MA-Hello | A MA-Hello message has been received. | 2603 | | | 2604 | tg_NSLPData | A signaling application has requested data | 2605 | | transfer (via API SendMessage). | 2606 | | | 2607 | tg_Connected | The protocol stack for a messaging | 2608 | | association has completed connecting. | 2609 | | | 2610 | tg_RawData | GIST wishes to transfer data over a | 2611 | | particular messaging association. | 2612 | | | 2613 | er_NoRSM | A "No Routing State" error was received. | 2614 | | | 2615 | er_MAConnect | A messaging association protocol failed to | 2616 | | complete a connection. | 2617 | | | 2618 | er_MAFailure | A messaging association failed. | 2619 +---------------------+---------------------------------------------+ 2621 6.1. Node Processing 2623 The Node level state machine is responsible for processing events for 2624 which no more appropriate messaging association state or routing 2625 state exists. Its structure is trivial: there is a single state 2626 ('Idle'); all events cause a transition back to Idle. Some events 2627 cause the creation of other state machines. The only events that are 2628 processed by this state machine are incoming GIST messages (Query/ 2629 Response/Confirm/Data) and API requests to send data; no other events 2630 are possible. In addition to this event processing, the Node level 2631 machine is responsible for managing listening endpoints for messaging 2632 associations. Although these relate to Responding node operation, 2633 they cannot be handled by the Responder state machine since they are 2634 not created per flow. The processing rules for each event are as 2635 follows: 2637 Rule 1 (rx_Query): 2639 use the GIST service interface to determine the signaling application 2640 policy relating to this peer 2641 if (the signaling application indicates that routing state should 2642 be created) then 2643 if (routing state can be created without a 3-way handshake) then 2644 create Responding-SM and transfer control to it 2645 else 2646 send Response 2647 else 2648 propagate the Query with any updated NSLP payload provided 2650 Rule 2 (rx_Response): 2652 // should already have a Querying-SM to handle this 2653 discard message 2654 send "No Routing State" error message 2656 Rule 3 (rx_Confirm): 2658 if (routing state can be created before receiving a Confirm) then 2659 // we should already have Responding-SM for it, 2660 // which would handle this message 2661 discard message 2662 send "No Routing State" error message 2663 else 2664 create Responding-SM and pass message to it 2666 Rule 4 (rx_Data): 2668 if (node policy will only process Data messages with matching 2669 routing state) then 2670 send "No Routing State" error message 2671 else 2672 pass directly to NSLP 2674 Rule 5 (tg_NSLPData): 2676 if Q-mode encapsulation is not possible for this MRI 2677 reject message with an error 2678 else 2679 if (local policy & transfer attributes say routing 2680 state is not needed) then 2681 send message statelessly 2682 else 2683 create Querying-SM and pass message to it 2685 6.2. Query Node Processing 2687 The Querying-Node state machine (Querying-SM) has three states: 2689 o Awaiting Response 2691 o Established 2693 o Awaiting Refresh 2695 The Querying-SM is created by the Node-SM machine as a result of a 2696 request to send a message for a flow in a signaling direction where 2697 the appropriate state does not exist. The Query is generated 2698 immediately and the No_Response timer is started. The NSLP data MAY 2699 be carried in the Query if local policy and the transfer attributes 2700 allow it, otherwise it MUST be queued locally pending MA 2701 establishment. Then the machine transitions to the Awaiting Response 2702 state, in which timeout-based retransmissions are handled. Data 2703 messages (rx_Data events) should not occur in this state; if they do, 2704 this may indicate a lost Response and a node MAY also retransmit a 2705 Query for this reason. 2707 Once a Response has been successfully received and routing state 2708 created, the machine transitions to Established, during which NSLP 2709 data can be sent and received normally. Further Responses received 2710 in this state (which may be the result of a lost Confirm) MUST be 2711 treated the same way. The Awaiting Refresh state can be considered 2712 as a substate of Established, where a new Query has been generated to 2713 refresh the routing state (as in Awaiting Response) but NSLP data can 2714 be handled normally. 2716 The timers relevant to this state machine are as follows: 2718 Refresh_QNode: Indicates when the routing state stored by this state 2719 machine must be refreshed. It is reset whenever a Response is 2720 received indicating that the routing state is still valid. 2721 Implementations MUST set the period of this timer based on the 2722 value in the RS-validity-time field of a Response to ensure that a 2723 Query is generated before the peer's routing state expires. 2725 No_Response: Indicates that a Response has not been received in 2726 answer to a Query. This is started whenever a Query is sent and 2727 stopped when a Response is received. 2729 Inactive_QNode: Indicates that no traffic is currently being handled 2730 by this state machine. This is reset whenever the state machine 2731 handles NSLP data, in either direction. When it expires, the 2732 state machine MAY be deleted. The period of the timer can be set 2733 at any time via the API (SetStateLifetime), and if the period is 2734 reset in this way the timer itself MUST be restarted. 2736 The main events (including all those that cause state transitions) 2737 are shown in the figure below, tagged with the number of the 2738 processing rule that is used to handle the event. These rules are 2739 listed after the diagram. All events not shown or described in the 2740 text above are assumed to be impossible in a correct implementation. 2742 [Initialisation] +-----+ 2743 -------------------------|Birth| 2744 | +-----+ 2745 | rx_Response[4] 2746 | || tg_NSLPData[5] 2747 | tg_NSLPData[1] er_NoRSM[3] || rx_Data[7] 2748 | -------- ------------------ ------- 2749 | | V | V | V 2750 | | V | V | V 2751 | +----------+ | +-----------+ 2752 ---->>| Awaiting | ---------------- |Established| 2753 ------| Response |---------------------------->> | | 2754 | +----------+ rx_Response[4] +-----------+ 2755 | ^ | ^ | 2756 | ^ | ^ | 2757 | -------- | | 2758 | to_No_Response[2] | | 2759 | [!nResp_reached] tg_NSLPData[5] | | 2760 | || rx_Data[7] | | 2761 | -------- | | 2762 | | V | | 2763 | to_No_Response[2] | V | | 2764 | [nResp_reached] +-----------+ rx_Response[4] | | 2765 ---------- -----------| Awaiting |----------------- | 2766 | | | Refresh |<<------------------- 2767 | | +-----------+ to_Refresh_QNode[8] 2768 | | ^ | 2769 | | ^ | 2770 | | -------- 2771 | | to_No_Response[2] 2772 | | [!nResp_reached] 2773 V V 2774 V V 2775 +-----+ 2776 |Death|<<--------------- 2777 +-----+ to_Inactive_QNode[6] 2778 (from all states) 2780 Figure 6: Query Node State Machine 2782 The processing rules are as follows: 2784 Rule 1: Store the message for later transmission 2786 Rule 2: 2788 if number of Queries sent has reached the threshold 2789 // nQuery_isMax is true 2790 indicate No Response error to NSLP 2791 destroy self 2792 else 2793 send Query 2794 start No_Response timer with new value 2796 Rule 3: 2798 // Assume the Confirm was lost in transit so resend it 2799 // for the last Response we received 2800 send Confirm 2801 restart Refresh_QNode and Inactive_QNode timers 2803 Rule 4: 2805 if a new MA-SM is needed create one 2806 if the R flag was set send a Confirm 2807 pass any NSLP data to the NSLP 2808 send any stored Data messages 2809 stop No_Response timer 2810 start Refresh_QNode and Inactive_QNode timers 2812 Rule 5: 2814 send Data message 2815 restart Inactive_QNode timer 2817 Rule 6: Terminate 2819 Rule 7: 2821 pass any data to the NSLP 2822 (re)start Inactive_QNode timer 2824 Rule 8: 2826 send Query 2827 start No_Response timer 2828 stop Refresh_QNode timer 2830 6.3. Responder Node Processing 2832 The Responding-Node state machine (Responding-SM) has three states: 2834 o Awaiting Confirm 2835 o Established 2837 o Awaiting Refresh 2839 The policy governing the creation of the Responding-SM has three 2840 cases: 2842 1. It is created on receiving a Query, no Confirm is requested. 2844 2. It is created on receiving a Query, but a Confirm is requested. 2845 A timer is used to retransmit Response messages and the 2846 Responding-SM is destroyed if no valid Confirm is received. 2848 3. It cannot be created until a valid Confirm is received; the 2849 initial Query will have been handled by the Node level machine. 2851 In case 2 the Responding-SM is created in the Awaiting Confirm state, 2852 and remains there until a Confirm is received, at which point it 2853 transitions to Established. In cases 1 and 3 the Responding-SM is 2854 created directly in the Established state. Note that if the machine 2855 is created on receiving a Query, some of the message processing will 2856 already have been performed in the Node state machine. In the 2857 Established state the NSLP can send and receive data normally, and 2858 any additional rx_Confirm events MUST be silently ignored. The 2859 Awaiting Refresh state can be considered a substate of Established, 2860 where a Query has been received to begin the routing state refresh. 2862 In the Awaiting Refresh state the Responding-SM behaves as in the 2863 Awaiting Confirm state, except that the NSLP can still send and 2864 receive data. In particular, in both states there is timer-based 2865 retransmission of Response messages until a Confirm is received; 2866 additional rx_Query events in these states MUST also generate a 2867 response and restart the no_Confirm timer. 2869 The timers relevant to the operation of this state machine are as 2870 follows: 2872 Expire_RNode: Indicates when the routing state stored by this state 2873 machine needs to be expired. It is reset whenever a Query or 2874 Confirm (depending on local policy) is received indicating that 2875 the routing state is still valid. Note that state cannot be 2876 refreshed from the R-Node. 2878 No_Confirm: Indicates that a Confirm has not been received in answer 2879 to a Response. This is started/reset whenever a Response is sent 2880 and stopped when a Confirm is received. 2882 The detailed state transitions and processing rules are described 2883 below as in the Query node case. 2885 rx_Query[1] rx_Query[5] 2886 [confirmRequired] +-----+ [!confirmRequired] 2887 -------------------------|Birth|---------------------------- 2888 | +-----+ | 2889 | | rx_Confirm[2] | 2890 | ---------------------------- | 2891 | | | 2892 | rx_Query[5] | | 2893 | tg_NSLPData[7] [!confirmRequired] | | 2894 | || rx_Query[1] || rx_Data[4] | | 2895 | || rx_Data[6] || tg_NSLPData[3] | | 2896 | -------- -------------- | | 2897 | | V | V V V 2898 | | V | V V V 2899 | +----------+ | +-----------+ 2900 ---->>| Awaiting | rx_Confirm[8] -----------|Established| 2901 ------| Confirm |------------------------------>> | | 2902 | +----------+ +-----------+ 2903 | ^ | ^ | 2904 | ^ | tg_NSLPData[3] ^ | 2905 | -------- || rx_Query[1] | | 2906 | to_No_Confirm[9] || rx_Data[4] | | 2907 | [!nConf_reached] -------- | | 2908 | | V | | 2909 | to_No_Confirm[9] | V | | 2910 | [nConf_reached] +-----------+ rx_Confirm[8] | | 2911 ---------- ------------| Awaiting |----------------- | 2912 | | | Refresh |<<------------------- 2913 | | +-----------+ rx_Query[1] 2914 | | ^ | [confirmRequired] 2915 | | ^ | 2916 | | -------- 2917 V V to_No_Confirm[9] 2918 V V [!nConf_reached] 2919 +-----+ 2920 |Death|<<--------------------- 2921 +-----+ to_Expire_RNode[10] 2922 (from all states) 2924 Figure 7: Responder Node State Machine 2926 The processing rules are as follows: 2928 Rule 1: 2930 // a Confirm is required 2931 send Response 2932 (re)start No_Confirm timer 2934 Rule 2: 2936 pass any piggybacked data to the NSLP 2937 start Expire_RNode timer 2939 Rule 3: send the Data message 2941 Rule 4: pass data to NSLP 2943 Rule 5: 2945 // no Confirm is required 2946 send Response 2947 start Expire_RNode timer 2949 Rule 6: send "No Routing State" error message 2951 Rule 7: store Data message 2953 Rule 8: 2955 pass any piggybacked data to the NSLP 2956 send any stored Data messages 2957 stop No_Confirm timer 2958 start Expire_RNode timer 2960 Rule 9: 2962 if number of Responses sent has reached threshold 2963 // nResp_isMax is true 2964 destroy self 2965 else 2966 send Response 2967 start No_Response timer 2969 Rule 10: destroy self 2971 6.4. Messaging Association Processing 2973 Messaging associations (MAs) are modelled for use within GIST with a 2974 simple three-state process. The Awaiting Connection state indicates 2975 that the MA is waiting for the connection process(es) for every 2976 protocol in the messaging association to complete; this might involve 2977 creating listening endpoints or attempting active connects. Timers 2978 may also be necessary to detect connection failure (e.g. no incoming 2979 connection within a certain period), but these are not modelled 2980 explicitly. The Connected state indicates that the MA is open and 2981 ready to use. In addition there is an Idle state in which the local 2982 node no longer requires the messaging association but the remote node 2983 still wants it to be kept open. 2985 Clearly, many internal details of the messaging association protocols 2986 are hidden in this model, especially where the messaging association 2987 uses multiple protocol layers. Note also that although the existence 2988 of messaging associations is not directly visible to signaling 2989 applications, there is some interaction between the two because 2990 security-related information becomes available during the open 2991 process, and this may be indicated to signaling applications if they 2992 have requested it. 2994 The timers relevant to the operation of this state machine are as 2995 follows: 2997 SendHello: Indicates that an MA-Hello message should be sent to the 2998 remote node. The period of this timer is determined by the MA- 2999 Hold-Time sent by the remote node during the Query/Response/ 3000 Confirm exchange. 3002 NoHello: Indicates that no MA-Hello has been received from the remote 3003 node for a period of time. The period of this timer is sent to 3004 the remote node as the MA-Hold-Time during the Query/Response 3005 exchange. 3007 NoActivity: Indicates that the link has been inactive for a period of 3008 time. The period of this timer is implementation-specific but is 3009 likely to be related to the period of the NoHello timer. 3011 The detailed state transitions and processing rules are described 3012 below as in the Query node case. 3014 [Initialisation] +-----+ 3015 ----------------------------|Birth| 3016 | +-----+ 3017 | tg_RawData[1] 3018 | || rx_Message[2] 3019 | || rx_MA-Hello[3] 3020 | tg_RawData[5] || to_SendHello[4] 3021 | -------- -------- 3022 | | V | V 3023 | | V | V 3024 | +----------+ +-----------+ 3025 ---->>| Awaiting | tg_Connected[6] | Connected | 3026 ------|Connection|----------------------->>| | 3027 | +----------+ +-----------+ 3028 | ^ | 3029 | tg_RawData[1] ^ | 3030 | || rx_Message[2] | |to_NoActivity[7] 3031 | | V 3032 | | V 3033 | er_MAConnect[8] +-----+ to_NoHello[8] +-----------+ 3034 ---------------->>|Death|<<----------------| Idle | 3035 +-----+ | | 3036 ^ +-----------+ 3037 ^ ^ | 3038 | ^ | 3039 --------------- -------- 3040 er_MAFailure[8] rx_MA-Hello[3] 3041 (from all states) 3043 Figure 8: Messaging Association State Machine 3045 The processing rules are as follows: 3047 Rule 1: 3049 pass message to transport layer 3050 (re)start NoActivity timer 3051 (re)start SendHello 3053 Rule 2: 3055 pass message to Node-SM 3056 (re)start NoActivity timer 3057 Rule 3: 3059 if reply requested 3060 send MA-Hello 3061 restart SendHello timer 3063 Rule 4: 3065 send MA-Hello message 3066 restart NoHello timer 3068 Rule 5: queue message for later transmission 3070 Rule 6: 3072 pass outstanding queued messages to transport layer 3073 stop any timers controlling connection establishment 3074 start NoActivity timer 3075 start SendHello timer 3077 Rule 7: 3079 stop NoActivity timer 3080 stop sendHello timer 3081 start NoHello timer 3083 Rule 8: destroy self 3085 7. Advanced Protocol Features 3087 7.1. Route Changes and Local Repair 3089 7.1.1. Introduction 3091 When re-routing takes place in the network, GIST and signaling 3092 application state need to be updated for all flows whose paths have 3093 changed. The updates to signaling application state depend mainly on 3094 the signaling application: for example, if the path characteristics 3095 have actually changed, simply moving state from the old to the new 3096 path is not sufficient. Therefore, GIST cannot carry out the 3097 complete path update processing. Its responsibilities are to detect 3098 the route change, update its local routing state consistently, and 3099 inform interested signaling applications at affected nodes. 3101 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 3102 x +--+ +--+ +--+ x Initial 3103 x .|C1|_.....|D1|_.....|E1| x Configuration 3104 x . +--+. .+--+. .+--+\. x 3105 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 3106 +-+ +-+ . .. .. . +-+ 3107 ...|A|_......|B|/ .. .. .|F|_.... 3108 +-+ +-+ . . . . . . +-+ 3109 . . . . . . 3110 . +--+ +--+ +--+ . 3111 .|C2|_.....|D2|_.....|E2|/ 3112 +--+ +--+ +--+ 3114 +--+ +--+ +--+ Configuration 3115 .|C1|......|D1|......|E1| after failure 3116 . +--+ .+--+ +--+ of E1-F link 3117 . \. . \. ./ 3118 +-+ +-+ . .. .. +-+ 3119 ...|A|_......|B|. .. .. .|F|_.... 3120 +-+ +-+\ . . . . . +-+ 3121 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 3122 x . +--+ +--+ +--+ . x 3123 x .|C2|_.....|D2|_.....|E2|/ x 3124 x +--+ +--+ +--+ x 3125 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 3127 ........... = physical link topology 3128 >>xxxxxxx>> = flow direction 3129 _.......... = outgoing link for flow xxxxxx given 3130 by local forwarding table 3132 Figure 9: A Re-Routing Event 3133 Route change management is complicated by the distributed nature of 3134 the problem. Consider the re-routing event shown in Figure 9. An 3135 external observer can tell that the main responsibility for 3136 controlling the updates will probably lie with nodes B and F; 3137 however, E1 is best placed to detect the event quickly at the GIST 3138 level, and C1 and D1 could also attempt to initiate the repair. 3140 On the assumption that signaling applications are soft-state based 3141 and operate end to end, and because GIST also periodically updates 3142 its picture of routing state, route changes will eventually be 3143 repaired automatically. The specification as already given includes 3144 this functionality. However, especially if upper layer refresh times 3145 are extended to reduce signaling load, the duration of inconsistent 3146 state may be very long indeed. Therefore, GIST includes logic to 3147 exchange prompt notifications with signaling applications, to allow 3148 local repair if possible. The additional mechanisms to achieve this 3149 are described in the following subsections. To a large extent, these 3150 additions can be seen as implementation issues; the protocol messages 3151 and their significance are not changed, but there are extra 3152 interactions through the API between GIST and signaling applications, 3153 and additional triggers for transitions between the various GIST 3154 states. 3156 7.1.2. Route Change Detection Mechanisms 3158 There are two aspects to detecting a route change at a single node: 3160 o Detecting that the outgoing path, in the direction of the Query, 3161 has or may have changed. 3163 o Detecting that the incoming path, in the direction of the 3164 Response, has (or may have) changed, in which case the node may no 3165 longer be on the path at all. 3167 At a single node, these processes are largely independent, although 3168 clearly a change in one direction at a node corresponds to a change 3169 the opposite direction at its peer. Note that there are two possible 3170 forms for a route change: the interface through which a flow leaves 3171 or enters a node may change, and the adjacent peer may change. In 3172 general, a route change can include one or the other or both (or 3173 indeed neither, although such changes are very hard to detect). 3175 The route change detection mechanisms available to a node depend on 3176 the MRM in use and the role the node played in setting up the routing 3177 state in the first place (i.e. as Querying or Responding node). The 3178 following discussion is specific to the case of the path-coupled MRM 3179 using downstream Queries only; other scenarios may require other 3180 methods. However, the repair logic described in the subsequent 3181 subsections is intended to be universal. 3183 There are five mechanisms for a node to detect that a route change 3184 has occurred, which are listed below. They apply differently 3185 depending on whether the change is in the Query or Response 3186 direction, and these differences are summarised in the following 3187 table. 3189 Local Trigger: In local trigger mode, GIST finds out from the local 3190 forwarding table that the next hop has changed. This only works 3191 if the routing change is local, not if it happens a few routing 3192 hops away, including the case that it happens at a GIST-unaware 3193 node. 3195 Extended Trigger: Here, GIST checks a link-state topology database to 3196 discover that the path has changed. This makes certain 3197 assumptions on consistency of route computation and only works 3198 within a single area for OSPF [13] and similar link-state 3199 protocols. Where available, this offers the most accurate and 3200 rapid indication of route changes, but requires more access to the 3201 routing internals than a typical operating system may provide. 3203 GIST C-mode Monitoring: GIST may find that C-mode packets are 3204 arriving (from either peer) with a different IP layer TTL or on a 3205 different interface. This provides no direct information about 3206 the new flow path, but indicates that routing has changed and that 3207 rediscovery may be required. 3209 Data Plane Monitoring: The signaling application on a node may detect 3210 a change in behaviour of the flow, such as IP layer TTL change, 3211 arrival on a different interface, or loss of the flow altogether. 3212 The signaling application on the node is allowed to notify this 3213 information locally to GIST (Appendix B.6). 3215 GIST Probing: According to the specification, each GIST node MUST 3216 periodically repeat the discovery (Query/Response) operation. 3217 Values for the probe frequency are discussed in Section 4.4.3. 3218 The querying node will discover the route change by a modification 3219 in the Network-Layer-Information in the Response. The period can 3220 be negotiated independently for each GIST hop, so nodes that have 3221 access to the other techniques listed above MAY use long periods 3222 for the probing operation. 3224 +------------+--------------------------+---------------------------+ 3225 | Method | Query direction | Response direction | 3226 +------------+--------------------------+---------------------------+ 3227 | Local | Discovers new interface | Not applicable | 3228 | Trigger | (and peer if local) | | 3229 | | | | 3230 | Extended | Discovers new interface | May determine that route | 3231 | Trigger | and may determine new | from peer will have | 3232 | | peer | changed | 3233 | | | | 3234 | C-mode | Provides hint that | Provides hint that change | 3235 | Monitoring | change has occurred | has occurred | 3236 | | | | 3237 | Data Plane | Not applicable | NSLP informs GIST that a | 3238 | Monitoring | | change may have occurred | 3239 | | | | 3240 | Probing | Discovers changed NLI in | Discovers changed NLI in | 3241 | | Response | Query | 3242 +------------+--------------------------+---------------------------+ 3244 7.1.3. GIST Behaviour Supporting Re-Routing 3246 The GIST behaviour necessary to support re-routing can be modelled 3247 using a 3-level classification of the validity of each item of 3248 routing state. (This classification applies separately to the 3249 Querying and Responding node for each pair of GIST peers.) The 3250 levels are: 3252 Bad: The routing state is either missing altogether, or not safe to 3253 use to send data. 3255 Tentative: The routing state may have changed, but it is still usable 3256 for sending NSLP data pending verification. 3258 Good: The routing state has been established and no events affecting 3259 it have since been detected. 3261 These classifications are not identical to the states described in 3262 Section 6, but there are dependencies between them. Specifically, 3263 routing state is considered Bad until the machine first enters the 3264 Established state, at which point it becomes Good. Thereafter, the 3265 status may be invalidated for any of the reasons discussed above; it 3266 is an implementation issue to decide which techniques to implement in 3267 any given node, and how to reclassify routing state (as Bad or 3268 Tentative) for each. The status returns to Good, either when the 3269 state machine re-enters the Established state, or if GIST can 3270 determine from direct examination of the routing or forwarding tables 3271 that the peer has not changed. When the status returns to Good, GIST 3272 MUST if necessary update its routing state table so that the 3273 relationships between MRI/SID/NSLPID tuples and messaging 3274 associations are up to date. 3276 When classification of the routing state for the downstream direction 3277 changes to Bad/Tentative because of local routing indications, GIST 3278 MAY automatically change the classification in the upstream direction 3279 to Tentative unless local routing indicates that this is not 3280 necessary. This SHOULD NOT be done in the case where the initial 3281 change was indicated by the signaling application. This mechanism 3282 accounts for the fact that a routing change may affect several nodes, 3283 and so can be an indication that upstream routing may also have 3284 changed. In any case, whenever GIST updates the routing status, it 3285 informs the signaling application with the NetworkNotification API 3286 (Appendix B.4), unless the change was caused via the API in the first 3287 place. 3289 The GIST behaviour for state repair is different for the Querying and 3290 Responding node. At the Responding node, there is no additional 3291 behaviour, since the Responding node cannot initiate protocol 3292 transitions autonomously, it can only react to the Querying node. 3293 The Querying node has three options, depending on how the transition 3294 from 'Good' was initially caused: 3296 1. To inspect the routing/forwarding table and verifying that the 3297 next peer has not changed. This technique MUST NOT be used if 3298 the transition was caused by a signaling application, but SHOULD 3299 be used otherwise if available. 3301 2. To move to the 'Awaiting Refresh' state. This technique MUST NOT 3302 be used if the current status is 'Bad', since data is being 3303 incorrectly delivered. 3305 3. To move to the 'Awaiting Response' state. This technique may be 3306 used at any time, but has the effect of freezing NSLP 3307 communication while GIST state is being repaired. 3309 The second and third techniques trigger the execution of a GIST 3310 handshake to carry out the repair. It may be desirable to delay the 3311 start of the handshake process, either to wait for the network to 3312 stabilise, to avoid flooding the network with Query traffic for a 3313 large number of affected flows, or to wait for confirmation that the 3314 node is still on the path from the upstream peer. One approach is to 3315 delay the handshake until there is NSLP data to be transmitted. 3316 Implementation of such delays is a matter of local policy; however, 3317 GIST MUST begin the handshake immediately if the status change was 3318 caused by an InvalidateRoutingState API call marked as 'Urgent', and 3319 SHOULD begin it if the upstream routing state is still known to be 3320 Good. 3322 7.1.4. Signaling Application Operation 3324 Signaling applications can use these functions as provided by GIST to 3325 carry out rapid local repair following re-routing events. The 3326 signaling application instances carry out the multi-hop aspects of 3327 the procedure, including crossover node detection, and tear-down/ 3328 reinstallation of signaling application state; they also trigger GIST 3329 to carry out the local routing state maintenance operations over each 3330 individual hop. The local repair procedures depend heavily on the 3331 fact that stateful NSLP nodes are a single GIST hop apart; this is 3332 enforced by the details of the GIST peer discovery process. 3334 The following outline description of a possible set of NSLP actions 3335 takes the scenario of Figure 9 as an example. 3337 1. The signaling application at node E1 is notified by GIST of route 3338 changes affecting the downstream and upstream directions. The 3339 downstream status was updated to Bad because of a trigger from 3340 the local forwarding tables, and the upstream status changed 3341 automatically to Tentative as a consequence. The signaling 3342 application at E1 MAY begin local repair immediately, or MAY 3343 propagate a notification upstream to D1 that re-routing has 3344 occurred. 3346 2. The signaling application at node D1 is notified of the route 3347 change, either by signaling application notifications or from the 3348 GIST level (e.g. by a trigger from a link-state topology 3349 database). If the information propagates faster within the 3350 routing protocol, GIST will change the upstream/downstream 3351 routing state to Tentative/Bad automatically, and this will cause 3352 the signaling application to propagate the notification further 3353 upstream. 3355 3. This process continues until the notification reaches node A. 3356 Here, there is no downstream routing change, so GIST only learns 3357 of the update via the signaling application trigger. Since the 3358 upstream status is still Good, it therefore begins the repair 3359 handshake immediately. 3361 4. The handshake initiated by node A causes its downstream routing 3362 state to be confirmed as Good and unchanged there; it also 3363 confirms the (Tentative) upstream routing state at B as Good. 3364 This is enough to identify B as the crossover router, and the 3365 signaling application and GIST can begin the local repair 3366 process. 3368 An alternative way to reach step (4) is that node B is able to 3369 determine autonomously that there is no likelihood of an upstream 3370 route change. For example, it could be an area border router and the 3371 route change is only intra-area. In this case, the signaling 3372 application and GIST will see that the upstream state is Good and can 3373 begin the local repair directly. 3375 After a route change, a signaling application may wish to remove 3376 state at another node which is no longer on the path. However, since 3377 it is no longer on the path, in principle GIST can no longer send 3378 messages to it. In general, provided this state is soft, it will 3379 time out anyway; however, the timeouts involved may have been set to 3380 be very long to reduce signaling load. The requirement to remove 3381 state in a specific peer node is identified in [33]. 3383 This requirement can be met provided that GIST is able to use the old 3384 path to the signaling application peer for some period while the 3385 signaling application still needs it. Since NSLP peers are a single 3386 GIST hop apart, the necessary information is just the old entry in 3387 the node's routing state table for that flow. Rather than requiring 3388 GIST to maintain multiple generations of this information, it can 3389 just be provided to the signaling application in the same node in an 3390 opaque form for each message that is received. The signaling 3391 application can store it if necessary and provide it back to the GIST 3392 layer in case it needs to be used. Because this is a reference to 3393 information about the source of a prior signaling message, it is 3394 denoted 'SII-Handle' (for Source Identification Information) in the 3395 abstract API of Appendix B. Note that GIST if possible SHOULD use 3396 the same SII-Handle for multiple sessions to the same peer, since 3397 this then allows signaling applications to aggregate some signaling, 3398 such as summary refreshes or bulk teardowns. 3400 Messages sent this way MUST bypass the GIST routing state tables at 3401 the sender, and this is indicated by setting the E flag in the common 3402 header (Appendix A.1); at the receiver, GIST MUST NOT validate the 3403 MRI/SID/NSLPID against local routing state and instead indicates the 3404 mode of reception to signaling applications through the API 3405 (Appendix B.2). Signaling applications should validate the source 3406 and effect of the message themselves, and if appropriate should in 3407 particular indicate to GIST (see Appendix B.5) that routing state is 3408 no longer required for this flow. This is necessary to prevent GIST 3409 in nodes on the old path initiating routing state refresh and thus 3410 causing state conflicts at the crossover router. 3412 7.2. NAT Traversal 3413 7.2.1. Overview 3415 GIST messages must carry packet addressing and higher layer 3416 information as payload data in order to define the flow signalled 3417 for. (This applies to all GIST messages, regardless of how they are 3418 encapsulated or which direction they are travelling in.) At an 3419 addressing boundary the data flow packets will have their headers 3420 translated; if the signaling payloads are not translated 3421 consistently, the signaling messages will refer to incorrect (and 3422 probably meaningless) flows after passing through the boundary. In 3423 addition, GIST handshake messages carry additional addressing 3424 information about the GIST nodes themselves, and this must also be 3425 processed appropriately when traversing a NAT. 3427 The simplest solution to this problem is to require that a NAT is 3428 GIST-aware, and to allow it to modify messages based on the contents 3429 of the MRI. This makes the assumption that NATs only rewrite the 3430 header fields included in this payload, and not other higher layer 3431 identifiers. Provided this is done consistently with the data flow 3432 header translation, signaling messages will be valid each side of the 3433 boundary, without requiring the NAT to be signaling application 3434 aware. Note, however, that if the NAT does not understand the MRI, 3435 and the N-flag in the MRI is clear (see Appendix A.3.1), it should 3436 reject the message with an "Object Type Error" message 3437 (Appendix A.4.4.9) with subcode 4 ("Untranslated Object"). 3439 This specification defines an additional object that a NAT can insert 3440 into Q-mode encapsulated messages and which is echoed back in any 3441 replies, i.e. Response or Error messages. NATs apply GIST-specific 3442 processing only to Q-mode encapsulated messages or replies carrying 3443 the NAT traversal object. All other GIST messages, either in C-mode, 3444 or D-mode messages with no NAT-Traversal object, should be treated as 3445 normal data traffic by the NAT, i.e. with IP and transport layer 3446 header translation but no GIST-specific processing. 3448 The new object, the NAT-Traversal object (Appendix A.3.8), carries 3449 the translation between the MRIs which are appropriate for the 3450 internal and external sides of the NAT. It also carries a list of 3451 which other objects in the message have been translated. This should 3452 always include the NLI, and the Stack-Configuration-Data if present; 3453 if GIST is extended with further objects that carry addressing data, 3454 this list allows a message receiver to know if the new objects were 3455 supported by the NAT. Finally, the NAT-Traversal object MAY be used 3456 to carry data to be used in back-translating D-mode responses; this 3457 could be the original NLI or SCD, or opaque equivalents in the case 3458 of topology hiding. 3460 A consequence of this approach is that the routing state tables at 3461 the signaling application peers each side of the NAT are no longer 3462 directly compatible. In particular, the values for Message-Routing- 3463 Information are different, which is why the unmodified MRI is 3464 propagated in the NAT-Traversal object to allow subsequent C-mode 3465 messages to be interpreted correctly. 3467 7.2.2. Message Processing Rules 3469 This specification normatively defines the behaviour of a GIST node 3470 receiving a message containing a NAT-Traversal object. However, it 3471 does not define normative behaviour for a NAT translating GIST 3472 messages, since much of this will depend on NAT implementation and 3473 policy about allocating bindings. In addition, it is not necessary 3474 for a GIST implementation itself. Therefore, those aspects of the 3475 following description are informative; full details of NAT behaviour 3476 for handling GIST messages can be found in [40]. 3478 A possible set of operations for a NAT to process a Q-mode 3479 encapsulated message is as follows: 3481 1. Verify that bindings for any data flow are actually in place. 3483 2. Create a new Message-Routing-Information object with fields 3484 modified according to the data flow bindings. 3486 3. Create bindings for subsequent C-mode signaling based on the 3487 information in the Network-Layer-Information and Stack- 3488 Configuration-Data objects. 3490 4. Create new Network-Layer-Information and if necessary Stack- 3491 Configuration-Data objects with fields to force D-mode response 3492 messages through the NAT, and to allow C-mode exchanges using the 3493 C-mode signaling bindings. 3495 5. Add a NAT-Traversal object, listing the objects which have been 3496 modified and including the unmodified MRI and any other data 3497 needed to interpret the response. If a NAT-Traversal object is 3498 already present, in the case of a sequence of NATs, the list of 3499 modified objects may be updated and further opaque data added, 3500 but the MRI contained in it is left unchanged. 3502 6. Encapsulate the message according to the normal rules of this 3503 specification for the Q-mode encapsulation. If the S-flag was 3504 set in the original message, the same IP source address selection 3505 policy should be applied to the forwarded message. 3507 7. Forward the message with these new payloads. 3509 A GIST node receiving such a message MUST verify that all mandatory 3510 objects containing addressing have been translated correctly, or else 3511 reject the message with an "Object Type Error" message 3512 (Appendix A.4.4.9) with subcode 4 ("Untranslated Object"). The error 3513 message MUST include the NAT-Traversal object as the first TLV after 3514 the common header, and this is also true for any other error message 3515 generated as a response. Otherwise, the message is processed 3516 essentially as normal. If no state needs to be updated for the 3517 message, the NAT-Traversal object can be effectively ignored. The 3518 other possibility is that a Response must be returned, either because 3519 the message is the beginning of a handshake for a new flow, or it is 3520 a refresh for existing state. In both cases, the GIST node MUST 3521 create the Response in the normal way using the local form of the 3522 MRI, and its own NLI and (if necessary) SCD. It MUST also include 3523 the NAT-Traversal object as the first object in the Response after 3524 the common header. 3526 A NAT will intercept D-mode messages with the normal encapsulation 3527 containing such echoed NAT-Traversal objects. The NAT processing is 3528 a subset of the processing for the Q-mode encapsulated case: 3530 1. Verify the existence of bindings for the data flow. 3532 2. Leave the Message-Routing-Information object unchanged. 3534 3. Modify the NLI and SCD objects for the Responding node if 3535 necessary, and create or update any bindings for C-mode signaling 3536 traffic. 3538 4. Forward the message. 3540 A GIST node receiving such a message MUST use the MRI from the NAT- 3541 Traversal object as the key to index its internal routing state; it 3542 MAY also store the translated MRI for additional (e.g. diagnostic) 3543 information, but this is not used in the GIST processing. The 3544 remainder of GIST processing is unchanged. 3546 Note that Confirm messages are not given GIST-specific processing by 3547 the NAT. Thus, a Responding node which has delayed state 3548 installation until receiving the Confirm, only has available the 3549 untranslated MRI describing the flow, and the untranslated NLI as 3550 peer routing state. This would prevent the correct interpretation of 3551 the signaling messages; also, subsequent Query (refresh) messages 3552 would always be seen as route changes because of the NLI change. 3553 Therefore, a Responding node that wishes to delay state installation 3554 until receiving a Confirm must somehow reconstruct the translations 3555 when the Confirm arrives. How to do this is an implementation issue; 3556 one approach is to carry the translated objects as part of the 3557 Responder cookie which is echoed in the Confirm. Indeed, for one of 3558 the cookie constructions in Section 8.5 this is automatic. 3560 7.3. Interaction with IP Tunnelling 3562 The interaction between GIST and IP tunnelling is very simple. An IP 3563 packet carrying a GIST message is treated exactly the same as any 3564 other packet with the same source and destination addresses: in other 3565 words, it is given the tunnel encapsulation and forwarded with the 3566 other data packets. 3568 Tunnelled packets will not be identifiable as GIST messages until 3569 they leave the tunnel, since any router alert option and the standard 3570 GIST protocol encapsulation (e.g. port numbers) will be hidden within 3571 the standard tunnel encapsulation. If signaling is needed for the 3572 tunnel itself, this has to be initiated as a separate signaling 3573 session by one of the tunnel endpoints - that is, the tunnel counts 3574 as a new flow. Because the relationship between signaling for the 3575 microflow and signaling for the tunnel as a whole will depend on the 3576 signaling application in question, it is a signaling application 3577 responsibility to be aware of the fact that tunnelling is taking 3578 place and to carry out additional signaling if necessary; in other 3579 words, at least one tunnel endpoint must be signaling application 3580 aware. 3582 In some cases, it is the tunnel exit point (i.e. the node where 3583 tunnelled data and downstream signaling packets leave the tunnel) 3584 that will wish to carry out the tunnel signaling, but this node will 3585 not have knowledge or control of how the tunnel entry point is 3586 carrying out the data flow encapsulation. The information about how 3587 the inner MRI/SID relate to the tunnel MRI/SID needs to be carried in 3588 the signaling data from the tunnel entry point; this functionality is 3589 the equivalent to the RSVP SESSION_ASSOC object of [14]. In the NSIS 3590 protocol suite, these bindings are managed by the signaling 3591 applications, either implicitly (e.g. by SID re-use) or explicitly by 3592 carrying objects that bind the inner and outer SIDs as part of the 3593 NSLP payload. 3595 7.4. IPv4-IPv6 Transition and Interworking 3597 GIST itself is essentially IP version neutral: version dependencies 3598 are isolated in the formats of the Message-Routing-Information, 3599 Network-Layer-Information and Stack-Configuration-Data objects, and 3600 GIST also depends on the version independence of the protocols that 3601 support messaging associations. In mixed environments, GIST 3602 operation will be influenced by the IP transition mechanisms in use. 3603 This section provides a high level overview of how GIST is affected, 3604 considering only the currently predominant mechanisms. 3606 Dual Stack: (As described in [34].) In mixed environments, GIST MUST 3607 use the same IP version for Q-mode encapsulated messages as the 3608 flow it is signaling for, and SHOULD do so for other signaling 3609 also (see Section 5.2.2). The IP version used in D-mode is 3610 closely tied to the IP version used by the data flow, so it is 3611 intrinsically impossible for an IPv4-only or IPv6-only GIST node 3612 to support signaling for flows using the other IP version. Hosts 3613 which are dual stack for applications and routers which are dual 3614 stack for forwarding need GIST implementations which can support 3615 both IP versions. Applications with a choice of IP versions might 3616 select a version based on which could be supported in the network 3617 by GIST, which could be established by invoking parallel discovery 3618 procedures. 3620 Packet Translation: (Applicable to SIIT [6] and NAT-PT [15].) Some 3621 transition mechanisms allow IPv4 and IPv6 nodes to communicate by 3622 placing packet translators between them. From the GIST 3623 perspective, this should be treated essentially the same way as 3624 any other NAT operation (e.g. between internal and external 3625 addresses) as described in Section 7.2. The translating node 3626 needs to be GIST-aware; it will have to translate the addressing 3627 payloads between IPv4 and IPv6 formats for flows which cross 3628 between the two. The translation rules for the fields in the MRI 3629 payload (including e.g. DiffServ-codepoint and flow-label) are as 3630 defined in [6]. 3632 Tunnelling: (Applicable to 6to4 [17].) Many transition mechanisms 3633 handle the problem of how an end to end IPv6 (or IPv4) flow can be 3634 carried over intermediate IPv4 (or IPv6) regions by tunnelling; 3635 the methods tend to focus on minimising the tunnel administration 3636 overhead. 3638 From the GIST perspective, the treatment should be as similar as 3639 possible to any other IP tunnelling mechanism, as described in 3640 Section 7.3. In particular, the end to end flow signaling will 3641 pass transparently through the tunnel, and signaling for the 3642 tunnel itself will have to be managed by the tunnel endpoints. 3643 However, additional considerations may arise because of special 3644 features of the tunnel management procedures. In particular, [18] 3645 is based on using an anycast address as the destination tunnel 3646 endpoint. GIST MAY use anycast destination addresses in the 3647 Q-mode encapsulation of D-mode messages if necessary, but MUST NOT 3648 use them in the Network-Layer-Information addressing field; normal 3649 unicast addresses MUST be used instead. Note that the addresses 3650 from the IP header are not used by GIST in matching requests and 3651 responses, so there is no requirement to use anycast source 3652 addresses. 3654 8. Security Considerations 3656 The security requirement for GIST is to protect the signaling plane 3657 against identified security threats. For the signaling problem as a 3658 whole, these threats have been outlined in [27]; the NSIS framework 3659 [26] assigns a subset of the responsibilities to the NTLP. The main 3660 issues to be handled can be summarised as: 3662 Message Protection: Signaling message content can be protected 3663 against eavesdropping, modification, injection and replay while in 3664 transit. This applies both to GIST payloads, and GIST should also 3665 provide such protection as a service to signaling applications 3666 between adjacent peers. 3668 Routing State Integrity Protection: It is important that signaling 3669 messages are delivered to the correct nodes, and nowhere else. 3670 Here, 'correct' is defined as 'the appropriate nodes for the 3671 signaling given the Message-Routing-Information'. In the case 3672 where the MRI is based on the Flow Identification for path-coupled 3673 signaling, 'appropriate' means 'the same nodes that the 3674 infrastructure will route data flow packets through'. GIST has no 3675 role in deciding whether the data flow itself is being routed 3676 correctly; all it can do is ensure the signaling is routed 3677 consistently with it. GIST uses internal state to decide how to 3678 route signaling messages, and this state needs to be protected 3679 against corruption. 3681 Prevention of Denial of Service Attacks: GIST nodes and the network 3682 have finite resources (state storage, processing power, 3683 bandwidth). The protocol tries to minimise exhaustion attacks 3684 against these resources and not allow GIST nodes to be used to 3685 launch attacks on other network elements. 3687 The main additional issue is handling authorisation for executing 3688 signaling operations (e.g. allocating resources). This is assumed to 3689 be done in each signaling application. 3691 In many cases, GIST relies on the security mechanisms available in 3692 messaging associations to handle these issues, rather than 3693 introducing new security measures. Obviously, this requires the 3694 interaction of these mechanisms with the rest of the GIST protocol to 3695 be understood and verified, and some aspects of this are discussed in 3696 Section 5.7. 3698 8.1. Message Confidentiality and Integrity 3700 GIST can use messaging association functionality, specifically in 3701 this version TLS (Section 5.7.3), to ensure message confidentiality 3702 and integrity. Implementation of this functionality is REQUIRED but 3703 its use for any given flow or signaling application is OPTIONAL. In 3704 some cases, confidentiality of GIST information itself is not likely 3705 to be a prime concern, in particular since messages are often sent to 3706 parties which are unknown ahead of time, although the content visible 3707 even at the GIST level gives significant opportunities for traffic 3708 analysis. Signaling applications may have their own mechanism for 3709 securing content as necessary; however, they may find it convenient 3710 to rely on protection provided by messaging associations, since it 3711 runs unbroken between signaling application peers. 3713 8.2. Peer Node Authentication 3715 Cryptographic protection (of confidentiality or integrity) requires a 3716 security association with session keys. These can be established by 3717 an authentication and key exchange protocol based on shared secrets, 3718 public key techniques or a combination of both. Authentication and 3719 key agreement is possible using the protocols associated with the 3720 messaging association being secured. TLS incorporates this 3721 functionality directly; IKE, IKEv2 or KINK could provide it for 3722 IPsec. GIST nodes rely on these protocols to authenticate the 3723 identity of the next hop, and GIST has no authentication capability 3724 of its own. 3726 With routing state discovery, there are few effective ways to know 3727 what is the legitimate next or previous hop as opposed to an 3728 impostor. In other words, cryptographic authentication here only 3729 provides assurance that a node is 'who' it is (i.e. the legitimate 3730 owner of identity in some namespace), not 'what' it is (i.e. a node 3731 which is genuinely on the flow path and therefore can carry out 3732 signaling for a particular flow). Authentication provides only 3733 limited protection, in that a known peer is unlikely to lie about its 3734 role. Additional methods of protection against this type of attack 3735 are considered in Section 8.3 below. 3737 It is an implementation issue whether peer node authentication should 3738 be made signaling application dependent; for example, whether 3739 successful authentication could be made dependent on presenting 3740 credentials related to a particular signaling role (e.g. signaling 3741 for QoS). The abstract API of Appendix B leaves open such policy and 3742 authentication interactions between GIST and the NSLP it is serving. 3743 However, it does allow applications to inspect the authenticated 3744 identity of the peer to which a message will be sent before 3745 transmission. 3747 8.3. Routing State Integrity 3749 Internal state in a node (see Section 4.2) is used to route messages. 3751 If this state is corrupted, signaling messages may be misdirected. 3753 In the case where the MRM is path-coupled, the messages need to be 3754 routed identically to the data flow described by the MRI, and the 3755 routing state table is the GIST view of how these flows are being 3756 routed through the network in the immediate neighbourhood of the 3757 node. Routes are only weakly secured (e.g. there is no cryptographic 3758 binding of a flow to a route), and there is no authoritative 3759 information about flow routes other than the current state of the 3760 network itself. Therefore, consistency between GIST and network 3761 routing state has to be ensured by directly interacting with the 3762 routing mechanisms to ensure that the signaling peers are the 3763 appropriate ones for any given flow. An overview of security issues 3764 and techniques in this context is provided in [38]. 3766 In one direction, peer identification is installed and refreshed only 3767 on receiving a Response (compare Figure 4). This MUST echo the 3768 cookie from a previous Query, which will have been sent along the 3769 flow path with the Q-mode encapsulation, i.e. end-to-end addressed. 3770 Hence, only the true next peer or an on-path attacker will be able to 3771 generate such a message, provided freshness of the cookie can be 3772 checked at the querying node. 3774 In the other direction, peer identification MAY be installed directly 3775 on receiving a Query containing addressing information for the 3776 signaling source. However, any node in the network could generate 3777 such a message; indeed, many nodes in the network could be the 3778 genuine upstream peer for a given flow. To protect against this, 3779 three strategies are used: 3781 Filtering: the receiving node MAY reject signaling messages which 3782 claim to be for flows with flow source addresses which could be 3783 ruled out by ingress filtering. An extension of this technique 3784 would be for the receiving node to monitor the data plane and to 3785 check explicitly that the flow packets are arriving over the same 3786 interface and if possible from the same link layer neighbour as 3787 the D-mode signaling packets. If they are not, it is likely that 3788 at least one of the signaling or flow packets is being spoofed. 3790 Authentication (weak or strong): the receiving node MAY refuse to 3791 install upstream state until it has completed a Confirm handshake 3792 with the peer. This echoes the Response cookie of the Response, 3793 and discourages nodes from using forged source addresses. This 3794 also plays a role in denial of service prevention, see below. A 3795 stronger approach is to require full peer authentication within 3796 the messaging association, the reasoning being that an 3797 authenticated peer can be trusted not to pretend that it is on 3798 path when it is not. 3800 SID segregation: The routing state lookup for a given MRI and NSLPID 3801 MUST also take the SID into account. A malicious node can only 3802 overwrite existing routing state if it can guess the corresponding 3803 SID; it can insert state with random SID values, but generally 3804 this will not be used to route messages for which state has 3805 already been legitimately established. 3807 8.4. Denial of Service Prevention 3809 GIST is designed so that in general each Query only generates at most 3810 one Response, so that a GIST node cannot become the source of a 3811 denial of service amplification attack. (There is a special case of 3812 retransmitted Response messages, see Section 5.3.3.) 3814 However, GIST can still be subjected to denial-of-service attacks 3815 where an attacker using forged source addresses forces a node to 3816 establish state without return routability, causing a problem similar 3817 to TCP SYN flood attacks. Furthermore, an adversary might use 3818 modified or replayed unprotected signaling messages as part of such 3819 an attack. There are two types of state attacks and one 3820 computational resource attack. In the first state attack, an 3821 attacker floods a node with messages that the node has to store until 3822 it can determine the next hop. If the destination address is chosen 3823 so that there is no GIST-capable next hop, the node would accumulate 3824 messages for several seconds until the discovery retransmission 3825 attempt times out. The second type of state-based attack causes GIST 3826 state to be established by bogus messages. A related computational/ 3827 network-resource attack uses unverified messages to cause a node 3828 query an authentication or authorisation infrastructure, or attempt 3829 to cryptographically verify a digital signature. 3831 We use a combination of two defences against these attacks: 3833 1. The responding node need not establish a session or discover its 3834 next hop on receiving the Query, but MAY wait for a Confirm, 3835 possibly on a secure channel. If the channel exists, the 3836 additional delay is one one-way delay and the total is no more 3837 than the minimal theoretically possible delay of a three-way 3838 handshake, i.e., 1.5 node-to-node round-trip times. The delay 3839 gets significantly larger if a new connection needs to be 3840 established first. 3842 2. The Response to the Query contains a cookie, which is repeated in 3843 the Confirm. State is only established for messages that contain 3844 a valid cookie. The setup delay is also 1.5 round-trip times. 3845 This mechanism is similar to that in SCTP [16] and other modern 3846 protocols. 3848 Once a node has decided to establish routing state, there may still 3849 be transport and security state to be established between peers. 3850 This state setup is also vulnerable to denial of service attacks. 3851 GIST relies on the lower layer protocols that make up messaging 3852 associations to mitigate such attacks. In the current specification, 3853 the querying node is always the one wishing to establish a messaging 3854 association, so it is the responding node that needs to be protected. 3856 Signaling applications can use the services provided by GIST to 3857 defend against certain (e.g. flooding) denial of service attacks. In 3858 particular, they can elect to process only messages from peers that 3859 have passed a return routability check or been authenticated at the 3860 messaging association level (see Appendix B.2). Signaling 3861 applications that accept messages under other circumstances (in 3862 particular, before routing state has been fully established at the 3863 GIST level) need to take this into account when designing their 3864 denial of service prevention mechanisms, for example by not creating 3865 local state as a result of processing such messages. 3867 8.5. Requirements on Cookie Mechanisms 3869 The requirements on the Query cookie can be summarised as follows: 3871 Liveness: The cookie must be live, that is, it must change from one 3872 handshake to the next. To prevent replay attacks. 3874 Unpredictability: The cookie must not be guessable e.g. from a 3875 sequence or timestamp. To prevent direct forgery based on seeing 3876 a history of captured messages. 3878 Easily validated: It must be efficient for the Q-Node to validate 3879 that a particular cookie matches an in-progress handshake, for a 3880 routing state machine which already exists. To discard spoofed 3881 responses, or responses to spoofed queries. 3883 Uniqueness: The cookie must be unique to a given handshake since it 3884 is actually used to match the Response to a handshake anyway, e.g. 3885 during messaging association re-use. 3887 Likewise, the requirements on the Responder cookie can be summarised 3888 as follows: 3890 Liveness: The cookie must be live as above. To prevent replay 3891 attacks. 3893 Creation simplicity: The cookie must be lightweight to generate. To 3894 avoid resource exhaustion at the responding node. 3896 Validation simplicity: It must be simple for the R-node to validate 3897 that an R-cookie was generated by itself and no-one else, without 3898 storing state about the handshake it was generated for. 3900 Binding: The cookie must be bound to the routing state that will be 3901 installed. To prevent use with different routing state e.g. in a 3902 modified Confirm. The routing state here includes the NLI of the 3903 Query, the MRI/NSLPID for the messaging, and the interface on 3904 which the Query was received. 3906 A suitable implementation for the Q-Cookie is a cryptographically 3907 strong random number which is unique for this routing state machine 3908 handshake. A node MUST implement this or an equivalently strong 3909 mechanism. Guidance on random number generation can be found in 3910 [28]. 3912 A suitable implementation for the R-Cookie is as follows: 3914 R-Cookie = liveness data + hash (locally known secret, 3915 Q-Node NLI, MRI, NSLPID, 3916 reception interface, 3917 liveness data) 3919 A node MUST implement this or an equivalently strong mechanism. 3920 There are several alternatives for the liveness data. One is to use 3921 a timestamp like SCTP. Another is to give the local secret a (rapid) 3922 rollover, with the liveness data as the generation number of the 3923 secret, like IKEv2. In both cases, the liveness data has to be 3924 carried outside the hash, to allow the hash to be verified at the 3925 Responder. Another approach is to replace the hash with encryption 3926 under a locally known secret, in which case the liveness data does 3927 not need to be carried in the clear. Any symmetric cipher immune to 3928 known plaintext attacks can be used. 3930 To support the validation simplicity requirement, the Responder can 3931 check the liveness data to filter out some blind (flooding) attacks 3932 before beginning any cryptographic cookie verification. To support 3933 this usage, the liveness data must be carried in the clear and not be 3934 easily guessable; this rules out the timestamp approach, and suggests 3935 the use of sequence of secrets with the liveness data identifying the 3936 position in the sequence. The secret strength and rollover frequency 3937 must be high enough that the secret cannot be brute-forced during its 3938 lifetime. Note that any node can use a Query to discover the current 3939 liveness data, so it remains hard to defend against sophisticated 3940 attacks which disguise such probes within a flood of Queries from 3941 forged source addresses. Therefore, it remains important to use an 3942 efficient hashing mechanism or equivalent. 3944 If a node receives a message for which cookie validation fails, it 3945 MAY return an "Object Value Error" error message (Appendix A.4.4.10) 3946 with subcode 4 ("Invalid Cookie") to the sender, as well as dropping 3947 the message. However, doing so in general makes a node a source of 3948 backscatter. Therefore, this MUST only be enabled selectively, e.g. 3949 during initial deployment or debugging. 3951 8.6. Security Protocol Selection Policy 3953 This specification defines a single mandatory-to-implement security 3954 protocol (TLS, Section 5.7.3). However, it is possible to define 3955 additional security protocols in the future, for example to allow re- 3956 use with other types of credentials, or migrate towards protocols 3957 with stronger security properties. In addition, use of any security 3958 protocol for a messaging association is optional. Security protocol 3959 selection is carried out as part of the GIST handshake mechanism 3960 (Section 4.4.1). 3962 The selection process may be vulnerable to downgrade attacks, where a 3963 man in the middle modifies the capabilities offered in the Query or 3964 Response to mislead the peers into accepting a lower level of 3965 protection than is achievable. There is a two part defence against 3966 such attacks (the following is based the same concepts as [22]): 3968 1. The Response does not depend on the Stack-Proposal in the Query 3969 (see Section 5.7.1). Therefore, tampering with the Query has no 3970 effect on the resulting messaging association configuration. 3972 2. The Responding node's Stack-Proposal is echoed in the Confirm. 3973 The Responding node checks this to validate that the proposal it 3974 made in the Response is the same as the one received by the 3975 Querying node. Note that as a consequence of the previous point, 3976 the Responding node does not have to remember the proposal 3977 explicitly, since it is a static function of local policy. 3979 The validity of the second part depends on the strength of the 3980 security protection provided for the Confirm. If the Querying node 3981 is prepared to create messaging associations with null security 3982 properties (e.g. TCP only), the defence is ineffective, since the 3983 man in the middle can re-insert the original Responder's Stack- 3984 Proposal, and the Responding node will assume that the minimal 3985 protection is a consequence of Querying node limitations. However, 3986 if the messaging association provides at least integrity protection 3987 that cannot be broken in real-time, the Confirm cannot be modified in 3988 this way. Therefore, if the Querying node does not apply a security 3989 policy to the messaging association protocols to be created that 3990 ensures at least this minimal level of protection is met, it remains 3991 open to the threat that a downgrade has occurred. Applying such a 3992 policy ensures capability discovery process will result in the setup 3993 of a messaging association with the correct security properties as 3994 appropriate for the two peers involved. 3996 8.7. Residual Threats 3998 Taking the above security mechanisms into account, the main residual 3999 threats against NSIS are three types of on-path attack. 4001 An on-path attacker who can intercept the initial Query can do most 4002 things it wants to the subsequent signaling. It is very hard to 4003 protect against this at the GIST level; the only defence is to use 4004 strong messaging association security to see whether the Responding 4005 node is authorised to take part in NSLP signaling exchanges. To some 4006 extent, this behaviour is logically indistinguishable from correct 4007 operation, so it is easy to see why defence is difficult. Note that 4008 an on-path attacker of this sort can do anything to the traffic as 4009 well as the signaling. Therefore, the additional threat induced by 4010 the signaling weakness seems tolerable. 4012 At the NSLP level, there is a concern about transitivity of trust of 4013 correctness of routing along the signaling chain. The NSLP at the 4014 querying node can have good assurance that it is communicating with 4015 an on-path peer or a node delegated by the on-path node. However, it 4016 has no assurance that the node beyond the responder is also on-path, 4017 or that the MRI (in particular) is not being modified by the 4018 responder to refer to a different flow. Therefore, if it sends 4019 signaling messages with payloads (e.g. authorisation tokens) which 4020 are valuable to nodes beyond the adjacent hop, it is up to the NSLP 4021 to ensure that the appropriate chain of trust exists, which must in 4022 general use strong messaging association security. 4024 There is a further residual attack by a node which is not on the path 4025 of the Query, but is on the path of the Response, or is able to use a 4026 Response from one handshake to interfere with another. The attacker 4027 modifies the Response to cause the Querying node to form an adjacency 4028 with it rather than the true peer. In principle, this attack could 4029 be prevented by including an additional cryptographic object in the 4030 Response which ties the Response to the initial Query and the routing 4031 state and can be verified by the Querying node. 4033 9. IANA Considerations 4035 This section defines the registries and initial codepoint assignments 4036 for GIST. It also defines the procedural requirements to be followed 4037 by IANA in allocating new codepoints. Note that the guidelines on 4038 the technical criteria to be followed in evaluating requests for new 4039 codepoint assignments are covered normatively in a separate document 4040 which considers the NSIS protocol suite in a unified way. That 4041 document discusses the general issue of NSIS extensibility, as well 4042 as the technical criteria for particular registries; see [11] for 4043 further details. 4045 The registry definitions that follow leave large blocks of codes 4046 reserved as unused. This is to allow a future revision of this 4047 specification to modify the allocation policies without having to 4048 retrospectively change the initial rules if they turn out to have 4049 been suboptimal, e.g. if the space for one particular policy is 4050 exhausted too quickly. 4052 The allocation policies used in this section follow the guidance 4053 given in [3]. In addition, for a number of the GIST registries, this 4054 specification also defines private/experimental ranges as discussed 4055 in [8]. Note that the only environment in which these codepoints can 4056 validly be used is a closed one in which the experimenter knows all 4057 the experiments in progress. 4059 This specification allocates the following codepoints in existing 4060 registries: 4062 Well-known UDP port XXX as the destination port for Q-mode 4063 encapsulated GIST messages (Section 5.3). 4065 This specification creates the following registries with the 4066 structures as defined below: 4068 NSLP Identifiers: Each signaling application requires the assignment 4069 of one of more NSLPIDs. The following NSLPID is allocated by this 4070 specification: 4072 +---------+---------------------------------------------------------+ 4073 | NSLPID | Application | 4074 +---------+---------------------------------------------------------+ 4075 | 0 | Used for GIST messages not related to any signaling | 4076 | | application. | 4077 +---------+---------------------------------------------------------+ 4079 Every other NSLPID MUST be associated with a specific RAO value; 4080 multiple NSLPIDs MAY be associated with the same value. The 4081 NSLPID is a 16 bit integer, and allocation policies for further 4082 values are as follows: 4084 1-32703: IESG Approval 4086 32704-32767: Private/Experimental Use 4088 32768-65536: Reserved 4090 GIST Message Type: The GIST common header (Appendix A.1) contains a 1 4091 byte message type field. The following values are allocated by 4092 this specification: 4094 +---------+----------+ 4095 | MType | Message | 4096 +---------+----------+ 4097 | 0 | Query | 4098 | | | 4099 | 1 | Response | 4100 | | | 4101 | 2 | Confirm | 4102 | | | 4103 | 3 | Data | 4104 | | | 4105 | 4 | Error | 4106 | | | 4107 | 5 | MA-Hello | 4108 +---------+----------+ 4110 Allocation policies for further values are as follows: 4112 6-63: Standards Action 4114 64-119: Expert Review 4116 120-127: Private/Experimental Use 4118 128-255: Reserved 4120 Object Types: There is a 12-bit field in the object header 4121 (Appendix A.2). The following values for object type are defined 4122 by this specification: 4124 +---------+-----------------------------+ 4125 | OType | Object Type | 4126 +---------+-----------------------------+ 4127 | 0 | Message Routing Information | 4128 | | | 4129 | 1 | Session ID | 4130 | | | 4131 | 2 | Network Layer Information | 4132 | | | 4133 | 3 | Stack Proposal | 4134 | | | 4135 | 4 | Stack Configuration Data | 4136 | | | 4137 | 5 | Query Cookie | 4138 | | | 4139 | 6 | Responder Cookie | 4140 | | | 4141 | 7 | NAT Traversal | 4142 | | | 4143 | 8 | NSLP Data | 4144 | | | 4145 | 9 | Error | 4146 +---------+-----------------------------+ 4148 Allocation policies for further values are as follows: 4150 10-1023: Standards Action 4152 1024-1999: Specification Required 4154 2000-2047: Private/Experimental Use 4156 2048-4095: Reserved 4158 When a new object type is defined, the object format MUST be 4159 provided, and the setting of the extensibility bits (A/B, see 4160 Appendix A.2.1) MUST also be defined. 4162 Message Routing Methods: GIST allows multiple message routing methods 4163 (see Section 3.3). The MRM is indicated in the leading byte of 4164 the MRI object (Appendix A.3.1). This specification defines the 4165 following values: 4167 +------------+------------------------+ 4168 | MRM-ID | Message Routing Method | 4169 +------------+------------------------+ 4170 | 0 | Path Coupled MRM | 4171 | | | 4172 | 1 | Loose End MRM | 4173 +------------+------------------------+ 4175 Allocation policies for further values are as follows: 4177 2-63: Standards Action 4179 64-119: Expert Review 4181 120-127: Private/Experimental Use 4183 128-255: Reserved 4185 When a new MRM is defined, the specification MUST provide the 4186 information described in Section 3.3. 4188 MA-Protocol-IDs: Each upper layer protocol that can be used in a 4189 messaging association is identified by a 1-byte MA-Protocol-ID 4190 (Section 5.7). This is used as a tag in the Stack-Proposal and 4191 Stack-Configuration-Data objects (Appendix A.3.4 and 4192 Appendix A.3.5). The following values are defined by this 4193 specification: 4195 +---------------------+-----------------------------------------+ 4196 | MA-Protocol-ID | Higher Layer Protocol | 4197 +---------------------+-----------------------------------------+ 4198 | 1 | TCP opened in the forwards direction | 4199 | | | 4200 | 2 | TLS initiated in the forwards direction | 4201 +---------------------+-----------------------------------------+ 4203 Allocation policies for further values are as follows: 4205 3-63: Standards Action 4207 64-119: Expert Review 4209 120-127: Private/Experimental Use 4211 128-255: Reserved 4213 Allocation of a new MA-Protocol-ID MUST define the format for the 4214 MA-protocol-options field (if any) in the Stack-Configuration-Data 4215 object that is needed to define its configuration. If a protocol 4216 is to be used for reliable message transfer, it MUST be described 4217 how delivery errors are to be detected by GIST. Note that the MA- 4218 Protocol-ID is not an IP Protocol number; indeed, some of the 4219 messaging association protocols - such as TLS - do not have an IP 4220 Protocol number. 4222 Error Codes/Subcodes: There is a 2 byte error code and 1 byte subcode 4223 in the Value field of the Error object (Appendix A.4.1). Error 4224 codes 1-12 are defined in Appendix A.4.4 together with subcodes 4225 0-3 for code 1, 0-5 for code 9, 0-5 for code 10, and 0-2 for code 4226 12. Additional codes and subcodes are allocated on a first-come, 4227 first served basis. When a new error code/subcode combination is 4228 allocated, the Error Class and the format of any associated error- 4229 specific information MUST also be defined. 4231 10. Acknowledgements 4233 This document is based on the discussions within the IETF NSIS 4234 working group. It has been informed by prior work and formal and 4235 informal inputs from: Cedric Aoun, Attila Bader, Roland Bless, Bob 4236 Braden, Marcus Brunner, Benoit Campedel, Luis Cordeiro, Elwyn Davies, 4237 Christian Dickmann, Pasi Eronen, Alan Ford, Xiaoming Fu, Bo Gao, 4238 Ruediger Geib, Eleanor Hepworth, Thomas Herzog, Cheng Hong, Jia Jia, 4239 Cornelia Kappler, Georgios Karagiannis, Ruud Klaver, Chris Lang, John 4240 Loughney, Allison Mankin, Jukka Manner, Pete McCann, Andrew McDonald, 4241 Glenn Morrow, Dave Oran, Andreas Pashalidis, Henning Peters, Tom 4242 Phelan, Takako Sanda, Charles Shen, Melinda Shore, Martin 4243 Stiemerling, Martijn Swanink, Mike Thomas, Hannes Tschofenig, Sven 4244 van den Bosch, Michael Welzl, Lars Westberg, and Mayi Zoumaro- 4245 djayoon. Parts of the TLS usage description (Section 5.7.3) were 4246 derived from the Diameter base protocol specification, RFC3588. In 4247 addition, Hannes Tschofenig provided a detailed set of review 4248 comments on the security section, and Andrew McDonald provided the 4249 formal description for the initial packet formats. Chris Lang's 4250 implementation work provided objective feedback on the clarity and 4251 feasibility of the specification, and he also provided the state 4252 machine description and the initial error catalogue and formats. 4253 Finally, Magnus Westerlund carried out a detailed AD review which 4254 identified a number of issues and led to significant clarifications. 4256 11. References 4258 11.1. Normative References 4260 [1] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 4262 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4263 Levels", BCP 14, RFC 2119, March 1997. 4265 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 4266 Considerations Section in RFCs", BCP 26, RFC 2434, 4267 October 1998. 4269 [4] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 4270 the Differentiated Services Field (DS Field) in the IPv4 and 4271 IPv6 Headers", RFC 2474, December 1998. 4273 [5] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 4274 RFC 2711, October 1999. 4276 [6] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 4277 RFC 2765, February 2000. 4279 [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 4280 RFC 2246, January 1999. 4282 [8] Narten, T., "Assigning Experimental and Testing Numbers 4283 Considered Useful", BCP 82, RFC 3692, January 2004. 4285 [9] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 4286 Specifications: ABNF", RFC 4234, October 2005. 4288 [10] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 4289 Protocol Version 1.1", RFC 4346, April 2006. 4291 [11] Loughney, J., "NSIS Extensibility Model", 4292 draft-loughney-nsis-ext-02 (work in progress), March 2006. 4294 11.2. Informative References 4296 [12] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 4297 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 4298 Specification", RFC 2205, September 1997. 4300 [13] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 4302 [14] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP 4303 Operation Over IP Tunnels", RFC 2746, January 2000. 4305 [15] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 4306 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 4308 [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 4309 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 4310 Paxson, "Stream Control Transmission Protocol", RFC 2960, 4311 October 2000. 4313 [17] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 4314 IPv4 Clouds", RFC 3056, February 2001. 4316 [18] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 4317 RFC 3068, June 2001. 4319 [19] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 4320 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 4321 September 2001. 4323 [20] Grossman, D., "New Terminology and Clarifications for 4324 Diffserv", RFC 3260, April 2002. 4326 [21] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 4327 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 4328 RFC 3320, January 2003. 4330 [22] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 4331 Haukka, "Security Mechanism Agreement for the Session 4332 Initiation Protocol (SIP)", RFC 3329, January 2003. 4334 [23] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 4335 - Simple Traversal of User Datagram Protocol (UDP) Through 4336 Network Address Translators (NATs)", RFC 3489, March 2003. 4338 [24] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 4339 of UDP Through NAT (STUN)", draft-ietf-behave-turn-01 (work in 4340 progress), June 2006. 4342 [25] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 4343 Security Mechanism (GTSM)", RFC 3682, February 2004. 4345 [26] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 4346 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 4347 June 2005. 4349 [27] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 4350 Steps in Signaling (NSIS)", RFC 4081, June 2005. 4352 [28] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 4353 Requirements for Security", BCP 106, RFC 4086, June 2005. 4355 [29] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 4356 Transport Layer Security (TLS)", RFC 4279, December 2005. 4358 [30] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion 4359 Control Protocol (DCCP)", RFC 4340, March 2006. 4361 [31] Conta, A., Deering, S., and M. Gupta, "Internet Control Message 4362 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 4363 Specification", RFC 4443, March 2006. 4365 [32] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 4366 (NSLP)", draft-ietf-nsis-nslp-natfw-12 (work in progress), 4367 June 2006. 4369 [33] Manner, J., "NSLP for Quality-of-Service Signaling", 4370 draft-ietf-nsis-qos-nslp-11 (work in progress), June 2006. 4372 [34] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 4373 IPv6 Hosts and Routers", RFC 4213, October 2005. 4375 [35] Kent, S. and K. Seo, "Security Architecture for the Internet 4376 Protocol", RFC 4301, December 2005. 4378 [36] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol 4379 Architecture", RFC 4251, January 2006. 4381 [37] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06 4382 (work in progress), June 2006. 4384 [38] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 4385 Nordmark, "Mobile IP Version 6 Route Optimization Security 4386 Design Background", RFC 4225, December 2005. 4388 [39] Floyd, S. and V. Jacobson, "The Synchronisation of Periodic 4389 Routing Messages", SIGCOMM Symposium on Communications 4390 Architectures and Protocols pp. 33--44, September 1993. 4392 [40] Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal", 4393 draft-pashalidis-nsis-gimps-nattraversal-03 (work in progress), 4394 June 2006. 4396 [41] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4397 Security", RFC 4347, April 2006. 4399 Appendix A. Bit-Level Formats and Error Messages 4401 This appendix provides formats for the various component parts of the 4402 GIST messages defined abstractly in Section 5.2. 4404 Each GIST message consists of a header and a sequence of objects. 4405 The GIST header has a specific format, described in more detail in 4406 Appendix A.1 below. An NSLP message is one object within a GIST 4407 message. Note that GIST itself provides the NSLP message length 4408 information and signaling application identification. General object 4409 formatting guidelines are provided in Appendix A.2 below, followed in 4410 Appendix A.3 by the format for each object. Finally, Appendix A.4 4411 provides the formats used for error reporting. 4413 In the following object diagrams, '//' is used to indicate a variable 4414 sized field and ':' is used to indicate a field that is optionally 4415 present. 4417 A.1. The GIST Common Header 4419 This header begins all GIST messages. It has a fixed format, as 4420 shown below. 4422 0 1 2 3 4423 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 4424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4425 | Version | GIST hops | Message length | 4426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4427 | NSLPID | Type |S|R|E| Reserved| 4428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4430 Version (8 bits): The GIST protocol version number. 4432 GIST hops (8 bits): A hop count for the number of GIST-aware nodes 4433 this message can still pass through. 4435 Message Length (16 bits): The total number of words in the message 4436 after the common header itself. 4438 NSLPID (16 bits): IANA assigned identifier of the signaling 4439 application the message refers to. 4441 Type (8 bits): The GIST message type (Query, Response, etc.). 4443 S flag: S=1 if the IP source address is the same as the signaling 4444 source address, S=0 if it is different. 4446 R flag: R=1 if a reply to this message is explicitly requested. 4448 E flag: E=1 if the message was explicitly routed Section 7.1.4. 4450 The rules governing the use of the R-flag depend on the GIST message 4451 type. It MUST always be set (R=1) in Query messages, since these 4452 always elicit a Response, and never in Confirm, Data or Error 4453 messages. It is optional in an MA-Hello; if set, another MA-Hello is 4454 sent in reply. It is optional in a Response, but MUST be set if the 4455 Response contains a Responder cookie; if set, a Confirm is sent in 4456 reply. 4458 Parsing failures may be caused by unknown Version or Type values, 4459 inconsistent R flag setting, or a Message Length inconsistent with 4460 the set of objects carried. In all cases the receiver MUST if 4461 possible return a "Common Header Parse Error" message 4462 (Appendix A.4.4.1) with the appropriate subcode, and not process the 4463 message further. 4465 A.2. General Object Format 4467 Each object begins with a fixed header giving the object Type and 4468 object Length. This is followed by the object Value, which is a 4469 whole number of 32-bit words long. 4471 0 1 2 3 4472 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 4473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4474 |A|B|r|r| Type |r|r|r|r| Length | 4475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4476 // Value // 4477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4479 A/B flags: The bits marked 'A' and 'B' are extensibility flags which 4480 are defined in Appendix A.2.1 below; the remaining bits marked 'r' 4481 are reserved. 4483 Type (12 bits): An IANA-assigned identifier for the type of object. 4485 Length (12 bits): Length has the units of 32 bit words, and measures 4486 the length of Value. If there is no Value, Length=0. If the 4487 Length is not consistent with the contents of the object, an 4488 "Object Value Error" message (Appendix A.4.4.10) with subcode 0 4489 "Incorrect Length" MUST be returned and the message dropped. 4491 Value (variable): Value is (therefore) a whole number of 32 bit 4492 words. If there is any padding required, the length and location 4493 must be defined by the object-specific format information; objects 4494 which contain variable length (e.g. string) types may need to 4495 include additional length subfields to do so. 4497 Any part of the object used for padding or defined as reserved 4498 (marked 'Reserved' or 'Rsv' or, in the case of individual bits, 'r' 4499 in the diagrams below) MUST be set to 0 on transmission and MUST be 4500 ignored on reception. 4502 A.2.1. Object Extensibility 4504 The leading two bits of the TLV header are used to signal the desired 4505 treatment for objects whose Type field is unknown at the receiver. 4506 The following three categories of object have been identified, and 4507 are described here. 4509 AB=00 ("Mandatory"): If the object is not understood, the entire 4510 message containing it MUST be rejected with an "Object Type Error" 4511 message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object"). 4513 AB=01 ("Ignore"): If the object is not understood, it MUST be deleted 4514 and the rest of the message processed as usual. 4516 AB=10 ("Forward"): If the object is not understood, it MUST be 4517 retained unchanged in any message forwarded as a result of message 4518 processing, but not stored locally. 4520 The combination AB=11 is reserved. If a message is received 4521 containing and object with AB=11, it MUST be rejected with an "Object 4522 Type Error" message (Appendix A.4.4.9) with subcode 5 ("Invalid 4523 Extensibility Flags"). 4525 A.3. GIST TLV Objects 4527 A.3.1. Message-Routing-Information 4529 Type: Message-Routing-Information 4531 Length: Variable (depends on MRM) 4532 0 1 2 3 4533 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 4534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4535 | MRM-ID |N| Reserved | | 4536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4537 // Method-specific addressing information (variable) // 4538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4540 MRM-ID (8 bits): An IANA-assigned identifier for the message routing 4541 method. 4543 N flag: If set (N=1), this means that NATs do not need to translate 4544 this MRM; if clear (N=0) it means that the method-specific 4545 information contains network or transport layer information that a 4546 NAT must process. 4548 The remainder of the object contains method-specific addressing 4549 information, which is described below. 4551 A.3.1.1. Path-Coupled MRM 4553 In the case of basic path-coupled routing, the addressing information 4554 takes the following format. The N-flag N=0 for this MRM. 4556 0 1 2 3 4557 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 4558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4559 |IP-Ver |P|T|F|S|A|B|D|Reserved | 4560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4561 // Source Address // 4562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4563 // Destination Address // 4564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4565 | Source Prefix | Dest Prefix | Protocol | DS-field |Rsv| 4566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4567 : Reserved | Flow Label : 4568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4569 : SPI : 4570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4571 : Source Port : Destination Port : 4572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4574 IP-Ver (4 bits): The IP version number, 4 or 6. 4576 Source/Destination address (variable): The source and destination 4577 addresses are always present and of the same type; their length 4578 depends on the value in the IP-Ver field. 4580 Source/Dest Prefix (each 8 bits): The length of the mask to be 4581 applied to the source and destination addresses for address 4582 wildcarding. In the normal case where the MRI refers only to 4583 traffic between specific host addresses, the Source/Dest Prefix 4584 values would both be 32/128 for IPv4/6 respectively. 4586 P flag: P=1 means that IP Protocol should be interpreted. 4588 Protocol (8 bits): The IP protocol number. Ignored if P=0. In the 4589 case of IPv6, the Protocol field refers to the true upper layer 4590 protocol carried by the packets, i.e. excluding any IP option 4591 headers. This is therefore not necessarily the same as the Next 4592 Header value from the base IPv6 header. 4594 T flag: T=1 means that DiffServ field (DS-field) should be 4595 interpreted. 4597 DS-field (6 bits): The DiffServ field. See [4] and [20]. 4599 F flag: F=1 means that flow label is present and should be 4600 interpreted. 4602 Flow Label (20 bits): The flow label; only present if F=1. If F=0, 4603 the entire 32 bit word containing the Flow Label is absent. F may 4604 only be set if IP-Ver is 6. 4606 S flag: S=1 means that the SPI field is present. Can only be set if 4607 P=1. 4609 SPI field (32 bits): The SPI field; see [35]. Only present if S=1. 4611 A/B flags: These can only be set if P=1. If either is set, the port 4612 fields are also present. 4614 Source/Destination Port (each 16 bits): If either of A, B is set the 4615 word containing the port numbers is included in the object. 4616 However, the contents of each field is only significant if the 4617 corresponding flag is set; otherwise, the contents of the field is 4618 regarded as padding, and the MRI refers to all ports (i.e. acts as 4619 a wildcard). If the flag is set and Port=0x0000, the MRI will 4620 apply to a specific port, whose value is not yet known. If 4621 neither of A or B is set, the word is absent. 4623 D flag: The Direction flag has the following meaning: the value 0 4624 means 'in the same direction as the flow' (i.e. downstream), and 4625 the value 1 means 'in the opposite direction to the flow' (i.e. 4626 upstream). 4628 A.3.1.2. Loose-End MRM 4630 In the case of the loose-end MRM, the addressing information takes 4631 the following format. The N-flag N=0 for this MRM. 4633 0 1 2 3 4634 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 4635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4636 |IP-Ver |D| Reserved | 4637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4638 // Source Address // 4639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4640 // Destination Address // 4641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4643 IP-Ver (4 bits): The IP version number, 4 or 6. 4645 Source/Destination address (variable): The source and destination 4646 addresses are always present and of the same type; their length 4647 depends on the value in the IP-Ver field. 4649 D flag: The direction flag. The only valid value is D=0 (see 4650 Section 5.8.2). 4652 A.3.2. Session Identification 4654 Type: Session-Identification 4656 Length: Fixed (4 32-bit words) 4658 0 1 2 3 4659 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 4660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4661 | | 4662 + + 4663 | | 4664 + Session ID + 4665 | | 4666 + + 4667 | | 4668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4670 A.3.3. Network-Layer-Information 4671 Type: Network-Layer-Information 4673 Length: Variable (depends on length of Peer-Identity and IP version) 4675 0 1 2 3 4676 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 4677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4678 | PI-Length | IP-TTL |IP-Ver | Reserved | 4679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4680 | Routing State Validity Time | 4681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4682 // Peer Identity // 4683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4684 // Interface Address // 4685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4687 PI-Length (8 bits): The byte length of the Peer Identity field. 4689 Peer Identity (variable): The Peer Identity field. Note that the 4690 Peer-Identity field itself is padded to a whole number of words. 4692 IP-TTL (8 bits): Initial or reported IP layer TTL. 4694 IP-Ver (4 bits): The IP version for the Interface Address field. 4696 Interface Address (variable): The IP address allocated to the 4697 interface, matching the IP-Ver field. 4699 Routing State Validity Time (32 bits): The time for which the routing 4700 state for this flow can be considered correct without a refresh. 4701 Given in milliseconds. 4703 A.3.4. Stack Proposal 4705 Type: Stack-Proposal 4707 Length: Variable (depends on number of profiles and size of each 4708 profile) 4710 0 1 2 3 4711 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 4712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4713 | Prof-Count | Reserved | 4714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4715 // Profile 1 // 4716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4717 : : 4718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4719 // Profile 2 // 4720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4722 Prof-Count (8 bits): The number of profiles listed. MUST be > 0. 4724 Each profile is itself a sequence of protocol layers, and the profile 4725 is formatted as a list as follows: 4727 o The first byte is a count of the number of layers in the profile. 4729 o This is followed by a sequence of 1-byte MA-Protocol-IDs as 4730 described in Section 5.7. 4732 o The profile is padded to a word boundary with 0, 1, 2 or 3 zero 4733 bytes. 4735 If there are no profiles (i.e. all bytes are null), then an "Object 4736 Value Error" message (Appendix A.4.4.10) with subcode 3 ("Empty 4737 List") MUST be returned and the message dropped. 4739 A.3.5. Stack-Configuration-Data 4741 Type: Stack-Configuration-Data 4743 Length: Variable (depends on number of protocols and size of each MA- 4744 protocol-options field) 4746 0 1 2 3 4747 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 4748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4749 | MPO-Count | Reserved | 4750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4751 | MA-Hold-Time | 4752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4753 // MA-protocol-options 1 // 4754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4755 : : 4756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4757 // MA-protocol-options N // 4758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4760 MPO-Count (8 bits): The number of MA-protocol-options fields present 4761 (these contain their own length information). 4763 MA-Hold-Time (32 bits): The time for which the messaging association 4764 will be held open without traffic or a hello message. Given in 4765 milliseconds. 4767 The MA-protocol-options fields are formatted as follows: 4769 0 1 2 3 4770 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 4771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4772 |MA-Protocol-ID | Profile | Length |D| Reserved | 4773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4774 // Options Data // 4775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4777 MA-Protocol-ID (8 bits): Protocol identifier as described in 4778 Section 5.7. 4780 Profile (8 bits): Tag indicating which profile from the accompanying 4781 Stack-Proposal object this applies to. Profiles are numbered from 4782 1 upwards; the special value 0 indicates 'applies to all 4783 profiles'. 4785 Length (8 bits): The byte length of MA-protocol-options field that 4786 follows. This will be zero-padded up to the next word boundary. 4788 D flag: If set (D=1), this protocol MUST NOT be used for a messaging 4789 association. 4791 Options Data (variable): Any options data for this protocol. Note 4792 that the format of the options data may differ depending on 4793 whether the field is in a Query or Response. 4795 A.3.6. Query Cookie 4797 Type: Query-Cookie 4799 Length: Variable (selected by querying node) 4801 0 1 2 3 4802 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 4803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4804 // Query Cookie // 4805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4807 The contents are implementation defined. See Section 8.5 for further 4808 discussion. 4810 A.3.7. Responder Cookie 4812 Type: Responder-Cookie 4814 Length: Variable (selected by responding node) 4816 0 1 2 3 4817 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 4818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4819 // Responder Cookie // 4820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4822 The contents are implementation defined. See Section 8.5 for further 4823 discussion. 4825 A.3.8. NAT Traversal 4827 Type: NAT-Traversal 4829 Length: Variable (depends on length of contained fields) 4831 This object is used to support the NAT traversal mechanisms described 4832 in Section 7.2. 4834 0 1 2 3 4835 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 4836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4837 | MRI-Length | Type-Count | NAT-Count | Reserved | 4838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4839 // Original Message-Routing-Information // 4840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4841 // List of translated objects // 4842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4843 | Length of opaque information | | 4844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 4845 // Information replaced by NAT #1 | 4846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4847 : : 4848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4849 | Length of opaque information | | 4850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 4851 // Information replaced by NAT #N | 4852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4854 MRI-Length (8 bits): The word length of the included MRI payload. 4856 Original Message-Routing-Information (variable): The MRI data from 4857 when the message was first sent, not including the object header. 4859 Type-Count (8 bits): The number of objects in the 'List of translated 4860 objects' field. 4862 List of translated objects (variable): This field lists the object 4863 types of the objects that were translated by every NAT through 4864 which the message has passed. It is initialised by the first NAT 4865 on the path; subsequent NATs may delete elements in the list. 4866 Padded with 2 null bytes if necessary. 4868 NAT-Count (8 bits): The number of NATs traversed by the message, and 4869 the number of opaque payloads at the end of the object. The 4870 length fields for each opaque payload are byte counts, not 4871 including the 2 bytes of the length field itself. Note that each 4872 opaque information field is zero-padded to the next 32-bit word 4873 boundary if necessary. 4875 A.3.9. NSLP Data 4877 Type: NSLP-Data 4878 Length: Variable (depends on NSLP) 4880 0 1 2 3 4881 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 4882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4883 // NSLP Data // 4884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4886 A.4. Errors 4888 A.4.1. Error Object 4890 Type: Error 4892 Length: Variable (depends on error) 4894 0 1 2 3 4895 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 4896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4897 | Error Class | Error Code | Error Subcode | 4898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4899 |S|M|C|D|Q| Reserved | MRI Length | Info Count | 4900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4901 | | 4902 + Common Header + 4903 | (of original message) | 4904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4905 : Session Id : 4906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4907 : Message Routing Information : 4908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4909 : Additional Information : 4910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4911 : Debugging Comment : 4912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4914 The flags are: 4915 S - S=1 means the Session ID object is present 4916 M - M=1 means MRI object is present 4917 C - C=1 means a debug Comment is present after header. 4918 D - D=1 means the original message was received in D-mode 4919 Q - Q=1 means the original message was received Q-mode encapsulated 4920 (can't be set if D=0). 4922 A GIST Error object contains an 8 bit error-class (see 4923 Appendix A.4.3), a 16 bit error-code, an 8 bit error-subcode, and as 4924 much information about the message which triggered the error as is 4925 available. This information MUST include the Common header of the 4926 original message and MUST also include the Session Id and MRI objects 4927 if these could be decoded correctly. These objects are included in 4928 their entirety, except for their TLV Headers. 4930 The Info Count field contains the number of Additional Information 4931 fields in the object, and the possible formats for these fields are 4932 given in Appendix A.4.2. The precise set of fields to include 4933 depends on the error code/subcode. For every error description in 4934 the error catalogue Appendix A.4.4, the line "Additional Info:" 4935 states what fields MUST be included, and in what order if there can 4936 be more than one; if this line is given as 'None' then additional 4937 information MUST NOT be included. The Debugging Comment is a null- 4938 terminated UTF-8 string, padded if necessary to a whole number of 32- 4939 bit words with more null characters. 4941 A.4.2. Additional Information Fields 4943 The Common Error Header may be followed by some Additional 4944 Information objects. The possible formats of these objects are shown 4945 below. 4947 Message Length Info: 4949 0 1 2 3 4950 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 4951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4952 | Calculated Length | Reserved | 4953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4954 Calculated Length (16 bits): the length of the original message 4955 calculated by adding up all the objects in the message. 4957 MTU Info: 4959 0 1 2 3 4960 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 4961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4962 | Link MTU | Reserved | 4963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4964 Link MTU (16 bits): the MTU for a link along which a message could 4965 not be sent. 4967 Object Type Info: 4969 0 1 2 3 4970 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 4971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4972 | Object Type | Reserved | 4973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4974 Object type (16 bits): This provides information about the type 4975 of object which caused the error. 4977 Object Value Info: 4979 0 1 2 3 4980 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 4981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4982 | Rsv | Real Object Length | Offset | 4983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4984 // Object // 4985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4986 This object carries information about a TLV object which was found 4987 to be invalid in the original message. An error message may contain 4988 more than one Object Value Info object. 4990 Real Object Length (12 bits) Since the length in the original TLV 4991 header may be inaccurate, this field provides the actual length 4992 of the object (including the TLV Header) included in the error 4993 message. 4995 Offset (16 bits): The byte in the object at which the GIST node 4996 found the error. The first byte in the object has offset=0. 4998 Object (variable): The invalid TLV object (including the TLV 4999 Header). 5001 A.4.3. Error Classes 5003 The first byte of the error object, "Error Class", indicates the 5004 severity level. The currently defined severity levels are: 5006 0 (Informational): response data which should not be thought of as 5007 changing the condition of the protocol state machine. 5009 1 (Success): response data which indicates that the message being 5010 responded to has been processed successfully in some sense. 5012 2 (Protocol-Error): the message has been rejected because of a 5013 protocol error (e.g. an error in message format). 5015 3 (Transient-Failure): the message has been rejected because of a 5016 particular local node status which may be transient (i.e. it may 5017 be worthwhile to retry after some delay). 5019 4 (Permanent-Failure): the message has been rejected because of local 5020 node status which will not change without additional out of band 5021 (e.g. management) operations. 5023 Additional error class values are reserved. 5025 The allocation of error classes to particular errors is not precise; 5026 the above descriptions are deliberately informal. Actual error 5027 processing should take into account the specific error in question; 5028 the error class may be useful supporting information (e.g. in network 5029 debugging). 5031 A.4.4. Error Catalogue 5033 This section lists all the possible GIST errors, including when they 5034 are raised and what additional information fields should be carried 5035 in the error object. 5037 A.4.4.1. Common Header Parse Error 5039 Class: Protocol-Error 5040 Code: 1 5041 Additional Info: For subcode 3 only, Message Length Info carries 5042 the calculated message length. 5044 This message is sent if a GIST node receives a message where the 5045 common header cannot be parsed correctly, or where an error in the 5046 overall message format is detected. Note that in this case the 5047 original MRI and Session ID are not included in the Error Object. 5048 This error code is split into subcodes as follows: 5050 0: Unknown Version: The GIST version is unknown. The (highest) 5051 supported version supported by the node can be inferred from the 5052 Common Header of the Error message itself. 5054 1: Unknown Type: The GIST message type is unknown. 5056 2: Invalid R-flag: The R flag in the header is inconsistent with the 5057 message type. 5059 3: Incorrect Message Length: The overall message length is not 5060 consistent with the set of objects carried. 5062 A.4.4.2. Hop Limit Exceeded 5064 Class: Permanent-Failure 5065 Code: 2 5066 Additional Info: None 5068 This message is sent if a GIST node receives a message with a GIST 5069 hop count of zero, or a GIST node decrements a packet's GIST hop 5070 count to zero on reception. This message indicates either a routing 5071 loop or too small an initial hop count value. 5073 A.4.4.3. Incorrect Encapsulation 5075 Class: Protocol-Error 5076 Code: 3 5077 Additional Info: None 5079 This message is sent if a GIST node receives a message which uses an 5080 incorrect encapsulation method (e.g. a Query arrives over an MA). 5082 A.4.4.4. Incorrectly Delivered Message 5084 Class: Protocol-Error 5085 Code: 4 5086 Additional Info: None 5088 This message is sent if a GIST node receives a message over an MA 5089 which is not associated with the MRI/NSLPID/SID combination in the 5090 message. 5092 A.4.4.5. No Routing State 5094 Class: Protocol-Error 5095 Code: 5 5096 Additional Info: None 5098 This message is sent if a node receives a message for which routing 5099 state should exist, but has not yet been created and thus there is no 5100 appropriate Querying-SM or Responding-SM. This can occur either on 5101 receiving a Response to an unknown Query, or on receiving a Data 5102 message at a node whose policy requires routing state to exist before 5103 such messages can be accepted. See also Section 6.1 and Section 6.3. 5105 A.4.4.6. Unknown NSLPID 5107 Class: Permanent-Failure 5108 Code: 6 5109 Additional Info: None 5111 This message is sent if a router receives a directly addressed 5112 message for an NSLP which it does not support. 5114 A.4.4.7. Endpoint Found 5116 Class: Informational 5117 Code: 7 5118 Additional Info: None 5120 This message is sent if a GIST node at a flow endpoint receives a 5121 Query message for an NSLP which it does not support. 5123 A.4.4.8. Message Too Large 5125 Class: Permanent-Failure 5126 Code: 8 5127 Additional Info: MTU Info 5129 A router receives a message which it can't forward because it exceeds 5130 the MTU on the next or subsequent hops. 5132 A.4.4.9. Object Type Error 5134 Class: Protocol-Error 5135 Code: 9 5136 Additional Info: Object Type Info 5138 This message is sent if a GIST node receives a message containing a 5139 TLV object with an invalid type. The message includes the object at 5140 fault. This error code is split into subcodes as follows: 5142 0: Duplicate Object: This subcode is used if a GIST node receives a 5143 message containing multiple instances of an object which may only 5144 appear once in a message. In the current specification, this 5145 applies to all objects. 5147 1: Unrecognised Object: This subcode is used if a GIST node receives 5148 a message containing an object which it does not support, and the 5149 extensibility flags AB=00. 5151 2: Missing Object: This subcode is used if a GIST node receives a 5152 message which is missing one or more mandatory objects. This 5153 message is also sent if a Stack-Proposal is sent without a 5154 matching Stack-Configuration-Data object when one was necessary, 5155 or vice versa. 5157 3: Invalid Object Type: This subcode is used if the object type is 5158 known, but it is not valid for this particular GIST message type. 5160 4: Untranslated Object: This subcode is used if the object type is 5161 known and is mandatory to interpret, but it contains addressing 5162 data which has not been translated by an intervening NAT. 5164 5: Invalid Extensibility Flags: This subcode is used if an object is 5165 received with the extensibility flags AB=11. 5167 A.4.4.10. Object Value Error 5169 Class: Protocol-Error 5170 Code: 10 5171 Additional Info: 1 or 2 Object Value Info fields as given below 5173 This message is sent if a router receives a packet containing an 5174 object which cannot be properly parsed. The message contains a 5175 single Object Value Info object, except for subcode 5 as stated 5176 below. This error code is split into subcodes as follows: 5178 0: Incorrect Length: The overall length does not match the object 5179 length calculated from the object contents. 5181 1: Value Not Supported: The value of a field is not supported by the 5182 GIST node. 5184 2: Invalid Flag-Field Combination: An object contains an invalid 5185 combination of flags and/or fields. At the moment this only 5186 relates to the Path-Coupled MRM object, but in future there may be 5187 more. 5189 3: Empty List: At the moment this only relates to Stack-Proposals. 5190 The error message is sent if a stack proposal with a length > 0 (a 5191 length of 0 is handled as "Value Not Supported") contains only 5192 null bytes. 5194 4: Invalid Cookie: The message contains a cookie which could not be 5195 verified by the node. 5197 5: Stack-Proposal - Stack-Configuration-Data Mismatch: This subcode 5198 is used if a GIST node receives a message in which the data in the 5199 Stack-Proposal object is inconsistent with the information in the 5200 Stack Configuration Data object. In this case, both the Stack- 5201 Proposal object and Stack-Configuration-Data object MUST be 5202 included in separate Object Value Info fields in that order. 5204 A.4.4.11. Invalid IP layer TTL 5206 Class: Permanent-Failure 5207 Code: 11 5208 Additional Info: None 5210 This error indicates that a message was received with an IP layer TTL 5211 outside an acceptable range; for example, that an upstream Query was 5212 received with an IP layer TTL of less than 254 (i.e. more than one IP 5213 hop from the sender). The actual IP distance can be derived from the 5214 IP-TTL information in the NLI object carried in the same message. 5216 A.4.4.12. MRI Validation Failure 5218 Class: Permanent-Failure 5219 Code: 12 5220 Additional Info: Object Value Info 5222 This error indicates that a message was received with an MRI that 5223 could not be accepted, e.g. because of too much wildcarding or 5224 failing some validation check (cf. Section 5.8.1.2). The Object 5225 Value Info includes the MRI so the error originator can indicate the 5226 part of the MRI which caused the problem. The error code is divided 5227 into subcodes as follows: 5229 0: MRI Too Wild: The MRI contained too much wildcarding (e.g. too 5230 short a destination address prefix) to be forwarded correctly down 5231 a single path. 5233 1: IP Version Mismatch: The MRI in a path-coupled Query message uses 5234 an IP version which is not implemented on the interface used. 5236 2: Ingress Filter Failure: The MRI in a path-coupled Query message 5237 describes a flow which would not pass ingress filtering on the 5238 interface used. 5240 Appendix B. API between GIST and Signaling Applications 5242 This appendix provides an abstract API between GIST and signaling 5243 applications. It should not constrain implementors, but rather help 5244 clarify the interface between the different layers of the NSIS 5245 protocol suite. In addition, although some of the data types carry 5246 the information from GIST information elements, this does not imply 5247 that the format of that data as sent over the API has to be the same. 5249 Conceptually the API has similarities to the sockets API, 5250 particularly that for unconnected UDP sockets. An extension for an 5251 API like that for UDP connected sockets could be considered. In this 5252 case, for example, the only information needed in a SendMessage 5253 primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle 5254 (which can be null). Other information which was persistent for a 5255 group of messages could be configured once for the socket. Such 5256 extensions may make a concrete implementation more efficient but do 5257 not change the API semantics, and so are not considered further here. 5259 B.1. SendMessage 5261 This primitive is passed from a signaling application to GIST. It is 5262 used whenever the signaling application wants to initiate sending a 5263 message. 5265 SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, 5266 NSLPID, Session-ID, MRI, SII-Handle, 5267 Transfer-Attributes, Timeout, IP-TTL, GIST-Hop-Count ) 5269 The following arguments are mandatory. 5271 NSLP-Data: The NSLP message itself. 5273 NSLP-Data-Size: The length of NSLP-Data. 5275 NSLP-Message-Handle: A handle for this message, that can be used by 5276 GIST as a reference in subsequent MessageStatus notifications 5277 (Appendix B.3). Notifications could be about error conditions or 5278 about the security attributes that will be used for the message. 5279 A NULL handle may be supplied if the NSLP is not interested in 5280 such notifications. 5282 NSLPID: An identifier indicating which NSLP this is. 5284 Session-ID: The NSIS session identifier. Note that it is assumed 5285 that the signaling application provides this to GIST rather than 5286 GIST providing a value itself. 5288 MRI: Message routing information for use by GIST in determining the 5289 correct next GIST hop for this message. The MRI implies the 5290 message routing method to be used and the message direction. 5292 The following arguments are optional: 5294 SII-Handle: A handle, previously supplied by GIST, to a data 5295 structure that should be used to route the message explicitly to a 5296 particular GIST next hop. 5298 Transfer-Attributes: Attributes defining how the message should be 5299 handled (see Section 4.1.2). The following attributes can be 5300 considered: 5302 Reliability: Values 'unreliable' or 'reliable'. 5304 Security: This attribute allows the NSLP to specify what level of 5305 security protection is requested for the message (selected from 5306 'integrity' and 'confidentiality'), and can also be used to 5307 specify what authenticated signaling source and destination 5308 identities should be used to send the message. The 5309 possibilities can be learned by the signaling application from 5310 prior MessageStatus or RecvMessage notifications. If an NSLP- 5311 Message-Handle is provided, GIST will inform the signaling 5312 application of what values it has actually chosen for this 5313 attribute via a MessageStatus callback. This might take place 5314 either synchronously (where GIST is selecting from available 5315 messaging associations), or asynchronously (when a new 5316 messaging association needs to be created). 5318 Local Processing: This attribute contains hints from the signaling 5319 application about what local policy should be applied to the 5320 message; in particular, its transmission priority relative to 5321 other messages, or whether GIST should attempt to set up or 5322 maintain forward routing state. 5324 Timeout: Length of time GIST should attempt to send this message 5325 before indicating an error. 5327 IP-TTL: The value of the IP layer TTL that should be used when 5328 sending this message (may be overridden by GIST for particular 5329 messages). 5331 GIST-Hop-Count: The value for the hop count when sending the message. 5333 B.2. RecvMessage 5335 This primitive is passed from GIST to a signaling application. It is 5336 used whenever GIST receives a message from the network, including the 5337 case of null messages (zero length NSLP payload), typically initial 5338 Query messages. For Queries, the results of invoking this primitive 5339 are used by GIST to check whether message routing state should be 5340 created (see the discussion of the 'Routing-State-Check' argument 5341 below). 5343 RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLPID, Session-ID, MRI, 5344 Routing-State-Check, SII-Handle, Transfer-Attributes, 5345 IP-TTL, IP-Distance, GIST-Hop-Count, Inbound-Interface ) 5347 NSLP-Data: The NSLP message itself (may be empty). 5349 NSLP-Data-Size: The length of NSLP-Data (may be zero). 5351 NSLPID: An identifier indicating which NSLP this is message is for. 5353 Session-ID: The NSIS session identifier. 5355 MRI: Message routing information that was used by GIST in forwarding 5356 this message. Implicitly defines the message routing method that 5357 was used and the direction of the message relative to the MRI. 5359 Routing-State-Check: This boolean is True if GIST is checking with 5360 the signaling application to see if routing state should be 5361 created with the peer or the message should be forwarded further 5362 (see Section 4.3.2). If True, the signaling application should 5363 return the following values via the RecvMessage call: 5365 A boolean indicating whether to set up the state. 5367 Optionally, an NSLP-Payload to carry in the generated Response 5368 or forwarded Query respectively. 5370 This mechanism could be extended to enable the signaling 5371 application to indicate to GIST whether state installation should 5372 be immediate or deferred (see Section 5.3.3 and Section 6.3 for 5373 further discussion). 5375 SII-Handle: A handle to a data structure, identifying a peer address 5376 and interface. Can be used to identify route changes and for 5377 explicit routing to a particular GIST next hop. 5379 Transfer-Attributes: The reliability and security attributes that 5380 were associated with the reception of this particular message. As 5381 well as the attributes associated with SendMessage, GIST may 5382 indicate the level of verification of the addresses in the MRI. 5383 Three attributes can be indicated: 5385 * Whether the signaling source address is one of the flow 5386 endpoints (i.e. whether this is the first or last GIST hop); 5388 * Whether the signaling source address has been validated by a 5389 return routability check. 5391 * Whether the message was explicitly routed (and so has not been 5392 validated by GIST as delivered consistently with local routing 5393 state). 5395 IP-TTL: The value of the IP layer TTL this message was received with 5396 (if available). 5398 IP-Distance: The number of IP hops from the peer signaling node which 5399 sent this message along the path, or 0 if this information is not 5400 available. 5402 GIST-Hop-Count: The value of the hop count the message was received 5403 with, after being decremented in the GIST receive-side processing. 5405 Inbound-Interface: Attributes of the interface on which the message 5406 was received, such as whether it lies on the internal or external 5407 side of a NAT. These attributes have only local significance and 5408 are implementation defined. 5410 B.3. MessageStatus 5412 This primitive is passed from GIST to a signaling application. It is 5413 used to notify the signaling application that a message that it 5414 requested to be sent could not be dispatched, or to inform the 5415 signaling application about the transfer attributes that have been 5416 selected for the message (specifically, security attributes). The 5417 signaling application can respond to this message with a return code 5418 to abort the sending of the message if the attributes are not 5419 acceptable. 5421 MessageStatus (NSLP-Message-Handle, Transfer-Attributes, Error-Type) 5422 NSLP-Message-Handle: A handle for the message provided by the 5423 signaling application in SendMessage. 5425 Transfer-Attributes: The reliability and security attributes that 5426 will be used to transmit this particular message. 5428 Error-Type: Indicates the type of error that occurred. For example, 5429 'no next node found'. 5431 B.4. NetworkNotification 5433 This primitive is passed from GIST to a signaling application. It 5434 indicates that a network event of possible interest to the signaling 5435 application occurred. 5437 NetworkNotification ( NSLPID, MRI, Network-Notification-Type ) 5439 NSLPID: An identifier indicating which NSLP this is message is for. 5441 MRI: Provides the message routing information to which the network 5442 notification applies. 5444 Network-Notification-Type: Indicates the type of event that caused 5445 the notification and associated additional data. Two events have 5446 been identified: 5448 Last Node: GIST has detected that this is the last NSLP-aware node 5449 in the path. See Section 4.3.4. 5451 Routing Status Change: GIST has installed new routing state, or 5452 has detected that the routing state may no longer be valid, or 5453 has re-established the routing state. See Section 7.1.3. The 5454 new status is reported; if the status is Good, the SII-Handle 5455 of the peer is also reported, as for RecvMessage. 5457 B.5. SetStateLifetime 5459 This primitive is passed from a signaling application to GIST. It 5460 indicates the duration for which the signaling application would like 5461 GIST to retain its routing state. It can also give a hint that the 5462 signaling application is no longer interested in the state. 5464 SetStateLifetime ( NSLPID, MRI, State-Lifetime ) 5465 NSLPID: Provides the NSLPID to which the routing state lifetime 5466 applies. 5468 MRI: Provides the message routing information to which the routing 5469 state lifetime applies; includes the direction (in the D flag). 5471 State-Lifetime: Indicates the lifetime for which the signaling 5472 application wishes GIST to retain its routing state (may be zero, 5473 indicating that the signaling application has no further interest 5474 in the GIST state). 5476 B.6. InvalidateRoutingState 5478 This primitive is passed from a signaling application to GIST. It 5479 indicates that the signaling application has knowledge that the next 5480 signaling hop known to GIST may no longer be valid, either because of 5481 changes in the network routing or the processing capabilities of 5482 signaling application nodes. See Section 7.1. 5484 InvalidateRoutingState ( NSLPID, MRI, Status, Urgent ) 5486 NSLPID: The NSLP originating the message. May be null (in which case 5487 the invalidation applies to all signaling applications). 5489 MRI: The flow for which routing state should be invalidated; includes 5490 the direction of the change (in the D flag). 5492 Status: The new status that should be assumed for the routing state, 5493 one of Bad or Tentative (see Section 7.1.3). 5495 Urgent: A hint as to whether rediscovery should take place 5496 immediately, or only with the next signaling message. 5498 Appendix C. Example Routing State Table and Handshake Message Sequence 5500 Figure 10 shows a signaling scenario for a single flow being managed 5501 by two signaling applications using the path-coupled message routing 5502 method. The flow sender and receiver and one router support both, 5503 two other routers support one each. The figure also shows the 5504 routing state table at node B. 5506 A B C D E 5507 +------+ +-----+ +-----+ +-----+ +--------+ 5508 | Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow | 5509 |Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver| 5510 | | +-+ +-+ |GIST | |GIST | |GIST | | | 5511 +------+ +-----+ +-----+ +-----+ +--------+ 5512 Flow Direction ------------------------------>> 5514 +------------------------------------+---------+--------+-----------+ 5515 | Message Routing Information | Session | NSLPID | Routing | 5516 | | ID | | State | 5517 +------------------------------------+---------+--------+-----------+ 5518 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | IP-A | 5519 | {IP-A, IP-E, proto/ports}; D=up | | | | 5520 | | | | | 5521 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | (null) | 5522 | {IP-A, IP-E, proto/ports}; D=down | | | | 5523 | | | | | 5524 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | IP-A | 5525 | {IP-A, IP-E, proto/ports}; D=up | | | | 5526 | | | | | 5527 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | Points to | 5528 | {IP-A, IP-E, proto/ports}; D=down | | | B-D MA | 5529 +------------------------------------+---------+--------+-----------+ 5531 Figure 10: A Signaling Scenario 5533 The upstream state is just the same address for each application. 5534 For the downstream direction, NSLP1 only requires D-mode messages and 5535 so no explicit routing state towards C is needed. NSLP2 requires a 5536 messaging association for its messages towards node D, and node C 5537 does not process NSLP2 at all, so the peer state for NSLP2 is a 5538 pointer to a messaging association that runs directly from B to D. 5539 Note that E is not visible in the state table (except implicitly in 5540 the address in the message routing information); routing state is 5541 stored only for adjacent peers. (In addition to the peer 5542 identification, IP hop counts are stored for each peer where the 5543 state itself if not null; this is not shown in the table.) 5545 Figure 11 shows the message sequence for a GIST handshake that sets 5546 up the messaging association for B-D signaling. It shows the 5547 exchange of Stack Proposals and MA-protocol-options data in each 5548 direction. Then the Querying node selects TLS/TCP as the stack 5549 configuration to use and sets up the messaging association over which 5550 it sends the Confirm. 5552 -------------------------- Query ----------------------------> 5553 IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST) 5554 GIST(Header(Type=Query; NSLPID=NSLP2; R=1; S=0) 5555 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 5556 SessionID(0x1234) 5557 NLI(Peer='string1'; IA=IP#B) 5558 QueryCookie(0x139471239471923526) 5559 StackProposal(#Proposals=3;1=TLS/TCP; 2=TLS/SCTP; 3=TCP) 5560 StackConfigurationData(#MPO=2; 5561 TCP(Applicable: all; Data: null) 5562 SCTP(Applicable: all; Data: null))) 5564 <---------------------- Response ---------------------------- 5565 IP(Src=IP#D; Dst=IP#B); UDP(Src=GIST; Dst=6789) 5566 GIST(Header(Type=Response; NSLPID=NSLP2; R=1; S=1) 5567 MRI(MRM=Path-Coupled; Flow=F; Direction=up) 5568 SessionID(0x1234) 5569 NLI(Peer='stringr2', IA=IP#D) 5570 QueryCookie(0x139471239471923526) 5571 ResponderCookie(0xacdefedcdfaeeeded) 5572 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP) 5573 StackConfigurationData(#MPO=3; 5574 TCP(Applicable: 3; Data: port=6123) 5575 TCP(Applicable: 1; Data: port=5438) 5576 SCTP(Applicable: all; Data: port=3333))) 5578 -------------------------TCP SYN-----------------------> 5579 <----------------------TCP SYN/ACK---------------------- 5580 -------------------------TCP ACK-----------------------> 5581 TCP connect(IP Src=IP#B; IP Dst=IP#D; Src Port=9166; Dst Port=6123) 5582 <-----------------------TLS INIT-----------------------> 5584 ------------------------ Confirm ----------------------------> 5585 [Sent within messaging association] 5586 GIST(Header(Type=Confirm; NSLPID=NSLP2; R=0; S=1) 5587 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 5588 SessionID(0x1234) 5589 NLI(Peer='string1'; IA=IP#B) 5590 ResponderCookie(0xacdefedcdfaeeeded) 5591 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)) 5593 Figure 11: GIST Handshake Message Sequence 5595 Appendix D. Change History 5597 D.1. Changes In Version -10 5599 1. Added further guidance on parameter setting for initial backoff 5600 and rate control for D-mode to Section 5.3.3 [AD review comment 5601 M1]. 5603 2. Rephrased the end of Section 8.6 to highlight the threat left 5604 open when the Querying node does not apply a strong security 5605 policy to offered Stack-Proposal [AD review comment M2]. 5607 3. Clarified in Section 7.2 that although NAT behaviour is only 5608 informatively described in this specification, it is being 5609 defined in a separate document [AD review M3]. 5611 4. Strengthened and clarified the reference to the extensibility 5612 document for technical guidance on codepoint allocation, and 5613 made the reference normative. Added rationale for the 5614 'Reserved' blocks in the various registries, and added further 5615 notes on what information must be provided to support an 5616 allocation request [AD review comment M4]. 5618 5. Fixed an identifier collision in the ABNF for the GIST messages 5619 in Section 5.2.2 (Common-Header in the message header and 5620 common-header as a payload in error messages) and re-verified 5621 the ABNF [AD review comment L1]. 5623 6. Clarified the text in Section 3.3 about the impact on NATs of 5624 defining a new MRM, referring to the specification split 5625 described in Section 7.2.2. Also added a flag to the MRM format 5626 (Appendix A.3.1) to denote MRIs which do not contain network or 5627 transport addresses, and made more specific the error message to 5628 be returned if a NAT does not understand an MRM in Section 7.2.1 5629 [AD review comment L2]. 5631 7. Added discussion in Section 4.1.2 on delivery failure detected 5632 for reliable messaging in general, and for the case of Forwards- 5633 TCP in particular in Section 5.7.2. Also noted that this needs 5634 to be considered for future MA-Protocol-IDs used for reliable 5635 messaging (Section 9) [AD review comment L3]. 5637 8. Added clarifying text to Section 5.1 on what it means to invert 5638 the direction of an MRI [AD review comment L5]. 5640 9. Enhanced the format descriptions in Appendix A to include 5641 descriptions of all message and object fields and also field 5642 lengths [AD review comment L6]. 5644 10. Added more explanation in Section 5.2.2 of how a message 5645 direction is defined, in particular in the context of TTL 5646 measurement [AD review comment L7]. 5648 11. Added a new explanation of why a well-known port is needed for 5649 the query encapsulation in Section 5.3.2 [AD review comment L8]. 5651 12. Added a note that DCCP does not provide reliability in 5652 Section 5.4.1 [AD review comment L9]. 5654 13. Clarified the rules on how long to retain stack configuration 5655 data in Section 5.7.1 and included a default timer value [AD 5656 review comment L10]. 5658 14. Modified the text about stack-proposal verification as part of 5659 downgrade protection in Section 5.7.1, to clarify that the MUST 5660 applies directly to the object verification itself; also noted 5661 the action to be taken in case of a failed verification [AD 5662 review comment L11]. 5664 15. Added further information on the addressing used in opening a 5665 forwards-TCP connection in Section 5.7.2 [AD review comment 5666 L12]. 5668 16. Modified the text in Section 5.8.1.2 to say that using the 5669 signaling source address is a consequence of setting DF itself 5670 rather than why DF was set in the first place; also weakened the 5671 instruction from MUST to SHOULD [AD review comment L14]. 5673 17. Added further clarification of why routing state installed by a 5674 downstream Query should supersede that from an upstream Query in 5675 Section 5.8.1.3 [AD review comment L15]. 5677 18. Corrected a timer in the Messaging Association state machine 5678 (Section 6.4) from NoHello to SendHello. Also, added default 5679 values for MA-Hold-Time and route change probe frequency, and 5680 explanatory text for each, to Section 4.4.3 [AD review comment 5681 L16]. 5683 19. Re-arranged the text in Section 7.2 to highlight the rules about 5684 precisely which messages are and are not translated in a GIST- 5685 specific way by NATs [AD review comment L19]. 5687 20. Explicitly noted that 'r' bits are also reserved in Appendix A.2 5688 [AD review comment L20]. 5690 21. Added an error condition for processing messages which have the 5691 extensibility flags AB set to 11 in Appendix A.2.1 [AD review 5692 comment L21]. 5694 22. Fixed the table of MRM identifiers in Section 9 so the field 5695 name matches that in Appendix A.3.1 [AD review comment L22]. 5697 23. Clarified why only D=0 is valid for the loose-end MRM in 5698 Appendix A.3.1.2 [AD review comment L23]. 5700 24. Clarified the rules about processing the NAT traversal object in 5701 Appendix A.3.8 to cover the case where there are several NATs 5702 along the path with different capabilities [AD review comment 5703 L24]. 5705 25. Strengthened the text in Appendix A.4.1 to be clearer about what 5706 additional information fields must be included in error messages 5707 [AD review comment L25]. 5709 26. Tidied up the use of acronyms throughout the document, including 5710 adding some to the terminology list in Section 2 [AD review 5711 comment N1]. 5713 27. Added references to RFC4086 and updated 2119 language for 5714 cryptographic randomness of SIDs and cookies in Section 3.5 and 5715 Section 8.5 respectively [AD review comment N2]. 5717 28. Modified the transition labelling in Figure 7 to make it clearer 5718 that in the Established-Established transition, the 5719 [!confirmRequired] qualification applies only to the rx_Query 5720 case [AD review comment N4]. 5722 29. Added a reference for OSPF in Section 7.1.2 [AD review comment 5723 N5]. 5725 30. Changed NAT terminology from public/private to external/internal 5726 to match BEHAVE usage in Section 7.2 and Section 7.4 [AD review 5727 comment N6]. 5729 31. Updated a number of i-d references to published RFCs or working 5730 group documents [AD review comment N7 partial]. 5732 32. Fixed rfc2119 capitalisation of MUST not in Appendix A.3.5 [AD 5733 review comment N8]. 5735 33. Fixed an error subcode name from 'Invalid Object' to 'Invalid 5736 Object Type' in Appendix A.4.4.9 [AD review comment N9]. 5738 34. Added the NTO to the GIST message ABNF in Section 5.1 and 5739 updated the forward reference to the NAT traversal section 5741 [tracker issue 104]. 5743 35. Removed a spurious rule about creating listening MAs in 5744 Section 6.3 and strengthened the rules about needing to have 5745 these available but with an open policy on when to create and 5746 destroy them in Section 5.7.1 [tracker issue 105]. 5748 36. Added text that limits the applicability of the private/ 5749 experimental space to closed network environments [tracker issue 5750 106]. 5752 37. Added text in Section 7.1.4 encouraging GIST to use a single SII 5753 across multiple sessions if possible to allow signaling 5754 application aggregation [tracker issue 107]. 5756 38. Specified that this document would define GIST version 1 in 5757 Section 5.2.1 [tracker issue 108]. 5759 39. Added the ability for RecvMessage to pass up interface 5760 attributes in Appendix B.2 [tracker issue 110]. 5762 40. Added additional text on rules for selecting stack proposals and 5763 MA re-use in Section 5.7.1 to ensure that re-used associations 5764 have properties that the Querying node actually needs [tracker 5765 issue 111]. 5767 41. Added a brief introduction to the GIST message types in a new 5768 Section 3.4. 5770 In addition, the following AD review comments did not lead to text 5771 changes. See the mailing list discussion at 5772 http://www1.ietf.org/mail-archive/web/nsis/current/msg06307.html. 5774 L4: Direct use of PMTUD by GIST. 5776 L13: Use of TLS 1.0 rather than 1.1. 5778 L17: Guidance on NSLP behaviour during rerouting, 5780 L18: Behaviour of GIST-unaware NATs. 5782 N3: Node state machine logic. 5784 D.2. Changes In Version -09 5786 1. Added a new Section 3.6 clarifying the relationship between 5787 signaling applications and NSLPIDs; modified terminology in the 5788 remainder of the document likewise. 5790 2. Added a new Section 8.6 explaining the rationale behind the 5791 downgrade attack prevention mechanism. 5793 3. Re-wrote parts of Section 4.3.2, Section 6.1 and Appendix B.2 to 5794 clarify the way that GIST is assumed to interact with signaling 5795 applications to exercise policy control over whether or not two 5796 nodes become signaling peers during a GIST handshake. 5798 4. Generalised an error message Appendix A.4.4.12 to cover 5799 additional MRI validation checks in Section 4.3.4 and 5800 Section 5.8.1.2. 5802 5. Allowed an optional Stack-Configuration-Data object in Confirm 5803 messages to allow messaging association lifetime to be 5804 negotiated even in the case of late state installation at the 5805 Responding node (see Section 4.4.1 and Section 4.4.3). 5807 6. Removed the option in Section 4.4.2 of allowing a node to treat 5808 messaging associations with the same authenticated end points as 5809 equivalent. 5811 7. Include additional guidance in Section 4.4.3 to prevent routing 5812 state being erroneously refreshed in the case of rerouting 5813 events; also included general guidance notes on timer setting. 5815 8. Clarified that the Stack-Proposal lists protocols in top-to- 5816 bottom order (see Section 5.7.1). 5818 9. Enhanced the definition of TLS usage in Section 5.7.3 with 5819 details on ciphersuite requirements and authentication methods. 5821 10. Tidied up terminology and discussion of how protocol options 5822 data is carried in the SCD; renamed higher-layer-addressing to 5823 MA-protocol-options. 5825 D.3. Changes In Version -08 5827 1. Changed the protocol name from GIMPS to GIST (everywhere). 5829 2. Inserted RFC2119 language (MUST etc.) in the appropriate places. 5831 3. Added references to the actions to be taken in various error 5832 conditions, including the error messages to be send 5833 (throughout). 5835 4. Added legacy NAT traversal to the list of excluded functions in 5836 Section 1.1. 5838 5. Included some text at the end of Section 3.3 analysing the case 5839 of a GIST node which does not support a particular MRM. 5841 6. Added a flag to mark when messages have been explicitly routed, 5842 so they can bypass validation against current routing state (see 5843 Section 4.3.1, TBD). 5845 7. Re-wrote the discussion in Section 4.3.4 to cover all cases of 5846 nodes not hosting an NSLP (including end systems), in particular 5847 the validations that can be performed at intermediate GIST nodes 5848 (this replaces the old section 7.2). 5850 8. Clarified the rules about R and S flag setting in the common 5851 header and D flag in the MRI (Section 5). 5853 9. Included discussion of how a node with a choice of interfaces or 5854 IP versions should select one to use in the NLI (Section 5.2.2). 5856 10. Modified the description of messaging association protocol 5857 selections (Section 5.7 and elsewhere) to clarify that this is 5858 essentially capability discovery rather than an open ended 5859 protocol negotiation. 5861 11. Modified the description of how higher layer addressing 5862 information is carried (Section 5.7.1 and Appendix A.3.5) to 5863 allow the data to be tagged against a specific profile if 5864 necessary, or omitted if the protocol does not need it. 5866 12. Added a higher layer protocol definition for TLS in 5867 Section 5.7.3. 5869 13. Simplified and restructured the state machine presentation in 5870 Section 6, in particular using a single list for the events and 5871 eliminating the transition tables. Also modified the operation 5872 of the Responder machine to handle retransmitted Query messages 5873 correctly. 5875 14. Re-wrote the route change handling text in Section 7.1 to 5876 clarify the relative responsibilities of GIST and NSLPs and 5877 their interaction through the API. Notifications are now 5878 assumed to be a signaling application responsibility, and GIST 5879 behaviour is defined in terms of handling changes in a 3-state 5880 model of the correctness of the routing state for each 5881 direction. 5883 15. Updated the NAT traversal description in Section 7.2, including 5884 normative text about how GIST nodes should handle messages 5885 containing NAT-Traversal objects. 5887 16. Likewise, clarified that the responsibility for session/flow 5888 binding in the case of tunnelling is handled by NSLPs 5889 (Section 7.3). 5891 17. Formalised the IANA considerations (Section 9). 5893 18. Extended the routing state example (Appendix C) to include a 5894 message sequence for association setup. 5896 19. Re-arranged the sequence of sections, including placing this 5897 change history at the end. 5899 D.4. Changes In Version -07 5901 1. The open issues section has finally been removed in favour of the 5902 authoritative list of open issues in an online issue tracker at h 5903 ttp://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index. 5905 2. Clarified terminology on peering and adjacencies that there may 5906 be NSIS nodes between GIMPS peers that do some message 5907 processing, but that are not explicitly visible in the peer state 5908 tables. 5910 3. Added a description of the loose-end MRM (Section 5.8.2 and 5911 Appendix A.3.1.2). 5913 4. Added a description of an upstream Query encapsulation for the 5914 path-coupled MRM, Section 5.8.1.3, including rationale for and 5915 restrictions on its use. 5917 5. The formal description of the protocol in Section 6 has been 5918 significantly updated and extended in terms of detail. 5920 6. Modified the description of the interaction between NSLPs and 5921 GIMPS for handling inbound messages for which no routing state 5922 exists, to allow the NSLP to indicate whether state setup should 5923 proceed and to provide NSLP payloads for the Response or 5924 forwarded message (Section 3.7, Section 4.3.2 and Appendix B). 5926 7. Included new text, Section 5.6, on the processing and 5927 encapsulation of error messages. Also added formats and an error 5928 message catalogue in Appendix A.4, including a modified format 5929 for the overall GIMPS-Error message and the GIMPS-Error-Data 5930 object. 5932 8. Removed the old section 5.3.3 on NSLPID/RAO setting on the 5933 assumption that this will be covered in the extensibility 5934 document. 5936 9. Included a number of other minor corrections and clarifications. 5938 D.5. Changes In Version -06 5940 Version -06 does not introduce any major structural changes to the 5941 protocol definition, although it does clarify a number of details and 5942 resolve some outstanding open issues. The primary changes are as 5943 follows: 5945 1. Added a new high level Section 3.3 which gathers together the 5946 various aspects of the message routing method concept. 5948 2. Added a new high level Section 3.5 which explains the concept 5949 and significance of the session identifier. Also clarified that 5950 the routing state always depends on the session identifier. 5952 3. Added notes about the level of address validation performed by 5953 GIMPS in Section 4.1.2 and extensions to the API in Appendix B. 5955 4. Split the old Node-Addressing object into a Network-Layer- 5956 Information object and Stack-Configuration-Data object. The 5957 former refers to basic information about a node, and the latter 5958 carries information about messaging association configuration. 5959 Redefined the content of the various handshake messages 5960 accordingly in Section 4.4.1 and Section 5.1. 5962 5. Re-wrote Section 4.4.3 to clarify the rules on refresh and purge 5963 of routing state and messaging associations. Also, moved the 5964 routing state lifetime into the Network-Layer-Information object 5965 and added a messaging association lifetime to the Stack- 5966 Configuration-Data object (Section 5.2). 5968 6. Added specific message types for errors and MA-Refresh in 5969 Section 5.1. The error object is now GIMPS-specific 5970 (Appendix A.4.1). 5972 7. Moved the Flow-Identifier information about the message routing 5973 method from the general description of the object to the path- 5974 coupled MRM section (Section 5.8.1.1), and made a number of 5975 clarifications to the bit format (Appendix A.3.1.1). 5977 8. Removed text about assumptions on the version numbering of 5978 NSLPs, and restricted the scope of the description of TLV object 5979 formats and extensibility flags to GIMPS rather than the whole 5980 of NSIS (Appendix A). 5982 9. Added a new Section 5.5 explaining the possible relationships 5983 between message types and encapsulation formats. 5985 10. Added a new Section 6 in outline form, to capture the formal 5986 specification of the protocol operation. 5988 11. Added new security sections on cookie requirements (Section 8.5) 5989 and residual threats (Section 8.7). 5991 D.6. Changes In Version -05 5993 Version -05 reformulates the specification, to describe routing state 5994 maintenance in terms of exchanging explicitly identified Query/ 5995 Response/Confirm messages, leaving the upstream/downstream 5996 distinction as a specific detail of how Query messages are 5997 encapsulated. This necessitated widespread changes in the 5998 specification text, especially Section 4.2.1, Section 4.4, 5999 Section 5.1 and Section 5.3 (although the actual message sequences 6000 are unchanged). A number of other issues, especially in the area of 6001 message encapsulation, have also been closed. The main changes are 6002 the following: 6004 1. Added a reference to an individual draft on the Loose End MRM as 6005 a concrete example of an alternative message routing method. 6007 2. Added further text (particularly in Section 2) on what GIMPS 6008 means by the concept of 'session'. 6010 3. Firmed up the selection of UDP as the encapsulation choice for 6011 D-mode, removing the open issue on this topic. 6013 4. Defined the interaction between GIMPS and signaling applications 6014 for communicating about the cryptographic security properties of 6015 how a message will be sent or has been received (see 6016 Section 4.1.2 and Appendix B). 6018 5. Closed the issue on whether Query messages should use the 6019 signaling or flow source address in the IP header; both options 6020 are allowed by local policy and a flag in the common header 6021 indicates which was used. (See Section 5.8.1.2.) 6023 6. Added the necessary information elements to allow the IP hop 6024 count between adjacent GIMPS peers to be measures and reported. 6025 (See Section 5.2.2 and Appendix A.3.3.) 6027 7. The old open-issue text on selection of IP router alert option 6028 values has been moved into the main specification to capture the 6029 technical considerations that should be used in assigning such 6030 values (in old section 5.3.3). 6032 8. Resolved the open issue on lost Confirm messages by allowing a 6033 choice of timer-based retransmission of the Response, or an 6034 error message from the responding node which causes the 6035 retransmission of the Confirm (see Section 5.3.3). 6037 9. Closed the open issue on support for message scoping (this is 6038 now assumed to be a NSLP function). 6040 10. Moved the authoritative text for most of the remaining open 6041 issues to an online issue tracker. 6043 D.7. Changes In Version -04 6045 Version -04 includes mainly clarifications of detail and extensions 6046 in particular technical areas, in part to support ongoing 6047 implementation work. The main details are as follows: 6049 1. Substantially updated Section 4, in particular clarifying the 6050 rules on what messages are sent when and with what payloads 6051 during routing and messaging association setup, and also adding 6052 some further text on message transfer attributes. 6054 2. The description of messaging association protocol setup 6055 including the related object formats has been centralised in a 6056 new Section 5.7, removing the old Section 6.6 and also closing 6057 old open issues 8.5 and 8.6. 6059 3. Made a number of detailed changes in the message format 6060 definitions (Appendix A), as well as incorporating initial rules 6061 for encoding message extensibility information. Also included 6062 explicit formats for a general purpose Error object, and the 6063 objects used to discover supported messaging association 6064 protocols. Updated the corresponding open issues section (old 6065 section 9.3) with a new item on NSLP versioning. 6067 4. Updated the GIMPS API (Appendix B), including more precision on 6068 message transfer attributes, making the NSLP hint about storing 6069 reverse path state a return value rather than a separate 6070 primitive, and adding a new primitive to allow signaling 6071 applications to invalidate GIMPS routing state. Also, added a 6072 new parameter to SendMessage to allow signaling applications to 6073 'bypass' a message statelessly, preserving the source of an 6074 input message. 6076 5. Added an outline for the future content of an IANA 6077 considerations section (Section 9). Currently, this is 6078 restricted to identifying the registries and allocations 6079 required, without defining the allocation policies and other 6080 considerations involved. 6082 6. Shortened the background design discussion in Section 3. 6084 7. Made some clarifications in the terminology section relating to 6085 how the use of C-mode does and does not mandate the use of 6086 transport or security protection. 6088 8. The ABNF for message formats in Section 5.1 has been re-written 6089 with a grammar structured around message purpose rather than 6090 message direction, and additional explanation added to the 6091 information element descriptions in Section 5.2. 6093 9. The description of the D-mode transport in Section 5.3 has been 6094 updated. The encapsulation rules (covering IP addressing and 6095 UDP port allocation) have been corrected, and a new subsection 6096 on message retransmission and rate limiting has been added, 6097 superseding the old open issue on the same subject (section 6098 8.10). 6100 10. A new open issue on IP TTL measurement to detect non-GIMPS 6101 capable hops has been added (old section 9.5). 6103 D.8. Changes In Version -03 6105 Version -03 includes a number of minor clarifications and extensions 6106 compared to version -02, including more details of the GIMPS API and 6107 messaging association setup and the node addressing object. The full 6108 list of changes is as follows: 6110 1. Added a new section pinning down more formally the interaction 6111 between GIMPS and signaling applications (Section 4.1), in 6112 particular the message transfer attributes that signaling 6113 applications can use to control GIMPS (Section 4.1.2). 6115 2. Added a new open issue identifying where the interaction between 6116 the security properties of GIMPS and the security requirements of 6117 signaling applications should be identified (old section 9.10). 6119 3. Added some more text in Section 4.2.1 to clarify that GIMPS has 6120 the (sole) responsibility for generating the messages that 6121 refresh message routing state. 6123 4. Added more clarifying text and table to GHC and IP TTL handling 6124 discussion of Section 4.3.4. 6126 5. Split Section 4.4 into subsections for different scenarios, and 6127 added more detail on Node-Addressing object content and use to 6128 handle the case where association re-use is possible in 6129 Section 4.4.2. 6131 6. Added strawman object formats for Node-Addressing and Stack- 6132 Proposal objects in Section 5.1 and Appendix A. 6134 7. Added more detail on the bundling possibilities and appropriate 6135 configurations for various transport protocols in Section 5.4.1. 6137 8. Included some more details on NAT traversal in Section 7.2, 6138 including a new object to carry the untranslated address-bearing 6139 payloads, the NAT-Traversal object. 6141 9. Expanded the open issue discussion in old section 9.3 to include 6142 an outline set of extensibility flags. 6144 D.9. Changes In Version -02 6146 Version -02 does not represent any radical change in design or 6147 structure from version -01; the emphasis has been on adding details 6148 in some specific areas and incorporation of comments, including early 6149 review comments. The full list of changes is as follows: 6151 1. Added a new Section 1.1 which summarises restrictions on scope 6152 and applicability; some corresponding changes in terminology in 6153 Section 2. 6155 2. Closed the open issue on including explicit GIMPS state teardown 6156 functionality. On balance, it seems that the difficulty of 6157 specifying this correctly (especially taking account of the 6158 security issues in all scenarios) is not matched by the saving 6159 of state enabled. 6161 3. Removed the option of a special class of message transfer for 6162 reliable delivery of a single message. This can be implemented 6163 (inefficiently) as a degenerate case of C-mode if required. 6165 4. Extended Appendix A with a general discussion of rules for 6166 message and object formats across GIMPS and other NSLPs. Some 6167 remaining open issues are noted in old section 9.3 (since 6168 removed). 6170 5. Updated the discussion of RAO/NSLPID relationships to take into 6171 account the proposed message formats and rules for allocation of 6172 NSLP id, and propose considerations for allocation of RAO 6173 values. 6175 6. Modified the description of the information used to route 6176 messages (first given in Section 4.2.1 but also throughout the 6177 document). Previously this was related directly to the flow 6178 identification and described as the Flow-Routing-Information. 6179 Now, this has been renamed Message-Routing-Information, and 6180 identifies a message routing method and any associated 6181 addressing. 6183 7. Modified the text in Section 4.3 and elsewhere to impose sanity 6184 checks on the Message-Routing-Information carried in C-mode 6185 messages, including the case where these messages are part of a 6186 GIMPS-Query/Response exchange. 6188 8. Added rules for message forwarding to prevent message looping in 6189 a new Section 4.3.4, including rules on IP TTL and GIMPS hop 6190 count processing. These take into account the new RAO 6191 considerations described above. 6193 9. Added an outline mechanism for messaging association protocol 6194 stack setup, with the details in a new Section 6.6 and other 6195 changes in Section 4.4 and the various sections on message 6196 formats. 6198 10. Removed the open issue on whether storing reverse routing state 6199 is mandatory or optional. This is now explicit in the API 6200 (under the control of the local NSLP). 6202 11. Added an informative annex describing an abstract API between 6203 GIMPS and NSLPs in Appendix B. 6205 D.10. Changes In Version -01 6207 The major change in version -01 is the elimination of 6208 'intermediaries', i.e. imposing the constraint that signaling 6209 application peers are also GIMPS peers. This has the consequence 6210 that if a signaling application wishes to use two classes of 6211 signaling transport for a given flow, maybe reaching different 6212 subsets of nodes, it must do so by running different signaling 6213 sessions; and it also means that signaling adaptations for passing 6214 through NATs which are not signaling application aware must be 6215 carried out in D-mode. On the other hand, it allows the elimination 6216 of significant complexity in the C-mode handling and also various 6217 other protocol features (such as general route recording). 6219 The full set of changes is as follows: 6221 1. Added a worked example in Section 3.7. 6223 2. Stated that nodes which do not implement the signaling 6224 application should bypass the message (Section 4.3). 6226 3. Decoupled the state handling logic for routing state and 6227 messaging association state in Section 4.4. Also, allow 6228 messaging associations to be used immediately in both directions 6229 once they are opened. 6231 4. Added simple ABNF for the various GIMPS message types in a new 6232 Section 5.1, and more details of the common header and each 6233 object in Section 5.2, including bit formats in Appendix A. The 6234 common header format means that the encapsulation is now the 6235 same for all transport types (Section 5.4.1). 6237 5. Added some further details on D-mode encapsulation in 6238 Section 5.3, including more explanation of why a well known port 6239 is needed. 6241 6. Removed the possibility for fragmentation over DCCP 6242 (Section 5.4.1), mainly in the interests of simplicity and loss 6243 amplification. 6245 7. Removed all the tunnel mode encapsulations (old sections 5.3.3 6246 and 5.3.4). 6248 8. Fully re-wrote the route change handling description 6249 (Section 7.1), including some additional detection mechanisms 6250 and more clearly distinguishing between upstream and downstream 6251 route changes. Included further details on GIMPS/NSLP 6252 interactions, including where notifications are delivered and 6253 how local repair storms could be avoided. Removed old 6254 discussion of propagating notifications through signaling 6255 application unaware nodes (since these are now bypassed 6256 automatically). Added discussion on how to route messages for 6257 local state removal on the old path. 6259 9. Revised discussion of policy-based forwarding (old Section 7.2) 6260 to account for actual Flow-Routing-Information definition, and 6261 also how wildcarding should be allowed and handled. 6263 10. Removed old route recording section (old Section 6.3). 6265 11. Extended the discussion of NAT handling (Section 7.2) with an 6266 extended outline on processing rules at a GIMPS-aware NAT and a 6267 pointer to implications for C-mode processing and state 6268 management. 6270 12. Clarified the definition of 'correct routing' of signaling 6271 messages in Section 8 and GIMPS role in enforcing this. Also, 6272 opened the possibility that peer node authentication could be 6273 signaling application dependent. 6275 13. Removed old open issues on C-mode Encapsulation (section 8.7); 6276 added new open issues on Message Routing (old Section 9.3 of 6277 version -05, later moved to Section 3.3) and D-mode congestion 6278 control. 6280 14. Added this change history. 6282 Authors' Addresses 6284 Henning Schulzrinne 6285 Columbia University 6286 Department of Computer Science 6287 450 Computer Science Building 6288 New York, NY 10027 6289 US 6291 Phone: +1 212 939 7042 6292 Email: hgs+nsis@cs.columbia.edu 6293 URI: http://www.cs.columbia.edu 6295 Robert Hancock 6296 Siemens/Roke Manor Research 6297 Old Salisbury Lane 6298 Romsey, Hampshire SO51 0ZN 6299 UK 6301 Email: robert.hancock@roke.co.uk 6302 URI: http://www.roke.co.uk 6304 Intellectual Property Statement 6306 The IETF takes no position regarding the validity or scope of any 6307 Intellectual Property Rights or other rights that might be claimed to 6308 pertain to the implementation or use of the technology described in 6309 this document or the extent to which any license under such rights 6310 might or might not be available; nor does it represent that it has 6311 made any independent effort to identify any such rights. Information 6312 on the procedures with respect to rights in RFC documents can be 6313 found in BCP 78 and BCP 79. 6315 Copies of IPR disclosures made to the IETF Secretariat and any 6316 assurances of licenses to be made available, or the result of an 6317 attempt made to obtain a general license or permission for the use of 6318 such proprietary rights by implementers or users of this 6319 specification can be obtained from the IETF on-line IPR repository at 6320 http://www.ietf.org/ipr. 6322 The IETF invites any interested party to bring to its attention any 6323 copyrights, patents or patent applications, or other proprietary 6324 rights that may cover technology that may be required to implement 6325 this standard. Please address the information to the IETF at 6326 ietf-ipr@ietf.org. 6328 Disclaimer of Validity 6330 This document and the information contained herein are provided on an 6331 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 6332 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 6333 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 6334 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 6335 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 6336 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6338 Copyright Statement 6340 Copyright (C) The Internet Society (2006). This document is subject 6341 to the rights, licenses and restrictions contained in BCP 78, and 6342 except as set forth therein, the authors retain all their rights. 6344 Acknowledgment 6346 Funding for the RFC Editor function is currently provided by the 6347 Internet Society.