idnits 2.17.1 draft-ietf-nsis-ntlp-08.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 5623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5613. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o whether the peer still wants the association in place. During messaging association setup, each node indicates its own MA-hold-time as part of the Stack-Configuration-Data; the node MUST not tear down the association if it has received traffic from its peer over that period. A peer which has generated no traffic but still wants the association retained SHOULD use a special 'null' message (GIST-MA-Hello) to indicate the fact. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MA-Protocol-ID | Proposal | Length |D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Higher-Layer-Addressing // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MA-Protocol-ID = Protocol identifier as described in Section 5.7 . Proposal = Tag indicating which proposal from the accompanying Stack-Proposal object this applies to. Proposals are numbered from 1 upwards; the special value 0 indicates 'applies to all proposals'. Length = the byte length of higher layer addressing information that follows. This will be zero-padded up to the next word boundary. D flag = If set (D=1), this protocol MUST not be used for a messaging assocation. -- 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 (September 27, 2005) is 6757 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 250 -- Looks like a reference, but probably isn't: 'Flow' on line 262 -- Looks like a reference, but probably isn't: 'Adjacent' on line 272 -- Looks like a reference, but probably isn't: 'Initialisation' on line 2762 == Unused Reference: '11' is defined on line 3921, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 3942, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 3949, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 3957, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 4008, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2765 (ref. '6') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2246 (ref. '7') (Obsoleted by RFC 4346) ** Downref: Normative reference to an Historic draft: draft-ietf-tls-rfc2246-bis (ref. '8') -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '10') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '11') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '13') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. '16') (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '22') (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 3682 (ref. '23') (Obsoleted by RFC 5082) == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-11 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-07 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-07 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-03 == Outdated reference: A later version (-02) exists of draft-loughney-nsis-ext-01 Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 17 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: March 31, 2006 R. Hancock 5 Siemens/RMR 6 September 27, 2005 8 GIST: General Internet Signaling Transport 9 draft-ietf-nsis-ntlp-08 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 March 31, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document specifies protocol stacks for the routing and transport 43 of per-flow signaling messages along the path taken by that flow 44 through the network. The design uses existing transport and security 45 protocols under a common messaging layer, the General Internet 46 Signaling Transport (GIST), which provides a universal service for 47 diverse signaling applications. GIST does not handle signaling 48 application state itself, but manages its own internal state and the 49 configuration of the underlying transport and security protocols to 50 enable the transfer of messages in both directions along the flow 51 path. The combination of GIST and the lower layer transport and 52 security protocols provides a solution for the base protocol 53 component of the "Next Steps in Signaling" framework. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Restrictions on Scope . . . . . . . . . . . . . . . . . . 5 59 2. Requirements Notation and Terminology . . . . . . . . . . . . 6 60 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 8 62 3.2. Modes and Messaging Associations . . . . . . . . . . . . 9 63 3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 10 64 3.4. Signaling Sessions . . . . . . . . . . . . . . . . . . . 12 65 3.5. Example of Operation . . . . . . . . . . . . . . . . . . 13 66 4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 16 67 4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 16 68 4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 18 69 4.3. Basic Message Processing . . . . . . . . . . . . . . . . 19 70 4.4. Routing State and Messaging Association Maintenance . . . 25 71 5. Message Formats and Transport . . . . . . . . . . . . . . . . 31 72 5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 31 73 5.2. Information Elements . . . . . . . . . . . . . . . . . . 33 74 5.3. Datagram Mode Transport . . . . . . . . . . . . . . . . . 37 75 5.4. Connection Mode Transport . . . . . . . . . . . . . . . . 39 76 5.5. Message Type/Encapsulation Relationships . . . . . . . . 41 77 5.6. Error Message Processing . . . . . . . . . . . . . . . . 42 78 5.7. Messaging Association Setup . . . . . . . . . . . . . . . 43 79 5.8. Specific Message Routing Methods . . . . . . . . . . . . 45 80 6. Formal Protocol Specification . . . . . . . . . . . . . . . . 51 81 6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 52 82 6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 54 83 6.3. Responder Node Processing . . . . . . . . . . . . . . . . 57 84 6.4. Messaging Association Processing . . . . . . . . . . . . 60 85 7. Advanced Protocol Features . . . . . . . . . . . . . . . . . 63 86 7.1. Route Changes and Local Repair . . . . . . . . . . . . . 63 87 7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 69 88 7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 72 89 7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 73 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 75 91 8.1. Message Confidentiality and Integrity . . . . . . . . . . 75 92 8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 76 93 8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 76 94 8.4. Denial of Service Prevention . . . . . . . . . . . . . . 78 95 8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 79 96 8.6. Residual Threats . . . . . . . . . . . . . . . . . . . . 80 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 87 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 88 101 11.2. Informative References . . . . . . . . . . . . . . . . . 88 102 Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 91 103 A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 91 104 A.2. General Object Format . . . . . . . . . . . . . . . . . . 92 105 A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 93 106 A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 100 107 Appendix B. API between GIST and NSLP . . . . . . . . . . . . . 108 108 B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 108 109 B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 109 110 B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 111 111 B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 111 112 B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 112 113 B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 112 114 Appendix C. Example Routing State Table and Handshake Message 115 Sequence . . . . . . . . . . . . . . . . . . . . . . 113 116 Appendix D. Change History . . . . . . . . . . . . . . . . . . . 115 117 D.1. Changes In Version -08 . . . . . . . . . . . . . . . . . 115 118 D.2. Changes In Version -07 . . . . . . . . . . . . . . . . . 116 119 D.3. Changes In Version -06 . . . . . . . . . . . . . . . . . 117 120 D.4. Changes In Version -05 . . . . . . . . . . . . . . . . . 118 121 D.5. Changes In Version -04 . . . . . . . . . . . . . . . . . 119 122 D.6. Changes In Version -03 . . . . . . . . . . . . . . . . . 120 123 D.7. Changes In Version -02 . . . . . . . . . . . . . . . . . 121 124 D.8. Changes In Version -01 . . . . . . . . . . . . . . . . . 122 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125 126 Intellectual Property and Copyright Statements . . . . . . . . . 126 128 1. Introduction 130 Signaling involves the manipulation of state held in network 131 elements. 'Manipulation' could mean setting up, modifying and 132 tearing down state; or it could simply mean the monitoring of state 133 which is managed by other mechanisms. 135 This specification concentrates on "path-coupled" signaling, which 136 involves network elements which are located on the path taken by a 137 particular data flow, possibly including but not limited to the flow 138 endpoints. Indeed, there are almost always more than two 139 participants in a path-coupled signaling session, although there is 140 no need for every node on the path to participate. Path-coupled 141 signaling thus excludes end-to-end higher-layer application signaling 142 (except as a degenerate case) such as ISUP (telephony signaling for 143 Signaling System #7) messages being transported by SCTP between two 144 nodes. 146 In the context of path-coupled signaling, examples of state 147 management include network resource allocation (for "resource 148 reservation"), firewall configuration, and state used in active 149 networking; examples of state monitoring are the discovery of 150 instantaneous path properties (such as available bandwidth, or 151 cumulative queuing delay). Each of these different uses of path- 152 coupled signaling is referred to as a signaling application. 154 Every signaling application requires a set of state management rules, 155 as well as protocol support to exchange messages along the data path. 156 Several aspects of this protocol support are common to all or a large 157 number of signaling applications, and hence can be developed as a 158 common protocol. The NSIS framework given in [24] provides a 159 rationale for a function split between the common and application 160 specific protocols, and gives outline requirements for the former, 161 the 'NSIS Transport Layer Protocol' (NTLP). 163 This specification provides a concrete solution for the NTLP. It is 164 based on the use of existing transport and security protocols under a 165 common messaging layer, the General Internet Signaling Transport 166 (GIST). GIST does not handle signaling application state itself; in 167 that crucial respect, it differs from application signaling protocols 168 such as SIP, RTSP, and the control component of FTP. Instead, GIST 169 manages its own internal state and the configuration of the 170 underlying transport and security protocols to ensure the transfer of 171 signaling messages on behalf of signaling applications in both 172 directions along the flow path. 174 The structure of this specification is as follows. Section 2 defines 175 terminology, and Section 3 gives an informal overview of the protocol 176 design principles and operation. The normative specification is 177 contained mainly in Section 4 to Section 8. Section 3 describes the 178 message sequences and Section 5 their format and contents (note that 179 the detailed bit formats are given in Appendix A). The protocol 180 operation is captured in the form of state machine language in 181 Section 6. Section 7 describes some particular more advanced 182 protocol features and security considerations are contained in 183 Section 8. In addition, Section 9 gives the IANA considerations, 184 Appendix C an example message flow, and Appendix B describes an 185 abstract API for the service which GIST provides to signaling 186 applications. 188 1.1. Restrictions on Scope 190 This section briefly lists some important restrictions on GIST 191 applicability and functionality. In some cases, these are implicit 192 consequences of the functionality split developed in the NSIS 193 framework; in others, they are restrictions on the types of scenario 194 in which GIST can operate correctly. 196 Flow splitting: In some cases, e.g. where packet-level load sharing 197 has been implemented, the path taken by a single flow in the 198 network may not be well defined. If this is the case, GIST cannot 199 route signaling meaningfully. (In some circumstances, GIST 200 implementations could detect this condition, but even this cannot 201 be guaranteed.) 203 Multicast: GIST does not handle multicast flows. This includes 204 'classical' IP multicast and any of the 'small group multicast' 205 schemes recently proposed. 207 Legacy NATs: GIST messages will generally pass through NATs, but 208 unless the NAT is GIST-aware, any addressing data carried in the 209 payload will not be handled correctly. There is a dual problem of 210 whether the GIST peers either side of the boundary can work out 211 how to address each other, and whether they can work out what 212 translation to apply to their payloads what is done to the 213 signaling packet headers. The fundamental problem is that GIST 214 messages contain 3 or 4 interdependent addresses which all have to 215 be consistently translated, and existing generic NAT traversal 216 techniques such as STUN [22] or TURN can process only two. 217 (Appropriate behaviour for a GIST-aware NAT is discussed in 218 Section 7.2.) 220 2. Requirements Notation and Terminology 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in [2]. 226 The terminology used in this specification is fully defined in this 227 section. The basic entities relevant at the GIST level are shown in 228 Figure 1. 230 Source GIST (adjacent) peer nodes Destination 232 IP address IP addresses = Signaling IP address 233 = Flow Source/Destination Addresses = Flow 234 Source (depending on signaling direction) Destination 235 Address | | Address 236 V V 237 +--------+ +------+ Data Flow +------+ +--------+ 238 | Flow |-----------|------|-------------|------|-------->| Flow | 239 | Sender | | | | | |Receiver| 240 +--------+ | GIST |============>| GIST | +--------+ 241 | Node |<============| Node | 242 +------+ Signaling +------+ 243 GN1 Flow GN2 245 >>>>>>>>>>>>>>>>> = Downstream direction 246 <<<<<<<<<<<<<<<<< = Upstream direction 248 Figure 1: Basic Terminology 250 [Data] Flow: A set of packets identified by some fixed combination of 251 header fields. Flows are unidirectional (a bidirectional 252 communication is considered a pair of unidirectional flows). 254 Session: A single application layer flow of information for which 255 some state information is to be manipulated or monitored. See 256 Section 3.4 for further detailed discussion. 258 [Flow] Sender: The node in the network which is the source of the 259 packets in a flow. Could be a host, or a router (e.g. if the flow 260 is actually an aggregate). 262 [Flow] Receiver: The node in the network which is the sink for the 263 packets in a flow. 265 Downstream: In the same direction as the data flow. 267 Upstream: In the opposite direction to the data flow. 269 GIST Node: Any node along the data path supporting GIST (regardless 270 of what signaling applications it supports). 272 [Adjacent] Peer: The next node along the data path, in the upstream 273 or downstream direction, with which a GIST node explicitly 274 interacts. The GIST peer discovery mechanisms implicitly 275 determine whether two nodes will be adjacent. It is possible for 276 adjacencies to 'skip over' intermediate nodes which decide not to 277 take part in the signaling exchange at the NTLP layer; even if 278 such nodes process parts of the signaling messages, they store no 279 state about the session and are never explicitly visible at the 280 GIST level to the nodes either side. 282 Datagram Mode: A mode of sending GIST messages between nodes without 283 using any transport layer state or security protection. Datagram 284 mode uses UDP encapsulation, with IP addresses derived either from 285 the flow definition or previously discovered adjacency 286 information. 288 Connection Mode: A mode of sending GIST messages directly between 289 nodes using point to point "messaging associations" (see below). 290 Connection mode allows the re-use of existing transport and 291 security protocols where such functionality is required. 293 Messaging Association: A single connection between two explicitly 294 identified GIST adjacent peers, i.e. between a given signaling 295 source and destination address. A messaging association may use a 296 specific transport protocol and known ports. If security 297 protection is required, it may use a specific network layer 298 security association, or use a transport layer security 299 association internally. A messaging association is bidirectional; 300 signaling messages can be sent over it in either direction, and 301 can refer to flows of either direction. 303 Message Routing Method: Even in the path-coupled case, there can be 304 different algorithms for discovering the route that signaling 305 messages should take. These are referred to as message routing 306 methods, and GIST supports alternatives within a common protocol 307 framework. See Section 3.3. 309 Transfer Attributes: A description of the requirements which a 310 signaling application has for the delivery of a particular 311 message; for example, whether the message should be delivered 312 reliably. See Section 4.1.2. 314 3. Design Overview 316 3.1. Overall Design Approach 318 The generic requirements identified in the NSIS framework [24] for 319 transport of path-coupled signaling messages are essentially two- 320 fold: 322 "Routing": Determine how to reach the adjacent signaling node along 323 each direction of the data path (the GIST peer), and if necessary 324 explicitly establish addressing and identity information about 325 that peer; 327 "Transport": Deliver the signaling information to that peer. 329 To meet the routing requirement, one possibility is for the node to 330 use local routing state information to determine the identity of the 331 GIST peer explicitly. GIST defines a 3-way handshake (Query/ 332 Response/optional Confirm) which sets up the necessary routing state 333 between adjacent peers, during which signaling application data can 334 also be exchanged; the Query message is encapsulated in a special 335 way, depending on the message routing method, in order to probe the 336 network infrastructure so that the correct peer will intercept it. 337 If the routing state does not exist, it may be possible for GIST to 338 send a message anyway, with the same encapsulation as used for a 339 Query message. 341 Once the routing decision has been made, the node has to select a 342 mechanism for transport of the message to the peer. GIST divides the 343 transport problems into two categories, the easy and the difficult. 344 It handles the easy cases internally, and uses well-understood 345 transport protocols for the harder cases. Here, with details 346 discussed later, "easy" messages are those that are sized well below 347 the lowest MTU along a path, are infrequent enough not to cause 348 concerns about congestion and flow control, and do not need security 349 protection or guaranteed delivery. 351 In [24] all of these routing and transport requirements are assigned 352 to a single notional protocol, the 'NSIS Transport Layer Protocol' 353 (NTLP). The strategy of splitting the transport problem leads to a 354 layered structure for the NTLP, as a specialised GIST 'messaging' 355 layer running over standard transport and security protocols, as 356 shown in Figure 2. This also shows GIST offering its services to 357 upper layers at an abstract interface, the GIST API, further 358 discussed in Section 4.1. 360 ^^ +-------------+ 361 || | Signaling | 362 NSIS +------------|Application 2| 363 Signaling | Signaling +-------------+ 364 Application |Application 1| | 365 Level +-------------+ | 366 || | | 367 VV | | 368 =========|===================|===== <-- GIST API 369 | | 370 ^^ +------------------------------------------------+ 371 || |+-----------------------+ +--------------+ | 372 || || GIST | | GIST State | | 373 || || Encapsulation |<<<>>>| Maintenance | | 374 || |+-----------------------+ +--------------+ | 375 || | GIST: Messaging Layer | 376 || +------------------------------------------------+ 377 NSIS | | | | 378 Transport ............................. 379 Level . Transport Layer Security . 380 ("NTLP") ............................. 381 || | | | | 382 || +----+ +----+ +----+ +----+ 383 || |UDP | |TCP | |SCTP| |DCCP|.... 384 || +----+ +----+ +----+ +----+ 385 || | | | | 386 || ............................. 387 || . IP Layer Security . 388 || ............................. 389 VV | | | | 390 =========================|=======|=======|=======|=============== 391 | | | | 392 +----------------------------------------------+ 393 | IP | 394 +----------------------------------------------+ 396 Figure 2: Protocol Stacks for Signaling Transport 398 3.2. Modes and Messaging Associations 400 Internally, GIST has two modes of operation: 402 Datagram mode ('D mode') is used for small, infrequent messages with 403 modest delay constraints; it is also used at least for the Query 404 message of the 3-way handshake. 406 Connection mode ('C mode') is used for larger data objects or where 407 fast state setup in the face of packet loss is desirable, or where 408 channel security is required. 410 Datagram mode uses UDP, as this is the only encapsulation which does 411 not require per-message shared state to be maintained between the 412 peers. The connection mode can in principal use any stream or 413 message-oriented transport protocol; this specification defines TCP 414 as the initial choice. It can in principal employ specific network 415 layer security associations, or an internal transport layer security 416 association; this specification defines TLS as the initial choice. 417 When GIST messages are carried in connection mode, they are treated 418 just like any other traffic by intermediate routers between the GIST 419 peers. Indeed, it would be impossible for intermediate routers to 420 carry out any processing on the messages without terminating the 421 transport and security protocols used. 423 It is possible to mix these two modes along a path. This allows, for 424 example, the use of datagram mode at the edges of the network and 425 connection mode in the core of the network. Such combinations may 426 make operation more efficient for mobile endpoints, while allowing 427 multiplexing of signaling messages across shared security 428 associations and transport connections between core routers. 430 It must be understood that the routing and transport decisions made 431 by GIST are not independent. If the message transfer has 432 requirements that require connection mode (e.g. the message is so 433 large that fragmentation is required), this can only be used between 434 explicitly identified nodes. In such cases, GIST carries out the 435 3-way handshake initially in datagram mode to identify the peer and 436 then sets up the necessary connections if they do not already exist. 437 It must also be understood that the signaling application does not 438 make the D/C mode selection directly; rather, this decision is made 439 by GIST on the basis of the message characteristics and the transfer 440 attributes stated by the application. The distinction is not visible 441 at the GIST service interface. 443 In general, the state associated with connection mode messaging to a 444 particular peer (signaling destination address, protocol and port 445 numbers, internal protocol configuration and state information) is 446 referred to as a "messaging association". There may be any number of 447 messaging associations between two GIST peers (although the usual 448 case is 0 or 1), and they are set up and torn down by management 449 actions within GIST itself. 451 3.3. Message Routing Methods 453 The baseline message routing functionality in GIST is that signaling 454 messages follow a route defined by an existing flow in the network, 455 visiting a subset of the nodes through which it passes. This is the 456 appropriate behaviour for application scenarios where the purpose of 457 the signaling is to manipulate resources for that flow. However, 458 there are scenarios for which other behaviours are applicable. Two 459 examples are: 461 Predictive Routing: Here, the intent is to send signaling along a 462 path that the data flow may or will follow in the future. 463 Possible cases are pre-installation of state on the backup path 464 that would be used in the event of a link failure; and predictive 465 installation of state on the path that will be used after a mobile 466 node handover. 468 NAT Address Reservations: This applies to the case where a node 469 behind a NAT wishes to reserve an address at which it can be 470 reached by a sender on the other side. This requires a message to 471 be sent outbound from what will be the flow receiver although no 472 reverse routing state for the flow yet exists. 474 Most of the details of GIST operation are independent of which 475 alternative is being used. Therefore, the GIST design encapsulates 476 the routing-dependent details as a message routing method (MRM), and 477 allows multiple MRMs to be defined. The default is the path-coupled 478 MRM, which corresponds to the baseline functionality described above; 479 a second MRM for the NAT Address Reservation case is also defined. 481 The content of a MRM definition is as follows, using the path-coupled 482 MRM as an example: 484 o The format of the information that describes the path that the 485 signaling should take, the Message Routing Information (MRI). For 486 the path-coupled MRM, this is just the Flow Identifier (see 487 Section 5.8.1.1) and some additional control information. 488 Specifically, the MRI always includes a flag to distinguish 489 between the two directions that signaling messages can take, 490 denoted 'upstream' and 'downstream'. 492 o A specification of the IP level encapsulation of the Query 493 messages which probe the network to discover the adjacent peers. 494 A downstream encapsulation must be defined; an upstream 495 encapsulation is optional. For the path-coupled MRM, this 496 information is given in Section 5.8.1.2 and Section 5.8.1.3. 498 o A specification of what validation checks GIST should apply to the 499 probe messages, for example to protect against IP address spoofing 500 attacks. The checks may be dependent on the direction (upstream/ 501 downstream) of the message. For the path-coupled MRM, the 502 downstream validity check is basically a form of ingress 503 filtering, also discussed in Section 5.8.1.2. 505 o The mechanism(s) available for route change detection, i.e. any 506 change in the neighbour relationships that the MRM discovers. The 507 default case for any MRM is soft-state refresh, but additional 508 supporting techniques may be possible; see Section 7.1.2. 510 In addition, it should be noted that NAT traversal almost certainly 511 requires transformation of the MRI field in GIST messages (see 512 Section 7.2). Although the transformation does not have to be 513 defined as part of the standard, the impact on existing GIST-aware 514 NAT implementations should be considered. 516 The MRI is passed explicitly between signaling applications and GIST; 517 therefore, NSLP specifications must define which MRMs they require 518 (they may use more than one, e.g. depending on the type of message). 519 NSLPs may use fields in the MRI in their packet classifiers; if they 520 use additional information for packet classification, this would be 521 carried at the NSLP level and so would be invisible to GIST. Any 522 node hosting a particular signaling application MUST use a GIST 523 implementation that supports the corresponding MRMs. The GIST 524 processing rules enforce that nodes which do not host the NSLP are 525 not forced to handle messages for it at the GIST level, so it does 526 not matter if they support the MRM or not. 528 3.4. Signaling Sessions 530 GIST allows signaling applications to associate each message with a 531 "signaling session". Informally, given an application layer exchange 532 of information for which some network control state information is to 533 be manipulated or monitored, the corresponding signaling messages 534 should be associated with the same session. Signaling applications 535 provide the session identifier (SID) whenever they wish to send a 536 message, and GIST reports the SID when a message is received. 538 Most GIST processing and state information is related to the flow 539 (defined by the MRI, see above) and NSLPID. There are several 540 possible relationships between flows and sessions, for example: 542 o The simplest case is that all messages for the same flow have the 543 same SID. 545 o Messages for more than one flow may use the same SID, for example 546 because one flow is replacing another in a mobility or multihoming 547 scenario. 549 o A single flow may have messages for different SIDs, for example 550 from independently operating signaling applications. 552 Because of this range of options, GIST does not perform any 553 validation on how signaling applications map between flows and 554 sessions, nor does it perform any validation on the properties of the 555 SID itself. In particular, when a new SID is needed, logically it 556 should be generated by the NSLP. (NSIS implementations could provide 557 common functionality to generate SIDs for use by any NSLP, but this 558 is not part of GIST.) GIST only defines the syntax of the SID as an 559 opaque 128-bit number. 561 The SID assignment has the following impact on GIST processing: 563 o Messages with the same SID to be delivered reliably between the 564 same GIST peers are delivered in order. 566 o All other messagse are handled independently. 568 o GIST identifies routing state (upstream and downstream peer) by 569 the triplet (MRI, NSLPID, SID). 571 Strictly, the routing state should not depend on the SID. However, 572 if the routing state is keyed only by (MRI, NSLPID) there is a 573 trivial denial of service attack (see Section 8.3) where a malicious 574 off-path node asserts that it is the peer for a particular flow. 575 Instead, the routing state is also segregated between different SIDs, 576 which means that the attacking node can only disrupt a signaling 577 session if it can guess the corresponding SID. A consequence of this 578 design is that signaling applications should choose SIDs so that they 579 are cryptographically random, and should not use several SIDs for the 580 same flow unless strictly necessary, to avoid additional load from 581 routing state maintenance. 583 3.5. Example of Operation 585 This section presents an example of GIST usage in a relatively simple 586 (in particular, NAT-free) signaling scenario, to illustrate its main 587 features. 589 Consider the case of an RSVP-like signaling application which 590 allocates resources for a single unicast flow. We will consider how 591 GIST transfers messages between two adjacent peers along the path, 592 GN1 and GN2 (see Figure 1). In this example, the end-to-end exchange 593 is initiated by the signaling application instance in the sender; we 594 take up the story at the point where the first message is being 595 processed (above the GIST layer) by the signaling application in GN1. 597 1. The signaling application in GN1 determines that this message is 598 a simple description of resources that would be appropriate for 599 the flow. It determines that it has no special security or 600 transport requirements for the message, but simply that it should 601 be transferred to the next downstream signaling application peer 602 on the path that the flow will take. 604 2. The message payload is passed to the GIST layer in GN1, along 605 with a definition of the flow and description of the message 606 transfer attributes {unsecured, unreliable}. GIST determines 607 that this particular message does not require fragmentation and 608 that it has no knowledge of the next peer for this flow and 609 signaling application; however, it also determines that this 610 application is likely to require secured upstream and downstream 611 transport of large messages in the future. This determination is 612 a function of node-local policy; see Appendix B for some 613 additional discussion. 615 3. GN1 therefore constructs a GIST-Query message, which is a UDP 616 datagram carrying the signaling application payload and 617 additional payloads at the GIST level to be used to initiate the 618 setup of a messaging association. The Query is injected into the 619 network, addressed towards the flow destination and with a Router 620 Alert Option included. 622 4. The Query message passes through the network towards the flow 623 receiver, and is seen by each router in turn. GIST-unaware 624 routers will not recognise the RAO value and will forward the 625 message unchanged; GIST-aware routers which do not support the 626 signaling application in question will also forward the message 627 basically unchanged, although they may need to process more of 628 the message to decide this. 630 5. The message is intercepted at GN2. The GIST layer identifies the 631 message as relevant to a local signaling application, and passes 632 the signaling application payload and flow description upwards to 633 it. The signaling application in GN2 indicates to GIST that it 634 will peer with GN1 and so GIST should proceed to set up any 635 routing state. In addition, the signaling application continues 636 to process the message as in GN1 (compare step 1), and this will 637 eventually result in the message reaching the flow receiver. 639 6. In parallel, the GIST instance in GN2 now knows that it should 640 maintain routing state and a messaging association for future 641 signaling with GN1. This is recognised because the message is a 642 GIST-Query, and because the local signaling application has 643 indicated that it will peer with GN1. There are two basic 644 possible cases for sending back the necessary GIST-Response: 646 A. GN1 and GN2 already have an appropriate messaging 647 association. GN2 simply records the identity of GN1 as its 648 upstream peer for that flow and signaling application, and 649 sends a GIST-Response back to GN1 over the association 650 identifying itself as the peer for this flow. 652 B. No messaging association exists. GN2 sends the GIST-Response 653 in D mode directly to GN1, identifying itself and agreeing to 654 the association setup. The protocol exchanges needed to 655 complete this will proceed in the background. 657 7. Eventually, another signaling application message works its way 658 upstream from the receiver to GN2. This message contains a 659 description of the actual resources requested, along with 660 authorisation and other security information. The signaling 661 application in GN2 passes this payload to the GIST level, along 662 with the flow definition and transfer attributes {secured, 663 reliable}. 665 8. The GIST layer in GN2 identifies the upstream peer for this flow 666 and signaling application as GN1, and determines that it has a 667 messaging association with the appropriate properties. The 668 message is queued on the association for transmission (this may 669 mean some delay if the procedures begun in step 6.B have not yet 670 completed). 672 Further messages can be passed in each direction in the same way. 673 The GIST layer in each node can in parallel carry out maintenance 674 operations such as route change detection (this can be done by 675 sending additional GIST-Query messages, see Section 7.1 for more 676 details). 678 It should be understood that several of these details of GIST 679 operations can be varied, either by local policy or according to 680 signaling application requirements. The authoritative details are 681 contained in the remainder of this document. 683 4. GIST Processing Overview 685 This section defines the basic structure and operation of GIST. 686 Section 4.1 describes the way in which GIST interacts with (local) 687 signaling applications in the form of an abstract service interface. 688 Section 4.2 describes the per-flow and per-peer state that GIST 689 maintains for the purpose of transferring messages. Section 4.3 690 describes how messages are processed in the case where any necessary 691 messaging associations and routing state already exist; this includes 692 the simple scenario of pure datagram mode operation, where no 693 messaging associations are necessary in the first place. Finally, 694 Section 4.4 describes how routing state and messaging associations 695 are created and managed. 697 4.1. GIST Service Interface 699 This section defines the service interface that GIST presents to 700 signaling applications in terms of abstract properties of the message 701 transfer. Note that the same service interface is presented at every 702 GIST node; however, applications may invoke it differently at 703 different nodes (e.g. depending on local policy). In addition, the 704 service interface is defined independently of any specific transport 705 protocol, or even the distinction between datagram and connection 706 mode. The initial version of this specification defines how to 707 support the service interface using a connection mode based on TCP; 708 if additional transport protocol support is added, this will support 709 the same interface and so be invisible to applications (except as a 710 possible performance improvement). A more detailed description of 711 this service interface is given in Appendix B. 713 4.1.1. Message Handling 715 Fundamentally, GIST provides a simple message-by-message transfer 716 service for use by signaling applications: individual messages are 717 sent, and individual messages are received. At the service 718 interface, the signaling application payload (which is opaque to 719 GIST) is accompanied by control information expressing the 720 application's requirements about how the message should be routed, 721 and the application also provides the session identifier (see 722 Section 3.4). Additional message transfer attributes control the 723 specific transport and security properties that the signaling 724 application desires for the message. 726 The distinction between GIST connection and datagram modes is not 727 visible at the service interface. In addition, the invocation of 728 GIST functionality to handle fragmentation and reassembly, bundling 729 together of small messages (for efficiency), and congestion control 730 is not directly visible at the service interface; GIST will take 731 whatever action is necessary based on the properties of the messages 732 and local node state. 734 4.1.2. Message Transfer Attributes 736 Message transfer attributes are used to define certain performance 737 and security related aspects of message processing. The attributes 738 available are as follows: 740 Reliability: This attribute may be 'true' or 'false'. For the case 741 'true', messages MUST be delivered to the signaling application in 742 the peer exactly once or not at all; if there is a chance that the 743 message was not delivered, an error MUST be indicated to the local 744 signaling application identifying the routing information for the 745 message in question. Messages with the same SID to the same peer 746 MUST be delivered in order. For the case 'false', a message may 747 be delivered, once, several times or not at all, with no error 748 indications in any case. 750 Security: This attribute defines the security properties that the 751 signaling application requires for the message, including the type 752 of protection required, and what authenticated identities should 753 be used for the signaling source and destination. This 754 information maps onto the corresponding properties of the security 755 associations established between the peers in connection mode. It 756 can be specified explicitly by the signaling application, or 757 reported by GIST to the signaling application (either on receiving 758 a message, or just before sending a message but after configuring 759 or selecting the messaging association to be used for it). This 760 attribute can also be used to convey information about any address 761 validation carried out by GIST (for example, whether a return 762 routability check has been carried out). Further details are 763 discussed in Appendix B. 765 Local Processing: An NSLP may provide hints to GIST to enable more 766 efficient or appropriate processing. For example, the NSLP may 767 select a priority from a range of locally defined values to 768 influence the sequence in which messages leave a node. Any 769 priority mechanism MUST respect the ordering requirements for 770 reliable messages within a session, and priority values are not 771 carried in the protocol or available at the signaling peer or 772 intermediate nodes. An NSLP may also indicate that reverse path 773 routing state will not be needed for this flow, to inhibit the 774 node requesting its downstream peer to create it. 776 4.2. GIST State 778 4.2.1. Message Routing State 780 For each flow, the GIST layer can maintain message routing state to 781 manage the processing of outgoing messages. This state is 782 conceptually organised into a table with the following structure. 784 The primary key (index) for the table is the combination of the 785 information about how the message is to be routed, the session being 786 signalled for, and the signaling application itself: 788 Message Routing Information (MRI): This defines the method to be used 789 to route the message, the direction in which to send the message, 790 and any associated addressing information; see Section 3.3. 792 Session Identification (SID): The signaling session with which this 793 message should be associated; see Section 3.4. 795 Signaling Application Identification (NSLPID): This is an IANA 796 assigned identifier of the signaling application which is 797 generating messages for this flow. The inclusion of this 798 identifier allows the routing state to be different for different 799 signaling applications (e.g. because of different adjacencies). 801 The information for a given key consists of the routing state to 802 reach the peer in the direction given by the MRI. For any flow, 803 their will usually be two entries (for the upstream and downstream 804 MRI). The routing state includes information about the peer identity 805 (see Section 4.4.2), and a UDP port number (for datagram mode) or a 806 reference to one or more messaging associations (for connection 807 mode). All of this information is learned from prior GIST exchanges. 809 It is also possible for the state information for either direction to 810 be null. There are several possible cases: 812 o The signaling application has indicated that no messages will 813 actually be sent in that direction. 815 o The node is a flow endpoint, so there can be no signaling peer in 816 one or other direction. 818 o The node is the endpoint of the signaling path (for example, 819 because it is acting as a proxy, or because it has determined 820 explicitly that there are no further signaling nodes in that 821 direction). 823 o The node can use other techniques to route the message. For 824 example, it can encapsulate it the same way as a Query message and 825 rely on the peer to intercept it. 827 Each item of routing state has an associated validity timer for how 828 long it can be considered accurate; when this timer expires, it MUST 829 be purged if it has not been refreshed. Installation and maintenance 830 of routing state is described in more detail in Section 4.4. 832 Note also that the routing state is described as a table of flows, 833 but that there is no implied constraint on how the information is 834 stored. However, in general, and especially if GIST peers are 835 several IP hops away, there is no way to identify the correct 836 downstream peer for a flow and signaling application from the local 837 forwarding table using prefix matching, and the same applies always 838 to upstream peer state because of the possibility of asymmetric 839 routing: per-flow state has to be stored, just as for RSVP [9]. 841 4.2.2. Messaging Association State 843 The per-flow message routing state is not the only state stored by 844 GIST. There is also the state required to manage the messaging 845 associations. Since these are typically per-peer rather than per- 846 flow, they are stored separately, including the following 847 information: 849 o messages pending transmission while an association is being 850 established; 852 o a timer for how long since the peer re-stated its desire to keep 853 the association open (see Section 4.4.3). 855 In addition, per-association state is held in the messaging 856 association protocols themselves. However, the details of this state 857 are not directly visible to GIST, and they do not affect the rest of 858 the protocol description. 860 4.3. Basic Message Processing 862 This section describes how signaling application messages are 863 processed in the case where any necessary messaging associations and 864 routing state are already in place. The description is divided into 865 several parts. Firstly, message reception, local processing and 866 message transmission are described for the case where the node hosts 867 the NSLPID in the message. Secondly, the case where the message is 868 handled directly in the IP or GIST layer (because there is no 869 matching signaling application on the node) is given. An overview is 870 given in Figure 3. 872 +---------------------------------------------------------+ 873 | >> Signaling Application Processing >> | 874 | | 875 +--------^---------------------------------------V--------+ 876 ^ V 877 ^ NSLP Payloads V 878 ^ V 879 +--------^---------------------------------------V--------+ 880 | >> GIST >> | 881 | ^ ^ ^ Processing V V V | 882 +--x-----------N--Q---------------------Q--N-----------x--+ 883 x N Q Q N x 884 x N Q>>>>>>>>>>>>>>>>>>>>>Q N x 885 x N Q Bypass at Q N x 886 +--x-----+ +--N--Q--+ GIST level +--Q--N--+ +-----x--+ 887 | C-mode | | D-mode | | D-mode | | C-mode | 888 |Handling| |Handling| |Handling| |Handling| 889 +--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+ 890 x N Q Q N x 891 x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x 892 x N Q Bypass at Q N x 893 +--x--N--+ +-----Q--+ IP (router +--Q-----+ +--N--x--+ 894 |IP Host | | RAO | alert) level | RAO | |IP Host | 895 |Handling| |Handling| |Handling| |Handling| 896 +--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+ 897 x N Q Q N x 898 +--x--N-----------Q--+ +--Q-----------N--x--+ 899 | IP Layer | | IP Layer | 900 | (Receive Side) | | (Transmit Side) | 901 +--x--N-----------Q--+ +--Q-----------N--x--+ 902 x N Q Q N x 903 x N Q Q N x 904 x N Q Q N x 906 NNNNNNNNNNNNNN = 'Normal' datagram mode messages 907 QQQQQQQQQQQQQQ = Datagram mode messages which 908 are Queries or likewise encapsulated 909 xxxxxxxxxxxxxx = connection mode messages 910 RAO = Router Alert Option 912 Figure 3: Message Paths through a GIST Node 914 4.3.1. Message Reception 916 Messages can be received in connection or datagram mode, and in the 917 latter case with two types of message encapsulation. 919 Reception in connection mode is simple: incoming packets undergo the 920 security and transport treatment associated with the messaging 921 association, and the messaging association provides complete messages 922 to the GIST layer for further processing. Unless the message is 923 protected by a query/response cookie exchange (see Section 4.4.1) or 924 has been explicitly routed (see Section 7.1.4), the routing state 925 table MUST be checked to ensure that this messaging association is 926 associated with the MRI/NSLPID/SID combination given in the message, 927 or else a "Incorrectly Delivered Message" error message 928 (Appendix A.4.4.4) MUST be returned. 930 Reception in datagram mode depends on the message type. 'Normal' 931 messages arrive UDP encapsulated and addressed directly to the 932 receiving signaling node, at an address and port learned previously. 933 Each datagram contains a single complete message which is passed to 934 the GIST layer for further processing, just as in the connection mode 935 case. 937 Where GIST is sending messages to be intercepted by the appropriate 938 peer rather than directly addressed to it (in particular, Query 939 messages), these are UDP encapsulated with an IP router alert option. 940 Each signaling node will therefore 'see' all such messages. The case 941 where the NSLPID does not match a local signaling application at all 942 is considered below in Section 4.3.4; otherwise, it is again passed 943 up to the GIST layer for further processing. 945 4.3.2. Local Processing 947 Once a message has been received, by any method, it is processed 948 locally within the GIST layer. The GIST processing to be done 949 depends on the message type and payloads carried; most of the GIST- 950 internal payloads are associated with state maintenance and are 951 covered in Section 4.4. There is also a hop count to prevent message 952 looping and this MUST be decremented immediately the message has been 953 received. 955 The remainder of the GIST message consists of an NSLP payload. This 956 is delivered locally to the signaling application identified at the 957 GIST level; the format of the NSLP payload is not constrained by 958 GIST, and the content is not interpreted. 960 Even when a message relates to a local signaling application, an 961 adjacency MAY be required based on signaling application policy, and 962 the application of this policy MAY depend on the NSLP payload. 963 Therefore, when this decision has to be made, the NSLP payload is 964 delivered and the signaling application has two options: 966 o to proceed setting up the adjacency. The application MAY provide 967 an NSLP payload (which will be used in any GIST-Response). 969 o to bypass the message and drop out of the signaling path. The 970 application MAY provide an updated NSLP payload (which will be 971 used in the message which is then forwarded by GIST). 973 Signaling applications can generate their messages for transmission, 974 either asynchronously, or in response to an input message, and GIST 975 can also generate messages autonomously. Regardless of the source, 976 outgoing messages are passed downwards for message transmission. 978 4.3.3. Message Transmission 980 When a message is available for transmission, GIST uses internal 981 policy and the stored routing state to determine how to handle it. 982 The following processing applies equally to locally generated 983 messages and messages forwarded from within the GIST or signaling 984 application levels. (However, note that special rules apply to the 985 transmission of error messages generated by GIST. These are given in 986 Section 5.6.) 988 The main decision is whether the message must be sent in connection 989 mode or datagram mode. Reasons for using the former are: 991 o NSLP requirements: for example, the signaling application has 992 requested channel secured delivery, or reliable delivery; 994 o protocol specification: a message that requires fragmentation MUST 995 be sent over a messaging association; 997 o local GIST policy: for example, a node MAY prefer to send messages 998 over a messaging association to benefit from adaptive congestion 999 control. 1001 In principle, as well as determining that some messaging association 1002 must be used, GIST MAY select between a set of alternatives, e.g. for 1003 load sharing or because different messaging associations provide 1004 different transport or security attributes. 1006 If the use of a messaging association is selected, the message is 1007 queued on the association found from the routing state table, and 1008 further output processing is carried out according to the details of 1009 the protocol stacks used. If no appropriate association exists, the 1010 message is queued while one is created (see Section 4.4). If no 1011 association can be created, this is an error condition, and should be 1012 indicated back to the local NSLP. 1014 If a messaging association is not required, the message is sent in 1015 datagram mode. The processing in this case depends on the message 1016 type and whether routing state exists or not. 1018 o If the message is not a Query, and routing state exists, it is UDP 1019 encapsulated and sent directly to the address from the routing 1020 state table. 1022 o If the message is a Query, then it is UDP encapsulated with IP 1023 address and router alert option determined from the MRI and NSLPID 1024 (further details depend on the message routing method). 1026 o If no routing state exists, GIST can attempt to use the same IP/ 1027 UDP encapsulation as in the Query case. If this is not possible 1028 (e.g. because the encapsulation algorithm for the message routing 1029 method is only defined valid for one message direction), then this 1030 is an error condition which is reported back to the local NSLP. 1032 4.3.4. Nodes not Hosting the NSLP 1034 A node may receive messages where it has no signaling application 1035 corresponding to the message NSLPID. There are several possible 1036 cases depending mainly on the encapsulation: 1038 1. A Query-encapsulated message contains an RAO value which is 1039 relevant to NSIS but not to the specific node, but the IP layer 1040 is unable to recognise whether it needs to be passed to GIST for 1041 further processing or whether the packet should be forwarded just 1042 like a normal IP datagram. 1044 2. A Query-encapsulated message contains an RAO value which is 1045 relevant to the node, but the specific signaling application for 1046 the actual NSLPID in the message is not processed there. 1048 3. A directly addressed message (in datagram or connection mode) is 1049 delivered to a node for which there is no corresponding signaling 1050 application. (With the current specification, this should never 1051 happen. While future versions might find a use for such a 1052 feature, currently this MUST cause an "Unknown NSLPID" error 1053 message, Appendix A.4.4.6.) 1055 4. A Query-encapsulated message arrives at the end-system which does 1056 not handle the NSLP. This is possible in normal operation, and 1057 MUST be notified to the sender with an "Endpoint Found" 1058 informational message (Appendix A.4.4.7). The end-system 1059 includes the MRI and SID from the original message in the error 1060 message without interpreting them. 1062 In cases (1) and (2), the role of GIST is to forward the message 1063 essentially unchanged, and it will not become a peer to the node 1064 sending the message. (Forwarding with modified signaling application 1065 payloads is covered above in Section 4.3.2.) However, a GIST 1066 implementation must ensure that the IP TTL field and GIST hop count 1067 are managed correctly to prevent message looping, and this should be 1068 done consistently independently of whether the processing (e.g. for 1069 case (1)) takes place on the fast path or in GIST-specific code. The 1070 rules are that in cases (1) and (2), the IP TTL MUST be decremented 1071 just as if the message was a normal IP forwarded packet; in case (2) 1072 the GIST hop count MUST be decremented as in the case of normal input 1073 processing, which indeed applies to cases (3) and (4). 1075 A GIST node processing Query-encapsulated messages in this way SHOULD 1076 make the routing decision based on the full contents of the MRI and 1077 not only the IP destination address. It MAY also apply a restricted 1078 set of sanity checks and under certain conditions return an error 1079 message rather than forwarding the message. These conditions are: 1081 1. The message is so large that it would be fragmented on downstream 1082 links (e.g. because the downstream MTU is very small). The error 1083 "Message Too Large" (Appendix A.4.4.8) SHOULD be returned to the 1084 sender, which SHOULD begin messaging association setup. 1086 2. The GIST hop count has been exceeded. The error "Hop Limit 1087 Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender, 1088 which MAY retry with a larger initial hop count if it is clear 1089 that a loop has not been formed. 1091 3. The MRI represents a flow definition which is too general to be 1092 forwarded along a unique path (e.g. the destination address 1093 prefix is too short). The error "MRI Too Wild" 1094 (Appendix A.4.4.12) SHOULD be returned to the sender, which MAY 1095 retry with restricted MRIs, possibly starting additional 1096 signaling sessions to do so. If the GIST node does not 1097 understand the MRM in question it MUST NOT apply this check, 1098 instead forwarding the message transparently. 1100 In the first two cases, only the common header is examined; in the 1101 third case, the MRI is also examined. The rest of the message MUST 1102 never be inspected or modified. 1104 Note that the hop count is only intended to prevent message looping 1105 at the GIST level, and by default NSLPs must take their own measures 1106 to prevent looping at the application level. However, the GIST API 1107 (Appendix B) allows NSLPs to find the GIST hop count on incoming 1108 messages and preserve it in outgoing messages which are being 1109 forwarded further along the path. This provides a lightweight loop- 1110 prevention mechanism for NSLPs which do not define anything more 1111 sophisticated. 1113 4.4. Routing State and Messaging Association Maintenance 1115 The main responsibility of GIST is to manage the routing state and 1116 messaging associations which are used in the basic message processing 1117 described above. Routing state is installed and maintained by 1118 specific GIST messages. Messaging associations are dependent on the 1119 existence of routing state, but are actually set up by the normal 1120 procedures of the transport and security protocols that comprise 1121 them. Timers control routing state and messaging association refresh 1122 and expiration. 1124 There are two different cases for state installation and refresh: 1126 1. Where routing state is being discovered or a new association is 1127 to be established; and 1129 2. Where an existing association can be re-used, including the case 1130 where routing state for the flow is being refreshed. 1132 These cases are now considered in turn, followed by the case of 1133 background general management procedures. 1135 4.4.1. State Setup 1137 The complete sequence of possible messages for state setup between 1138 adjacent peers is shown in Figure 4 and described in detail in the 1139 following text. A concrete example is given in Appendix C. 1141 The initial message in any routing state maintenance operation is a 1142 GIST-Query message, sent from the querying node and intercepted at 1143 the responding node. This message has addressing and other 1144 identifiers appropriate for the flow and signaling application that 1145 state maintenance is being done for, addressing information about the 1146 node itself, and it MAY contain an NSLP payload. It also includes a 1147 Query Cookie, and optionally capability information about messaging 1148 association protocol stacks. The role of the cookies in this and 1149 subsequent messages is to protect against certain denial of service 1150 attacks and to correlate the various events in the message sequence. 1152 +----------+ +----------+ 1153 | Querying | |Responding| 1154 | Node | | Node | 1155 +----------+ +----------+ 1156 GIST-Query 1157 ----------------------> ............. 1158 Router Alert Option . Routing . 1159 MRI/SID/NSLPID . state . 1160 Q-Node Network Layer Info . installed . 1161 Query Cookie . at . 1162 [Q-Node Stack-Proposal . R-node(1) . 1163 Q-Node Stack-Config-Data] ............. 1164 [NSLP Payload] 1166 ...................................... 1167 . The responder can use an existing . 1168 . messaging association if available . 1169 . from here onwards to short-circuit . 1170 . messaging association setup . 1171 ...................................... 1173 GIST-Response 1174 ............. <---------------------- 1175 . Routing . MRI/SID/NSLPID 1176 . state . R-Node Network Layer Info (D Mode only) 1177 . installed . Query cookie 1178 . at . [Responder Cookie 1179 . Q-Node . [R-Node Stack-Proposal 1180 ............. R-Node Stack-Config-Data]] 1181 [NSLP Payload] 1183 .................................... 1184 . If a messaging association needs . 1185 . to be created, it is set up here . 1186 .................................... 1188 GIST-Confirm 1189 ----------------------> 1190 MRI/SID/NSLPID ............. 1191 Q-Node Network Layer Info . Routing . 1192 [Responder Cookie . state . 1193 [R-Node Stack-Proposal]] . installed . 1194 [NSLP Payload] . at . 1195 . R-node(2) . 1196 ............. 1198 Figure 4: Message Sequence at State Setup 1199 Reception of a GIST-Query MUST elicit a GIST-Response message. This 1200 is a 'normally' encapsulated datagram mode message with additional 1201 payloads. It contains network layer information about the responding 1202 node, echoes the Query Cookie, and MAY contain an NSLP payload 1203 (possibly a response to the NSLP payload in the initial message). In 1204 case a messaging association was requested, it MUST also contain a 1205 Responder Cookie and its own capability information about messaging 1206 association protocol stacks. Even if a messaging association is not 1207 requested, the Response MAY still include a Responder Cookie if the 1208 node's routing state setup policy requires it (see below). 1210 Setup of a new messaging association begins when peer addressing 1211 information is available and a new messaging association is actually 1212 needed. The setup MUST be contemporaneous with a specific GIST- 1213 Query/Response exchange, because the addressing information used may 1214 have a limited lifetime (either because it depends on limited 1215 lifetime NAT bindings, or because it refers to agile destination 1216 ports for the transport protocols). The Stack-Proposal and Stack- 1217 Configuration-Data objects carried in the exchange carry capability 1218 information about what messaging association protocols can be used, 1219 and the processing of these objects is described in more detail in 1220 Section 5.7. With the protocol options currently defined, setup of 1221 the messaging association always starts from the Querying node, 1222 although more flexible configurations are possible within the overall 1223 GIST design. In any case, once set up the association itself can be 1224 used equally in both directions. 1226 Finally, a GIST-Confirm MUST be sent if the GIST-Response requested 1227 it. If a messaging association is being used, the GIST-Confirm MUST 1228 be sent over it before any other messages for the same flow, and it 1229 echoes the Responder Cookie and Stack Proposal from the GIST- 1230 Response. The former is used to allow the receiver to validate the 1231 contents of the message (see Section 8.5), and the latter is to 1232 prevent certain bidding-down attacks on messaging association 1233 security. The association can be used in the upstream direction for 1234 that flow and NSLPID after the Confirm has been received. 1236 The querying node MUST install the responder address as routing state 1237 information after verifying the Query Cookie in the GIST-Response. 1238 The responding node MAY install the querying address as peer state 1239 information at two points in time: 1241 1. after the receipt of the initial GIST-Query, or 1243 2. after a GIST-Confirm message containing the Responder Cookie. 1245 The precise constraints on when state information is installed are a 1246 matter of security policy considerations on prevention of denial-of- 1247 service attacks and state poisoning attacks, which are discussed 1248 further in Section 8. Because the responding node MAY choose to 1249 delay state installation as in case (2), the GIST-Confirm must 1250 contain sufficient information to allow it to be processed 1251 identically to the original Query. This places some special 1252 requirements on NAT traversal and cookie functionality, which are 1253 discussed in Section 7.2 and Section 8 respectively. 1255 4.4.2. Association Re-use 1257 It is a design goal of GIST that, so far as possible, messaging 1258 associations should be re-used for multiple flows and sessions, 1259 rather than a new association set up for each. This is to ensure 1260 that the association cost scales only like the number of peers, and 1261 to avoid the latency of new association setup where possible. 1263 However, re-use requires the identification of an existing 1264 association which matches the same routing state and desired 1265 properties that would be the result of a full handshake in D-mode, 1266 and this identification must be done as reliably and securely as 1267 continuing with the full procedure. Note that this requirement is 1268 complicated by the fact that NATs may remap the node addresses in 1269 D-mode messages, and also interacts with the fact that some nodes may 1270 peer over multiple interfaces (and so with different addresses). 1272 Association re-use is controlled by the Network-Layer-Information 1273 (NLI) object, which is carried in GIST-Query/Confirm and optionally 1274 GIST-Response messages. The NLI object includes: 1276 Peer-Identity: For a given node, this is an interface independent 1277 with opaque syntax. It MUST be chosen so as to have a high 1278 probability of uniqueness between peers, and SHOULD be stable (at 1279 least between restarts). Note that there is no cryptographic 1280 protection of this identity (attempting to provide this would 1281 essentially duplicate the functionality in the messaging 1282 association security protocols). 1284 Interface-Address: This is an IP address through which the signaling 1285 node can be reached. There may be several choices available for 1286 the Interface-Address, and further discussion of this is contained 1287 in Section 5.2.2. 1289 By default, a messaging association is associated with the NLI object 1290 that was provided by the peer in the Query/Response/Confirm at the 1291 time the association was set up. There may be more than one 1292 association for a given NLI object (e.g. with different properties). 1294 Association re-use is controlled by matching the NLI provided in a 1295 GIST message with those associated with existing associations. This 1296 can be done on receiving either a GIST-Query or GIST-Response (the 1297 former is more likely): 1299 o If there is a perfect match to the NLI of an existing association, 1300 that association SHOULD be re-used (provided it has the 1301 appropriate properties in other respects). This is indicated by 1302 sending the remaining messages in the handshake over that 1303 association. This will only fail (i.e. lead to re-use of an 1304 association to the 'wrong' node) if signaling nodes have colliding 1305 Peer-Identities, and one is reachable at the same Interface- 1306 Address as another. (This could be done by an on-path attacker.) 1308 o In all other cases, the full handshake MUST be executed in 1309 datagram mode as usual. There are in fact four possibilities: 1311 1. Nothing matches: this is clearly a new peer. 1313 2. Only the Peer-Identity matches: this may be either a new 1314 interface on an existing peer, or a changed address mapping 1315 behind a NAT, or an attacker attempting to hijack the Peer- 1316 Identity. These should be rare events, so the expense of a 1317 new association setup is acceptable. If the authenticated 1318 peer identities match after association setup, the two 1319 Interface-Addresses MAY be bound to the association. 1321 3. Only the Interface-Address matches: this is probably a new 1322 peer behind the same NAT as an existing one. A new 1323 association setup is required. 1325 4. The full NLI object matches: this is a degenerate case, where 1326 one node recognises an existing peer, but wishes to allow the 1327 option to set up a new association in any case (for example to 1328 create an association with different properties). 1330 4.4.3. State Maintenance Procedures 1332 Refresh and expiration of all types of state is controlled by timers. 1334 Each item of routing state expires after a validity lifetime which is 1335 negotiated during the Query/Response/Confirm handshake. The NLI 1336 object in the Query contains a proposal for the lifetime value, and 1337 the NLI in the Response contains the value the Responding node 1338 requires. The Querying node MUST generate a GIST-Query message 1339 before this timer expires, if it believes that the flow is still 1340 active; otherwise, the Responding node MAY delete the state. Receipt 1341 of the message at the Responding node will refresh peer addressing 1342 state for one direction, and receipt of a GIST-Response at the 1343 querying node will refresh it for the other. There is no mechanism 1344 at the GIST level for explicit teardown of routing state. 1346 Unneeded messaging associations are torn down by GIST, using the 1347 teardown mechanisms of the underlying transport or security protocols 1348 if available (for example, simply by closing a TCP connection). The 1349 teardown can be initiated by either end. Whether an association is 1350 needed is a combination of two factors: 1352 o local policy, which could take into account the cost of keeping 1353 the messaging association open, the level of past activity on the 1354 association, and the likelihood of future activity (e.g. if there 1355 is routing state still in place which might generate messages to 1356 use it). 1358 o whether the peer still wants the association in place. During 1359 messaging association setup, each node indicates its own MA-hold- 1360 time as part of the Stack-Configuration-Data; the node MUST not 1361 tear down the association if it has received traffic from its peer 1362 over that period. A peer which has generated no traffic but still 1363 wants the association retained SHOULD use a special 'null' message 1364 (GIST-MA-Hello) to indicate the fact. 1366 Messaging associations can always be set up on demand, and messaging 1367 association status is not made directly visible outside the GIST 1368 layer. Therefore, even if GIST tears down and later re-establishes a 1369 messaging association, signaling applications cannot distinguish this 1370 from the case where the association is kept permanently open. To 1371 maintain the transport semantics described in Section 4.1, GIST MUST 1372 close transport connections carrying reliable messages gracefully or 1373 report an error condition, and MUST NOT open a new association for a 1374 given session and peer while messages on a previous association may 1375 still be outstanding. 1377 5. Message Formats and Transport 1379 5.1. GIST Messages 1381 All GIST messages begin with a common header, followed by a sequence 1382 of type-length-value (TLV) objects. This subsection describes the 1383 possible GIST messages and their contents at a high level; a more 1384 detailed description of the header and each object is given in 1385 Section 5.2. 1387 The common header includes a version number, message type and size, 1388 and signaling application ID. It also carries a hop count to prevent 1389 message looping and a R (Reply) flag to indicate if a reply of some 1390 sort is requested. The objects following the common header MUST be 1391 carried in a fixed order, depending on message type. Messages with 1392 missing, duplicate or invalid objects for the message type MUST be 1393 rejected with a "Object Type Error" error message with the 1394 appropriate subcode (Appendix A.4.4.9). 1396 The following gives the basic syntax of GIST messages in ABNF [3]. 1397 Note that the NAT traversal mechanism for GIST involves the insertion 1398 of an additional NAT-Traversal object in certain messages; the rules 1399 for this are given in Section 7.2. 1401 GIST-Message: The main messages are either one of the stages in the 1402 3-way handshake, or a simple message carrying NSLP data. Additional 1403 types are allocated for errors and messaging association keepalive. 1405 GIST-Message = GIST-Query / GIST-Response / 1406 GIST-Confirm / GIST-Data / 1407 GIST-Error / GIST-MA-Hello 1409 GIST-Query: A GIST-Query MUST be sent in datagram mode. As well as 1410 the common header, it contains certain mandatory control objects, and 1411 MAY contain a signaling application payload. A stack proposal and 1412 configuration data MUST be included if the message exchange relates 1413 to setup of a messaging association. The R flag MUST always be set 1414 (R=1) in a Query, since this message always elicits a Response. 1416 GIST-Query = Common-Header 1417 Message-Routing-Information 1418 Session-Identification 1419 Network-Layer-Information 1420 Query-Cookie 1421 [ Stack-Proposal Stack-Configuration-Data ] 1422 [ NSLP-Data ] 1424 GIST-Response: A GIST-Response may be sent in datagram or connection 1425 mode (if a messaging association is being re-used). It MUST echo the 1426 MRI (with inverted D flag), SID and Query-Cookie of the Query, and in 1427 D-mode carries its own Network-Layer-Information; if the message 1428 exchange relates to setup of a messaging association (which can only 1429 take place in datagram mode), a Responder cookie MUST be included, as 1430 well as its own stack proposal and configuration data. The R flag 1431 MUST be set (R=1) if a Responder cookie is present but otherwise is 1432 optional; the R flag controls whether a Confirm is sent. 1434 GIST-Response = Common-Header 1435 Message-Routing-Information 1436 Session-Identification 1437 [ Network-Layer-Information ] 1438 Query-Cookie 1439 [ Responder-Cookie 1440 [ Stack-Proposal Stack-Configuration-Data ] ] 1441 [ NSLP-Data ] 1443 GIST-Confirm: A GIST-Confirm may be sent in datagram or connection 1444 mode (if a messaging association has been re-used). It MUST echo the 1445 MRI (with inverted D flag), SID, and Responder-Cookie if the Response 1446 carried one; if the message exchange relates to setup of a new 1447 messaging association or reuse of an existing one (which can only 1448 take place in connection mode), the message MUST also echo the Stack- 1449 Proposal from the GIST-Response so it can be verified that this has 1450 not been tampered with. 1452 GIST-Confirm = Common-Header 1453 Message-Routing-Information 1454 Session-Identification 1455 Network-Layer-Information 1456 [ Responder-Cookie ] 1457 [ Stack-Proposal ] 1458 [ NSLP-Data ] 1460 GIST-Data: A plain data message contains no control objects, but only 1461 the MRI and SID associated with the NSLP data being transferred. 1462 Network-Layer-Information MUST be carried in the datagram mode case 1463 and not otherwise. 1465 GIST-Data = Common-Header 1466 Message-Routing-Information 1467 Session-Identification 1468 [ Network-Layer-Information ] 1469 NSLP-Data 1471 GIST-Error: A GIST-Error message reports a problem determined at the 1472 GIST level. (Errors generated by signaling applications are reported 1473 in NSLP-Data payloads and are not treated specially by GIST.) The 1474 message includes a Network-Layer-Information object for the 1475 originator of the error message it if is being sent in datagram mode; 1476 all other information related to the error is carried in a GIST- 1477 Error-Data object. 1479 GIST-Error = Common-Header 1480 [ Network-Layer-Information ] 1481 GIST-Error-Data 1483 GIST-MA-Hello: This message MUST be sent only in C-Mode to indicate 1484 that a node wishes to keep a messaging association open. It contains 1485 only the common header, with a null NSLPID. The R flag MAY be set 1486 (R=1) to indicate that a reply is requested, thus allowing a node to 1487 test the liveness of the peer. 1489 GIST-MA-Hello = Common-Header 1491 5.2. Information Elements 1493 This section describes the content of the various objects that can be 1494 present in each GIST message, both the common header, and the 1495 individual TLVs. The bit patterns are provided in Appendix A. 1497 5.2.1. The Common Header 1499 Each message begins with a fixed format common header, which contains 1500 the following information: 1502 Version: The version number of the GIST protocol. 1504 Length: The number of 32 bit words in the message following the 1505 common header. 1507 Signaling application identifier (NSLPID): This describes the 1508 specific signaling application, such as resource reservation or 1509 firewall control. 1511 GIST hop counter: A hop counter to prevent a message from looping. 1513 Message type: The message type (Query, Response, etc.) 1515 Source addressing mode: If set (S=1), this indicates that the IP 1516 source address of the message is the same as the signaling source 1517 address, in which case replies to this message can be sent safely 1518 to this address. It is cleared (S=0) if the IP source address was 1519 derived from the message routing information in the payload and 1520 this is different from the signaling source address. 1522 Response requested: A flag which if set (R=1) indicates that a 1523 message should be sent in response to this message. 1525 Explicit routing: A flag which if set (E=1) indicates that the 1526 message was explicitly routed (see Section 7.1.4). 1528 5.2.2. TLV Objects 1530 All data following the common header is encoded as a sequence of 1531 type-length-value objects. Currently, each object can occur at most 1532 once; the set of required and permitted objects is determined by the 1533 message type and encapsulation. 1535 Message-Routing-Information (MRI): Information sufficient to define 1536 how the signaling message should be routed through the network. 1538 Message-Routing-Information = message-routing-method 1539 method-specific-information 1541 The format of the method-specific-information depends on the 1542 message-routing-method requested by the signaling application. It 1543 is provided by the NSLP in the message sender and used by GIST to 1544 select the message routing. 1546 Session-Identification (SID): The GIST session identifier is a 128 1547 bit, cryptographically random identifier chosen by the node which 1548 originates the signaling exchange. See Section 3.4. 1550 Network-Layer-Information: This object carries information about the 1551 network layer attributes of the node sending the message, 1552 including data related to the management of routing state. This 1553 includes a peer identity and IP address for the sending node. It 1554 also includes IP TTL information to allow the hop count between 1555 GIST peers to be measured and reported, and a validity time for 1556 the routing state. 1558 Network-Layer-Information = peer-identity 1559 interface-address 1560 RS-validity-time 1561 IP-TTL 1563 The use of the RS-validity-time field is described in 1564 Section 4.4.3. The peer-identity and interface-address are used 1565 for matching existing associations, as discussed in Section 4.4.2. 1567 The interface-address must be routable, i.e. it MUST be usable as 1568 a destination IP address for packets to be sent back to the node 1569 generating the signaling message (whether in datagram or 1570 connection mode). Where this object is carried in a GIST-Query or 1571 GIST-Confirm, the interface-address MUST specifically be set to an 1572 address bound to the interface associated with the MRI (e.g. the 1573 one carrying the outbound flow), to allow its use in route change 1574 handling, see Section 7.1. A node may have several choices for 1575 which of its addresses to use as the interface-address. For 1576 example, there may be a choice of IP versions, or addresses of 1577 limited scope (e.g. link-local), or addresses bound to different 1578 interfaces in the case of a router or multi-homed host. However, 1579 some of these interface addresses may not be usable by the peer. 1580 A node SHOULD follow a default policy of using a global address of 1581 the same IP version as in the MRI, unless it can establish that an 1582 alternative address would also be usable. 1584 The setting and interpretation of the IP-TTL field depends on the 1585 message direction (as determined from the MRI) and encapsulation. 1587 * If the message is downstream, the IP-TTL MUST be set to the TTL 1588 that will be set in the IP header for the message (if this can 1589 be determined), or else set to 0. 1591 * On receiving a downstream message in datagram mode, a non-zero 1592 IP-TTL is compared to the TTL in the IP header, and the 1593 difference is stored as the IP-hop-count-to-peer for the 1594 upstream peer in the routing state table for that flow. 1595 Otherwise, the field is ignored. 1597 * If the message is upstream, the IP-TTL MUST be set to the value 1598 of the IP-hop-count-to-peer stored in the routing state table, 1599 or 0 if there is no value yet stored. 1601 * On receiving an upstream message, the IP-TTL is stored as the 1602 IP-hop-count-to-peer for the downstream peer. 1604 In all cases, the TTL value reported to signaling applications is 1605 the one stored with the routing state for that flow, after it has 1606 been updated (if appropriate) from processing the message in 1607 question. 1609 Stack-Proposal: This field contains information about which 1610 combinations of transport and security protocols are available for 1611 use in messaging associations, and is also discussed further in 1612 Section 5.7. 1614 Stack-Proposal = 1*stack-profile 1616 stack-profile = 1*protocol-layer 1618 Each protocol-layer field identifies a protocol with a unique tag; 1619 any address-related (mutable) information associated with the 1620 protocol will be carried in a higher-layer-addressing field in the 1621 Stack-Configuration-Data TLV (see below). 1623 Stack-Configuration-Data: This object carries information about the 1624 overall configuration of a messaging association. 1626 Stack-Configuration-Data = MA-hold-time 1627 0*higher-layer-addressing 1629 The MA-hold-time field indicates how long a node will hold open an 1630 inactive association; see Section 4.4.3 for more discussion. The 1631 higher-layer-addressing fields give the configuration of the 1632 protocols to be used for new messaging associations, and they are 1633 described in more detail in Section 5.7. 1635 Query-Cookie/Responder-Cookie: A Query-Cookie is contained in a GIST- 1636 Query message and MUST be echoed in a GIST-Response; a Response- 1637 Cookie MAY be sent in a GIST-Response message, and if present MUST 1638 be echoed in the following GIST-Confirm message. Cookies are 1639 variable length (chosen by the cookie generator). See Section 8.5 1640 for further details on requirements and mechanisms for cookie 1641 generation. 1643 NSLP-Data: The NSLP payload to be delivered to the signaling 1644 application. GIST does not interpret the payload content. 1646 GIST-Error-Data: This contains all the information to determine the 1647 cause and context of an error. 1649 GIST-Error-Data = error-class error-code error-subcode 1650 common-header 1651 [ Message-Routing-Information-content ] 1652 [ Session-Identification-content ] 1653 0*additional-information 1654 [ comment ] 1656 The error-class indicates the severity level, and the error-code 1657 and error-subcode identify the specific error itself. A full list 1658 of GIST errors and their severity levels is given in Appendix A.4. 1659 The common-header from the original message is always included, as 1660 are the contents of the Message-Routing-Information and Session- 1661 Identification objects if they were successfully decoded. For 1662 some errors, additional information fields must be included 1663 according to a fixed format; finally, an optional free-text 1664 comment may be added. 1666 5.3. Datagram Mode Transport 1668 This section describes the various encapsulation options for datagram 1669 mode messages. Although there are several possibilities, depending 1670 on message type, message routing method, and local policy, the 1671 general design principle is that the sole purpose of the 1672 encapsulation is to ensure that the message is delivered to or 1673 intercepted at the correct peer. Beyond that, minimal significance 1674 is attached to the type of encapsulation or the values of addresses 1675 or ports used for it. This allows new options to be developed in the 1676 future to handle particular deployment requirements without modifying 1677 the overall protocol specification. 1679 5.3.1. Normal Encapsulation 1681 Normal encapsulation MUST be used for all datagram mode messages 1682 where the signaling peer is already known from previous signaling. 1683 This includes Response and Confirm messages, and Data messages except 1684 if these are being sent without using local routing state. Normal 1685 encapsulation is simple: the complete set of GIST payloads is 1686 concatenated together with the common header, and placed in the data 1687 field of a UDP datagram. UDP checksums MUST be enabled. The message 1688 is IP addressed directly to the adjacent peer; the UDP port numbering 1689 MUST be compatible with that used on Query messages (see below), that 1690 is, the same for messages in the same direction and swapped 1691 otherwise. 1693 5.3.2. Query Encapsulation 1695 Query encapsulation MUST be used for messages where no routing state 1696 is available or where the routing state is being refreshed, in 1697 particular for GIST-Query messages. Query encapsulation is similar 1698 to normal encapsulation, with changes in IP address selection, IP 1699 options, and a defined method for selecting UDP ports. 1701 In general, the IP addresses are derived from information in the MRI; 1702 the exact rules depend on the message routing method. In addition, 1703 the IP header is given a Router Alert Option to assist the peer in 1704 intercepting the message depending on the NSLPID. Each NSLPID 1705 corresponds to a unique RAO value, but not necessarily vice versa; 1706 further details are discussed in [36]. 1708 The source UDP port is selected by the message sender as the port at 1709 which it is prepared to receive UDP messages in reply, and a 1710 destination UDP port is allocated by IANA (see Section 9). Note that 1711 GIST may send messages addressed as {flow sender, flow receiver} 1712 which could make their way to the flow receiver even if that receiver 1713 were GIST-unaware. These should be rejected (with an ICMP message) 1714 rather than delivered to the user application (which would be unable 1715 to use the source address to identify it as not being part of the 1716 normal data flow). Therefore, a "well-known" port is required. 1718 5.3.3. Retransmission and Rate-Control 1720 Datagram mode uses UDP, and hence has no automatic reliability or 1721 congestion control capabilities. Signaling applications requiring 1722 reliability should be serviced using C-mode, which should also carry 1723 the bulk of signaling traffic. However, some form of messaging 1724 reliability is required for the GIST control messages themselves, as 1725 is rate control to handle retransmissions and also bursts of 1726 unreliable signaling or state setup requests from the signaling 1727 applications. 1729 Query messages which do not receive Responses MAY be retransmitted; 1730 retransmissions MUST use a binary exponential backoff, with an 1731 initial timeout of T1 up to a maximum of T2 seconds. Retransmitted 1732 Queries MUST use different Query-Cookie values. The values of T1 and 1733 T2 are implementation defined. Note that Queries may go unanswered 1734 either because of message loss (in either direction), or because 1735 there is no reachable GIST peer. Therefore, implementations should 1736 trade off reliability (large T2) against promptness of error feedback 1737 to applications (small T2). If either message carries NSLP data, it 1738 may be delivered multiple times to the signaling application. 1740 This algorithm is sufficient to handle lost Queries and Responses. 1741 The case of a lost Confirm is more subtle. Notionally, we can 1742 distinguish between two cases: 1744 1. Where the Responding node is already prepared to store per-flow 1745 state after receiving a single (Query) message. This would 1746 include any cases where the node has NSLP data queued to send. 1747 Here, the Responding node MAY run a retransmission timer to 1748 resend the Response message until a Confirm is received, since 1749 the node is already managing state for that flow. The problem of 1750 an amplification attack stimulated by a malicious Query is 1751 handled by requiring the cookie mechanism to enable the node 1752 receiving the Response to discard it efficiently if it does not 1753 match a previously sent Query. 1755 2. Where the responding node is not prepared to store per-flow state 1756 until receiving a properly formed Confirm message. 1758 In case (2), a retransmission timer should not be required. However, 1759 we can assume that the next signaling message will be in the 1760 direction Querying Node -> Responding Node (if there is no 'next 1761 signaling message' the fact that the Confirm has been lost is moot). 1763 In this case, the responding node will start to receive messages at 1764 the GIST level for a MRI/NSLP combination for which there is no 1765 stored routing state (since this state is only created on receipt of 1766 a Confirm). 1768 Therefore, the error condition is detected at the Responding node 1769 when such a message arrives, without the need for a specific timer. 1770 Recovery requires a Confirm to be transmitted and successfully 1771 received. The mechanism to cause this is that the Responding node 1772 MUST reject the incoming message with a "No Routing State" error 1773 message (Appendix A.4.4.5) back to the Querying node, which MUST 1774 interpret this as caused by a lost Confirm; the Querying node MUST 1775 regenerate the Confirm purely from local state (e.g. in particular it 1776 needs to remember a valid Responder Cookie). 1778 In all cases, Responses MUST be sent promptly to avoid spurious 1779 retransmissions. Nodes generating any type of retransmission MUST be 1780 prepared to receive (and match) a reply to any of them (not just the 1781 one most recently sent). 1783 The basic rate-control requirements for datagram mode traffic are 1784 deliberately minimal. A single rate limiter applies to all traffic 1785 (for all interfaces and message types). It applies to 1786 retransmissions as well as new messages, although an implementation 1787 MAY choose to prioritise one over the other. When the rate limiter 1788 is in effect, datagram mode messages are queued until transmission is 1789 re-enabled, or an error condition MAY be indicated back to local 1790 signaling applications. The rate limiting mechanism is 1791 implementation defined, but it is RECOMMENDED that a token bucket 1792 limiter as described in [27] be used. 1794 5.4. Connection Mode Transport 1796 Encapsulation in connection mode is more complex, because of the 1797 variation in available transport functionality. This issue is 1798 treated in Section 5.4.1. The actual encapsulation is given in 1799 Section 5.4.2. 1801 5.4.1. Choice of Transport Protocol 1803 It is a general requirement of the NTLP defined in [24] that it 1804 should be able to support bundling (of small messages), fragmentation 1805 (of large messages), and message boundary delineation. Not all 1806 transport protocols natively support all these features. 1808 TCP provides both bundling and fragmentation, but not message 1809 boundaries. However, the length information in the common header 1810 allows the message boundary to be discovered during parsing. 1812 SCTP [14] satisfies all requirements. 1814 DCCP [26] is message based but does not provide bundling or 1815 fragmentation. Bundling can be carried out by the GIST layer 1816 sending multiple messages in a single datagram; because the common 1817 header includes length information, the message boundaries within 1818 the datagram can be discovered during parsing. Fragmentation of 1819 GIST messages over multiple datagrams should be avoided, because 1820 of amplification of message loss rates that this would cause. 1822 The bundling together of small messages is either built into the 1823 transport protocol or can be carried out by the GIST layer during 1824 message construction. Either way, two approaches can be 1825 distinguished: 1827 1. As messages arrive for transmission they are gathered into a 1828 bundle until a size limit is reached or a timeout expires (cf. 1829 the Nagle algorithm of TCP or similar optional functionality in 1830 SCTP). This provides maximal efficiency at the cost of some 1831 latency. 1833 2. Messages awaiting transmission are gathered together while the 1834 node is not allowed to send them (e.g. because it is congestion 1835 controlled). 1837 The second type of bundling is always appropriate. For GIST, the 1838 first type SHOULD NOT be used for 'trigger' (i.e. state-changing) 1839 messages, but may be appropriate for refresh messages. These 1840 distinctions are known only to the signaling applications, but MAY be 1841 indicated (as an implementation issue) by setting the priority 1842 transfer attribute. 1844 It can be seen that all of these transport protocol options can be 1845 supported by the basic GIST message format already presented. GIST 1846 messages requiring fragmentation must be carried using a reliable 1847 transport protocol, TCP or SCTP. This specification defines only the 1848 use of TCP, but other possibilities could be included without 1849 additional work on message formatting. 1851 5.4.2. Encapsulation Format 1853 The GIST message, consisting of common header and TLVs, is carried 1854 directly in the transport protocol (possibly incorporating transport 1855 layer security protection). Further messages can be carried in a 1856 continuous stream (for TCP), or up to the next transport layer 1857 message boundary (for SCTP/DCCP/UDP). This situation is shown in 1858 Figure 5. 1860 +---------------------------------------------+ 1861 | L2 Header | 1862 +---------------------------------------------+ 1863 | IP Header | ^ 1864 | Source address = signaling source | ^ 1865 | Destination address = signaling destination | . 1866 +---------------------------------------------+ . 1867 | L4 Header | . ^ 1868 | (Standard TCP/SCTP/DCCP/UDP header) | . ^ 1869 +---------------------------------------------+ . . 1870 | GIST Message | . . ^ 1871 | (Common header and TLVs as in section 5.1) | . . ^ Scope of 1872 +---------------------------------------------+ . . . security 1873 | Additional GIST messages, each with its | . . . protection 1874 | own common header, either as a continuous | . . . (depending 1875 | stream, or continuing to the next L4 | . . . on channel 1876 . message boundary . . . . security 1877 . . V V V mechanism 1878 . . V V V in use) 1880 Figure 5: Connection Mode Encapsulation 1882 5.5. Message Type/Encapsulation Relationships 1884 GIST has four primary message types (Query/Response/Confirm/Data) and 1885 three possible encapsulation methods (D-Mode Normal/D-Mode Query/ 1886 C-Mode). For information, the allowed combinations of message type 1887 and encapsulation are given in the table below. If a message arrives 1888 with an invalid encapsulation (e.g. a Query arrives over a messaging 1889 association), this MUST be rejected with an "Incorrect Encapsulation" 1890 error message (Appendix A.4.4.3). However, it should be noted that 1891 the processing of the message at the receiver is not otherwise 1892 affected by the encapsulation method used, with the exception that 1893 the decapsulation process may provide additional information (e.g. 1894 translated addresses or IP hop count) which is used in the subsequent 1895 message processing. 1897 +---------------+----------------+-------------------+--------------+ 1898 | Message | D-Mode Normal | D-Mode Query | C-Mode | 1899 +---------------+----------------+-------------------+--------------+ 1900 | GIST-Query | Never | Always | Never | 1901 | | | | | 1902 | GIST-Response | Unless a | Never | If a | 1903 | | messaging | | messaging | 1904 | | association is | | association | 1905 | | being re-used | | is being | 1906 | | | | re-used | 1907 | | | | | 1908 | GIST-Confirm | Unless a | Never | If a | 1909 | | messaging | | messaging | 1910 | | association | | association | 1911 | | has been set | | has been set | 1912 | | up or is being | | up or is | 1913 | | re-used | | being | 1914 | | | | re-used | 1915 | | | | | 1916 | GIST-Data | If routing | If no routing | If a | 1917 | | state exists | state exists and | messaging | 1918 | | for the flow | the MRI can be | association | 1919 | | but no | used to derive | exists | 1920 | | appropriate | the query | | 1921 | | messaging | encapsulation | | 1922 | | association | | | 1923 +---------------+----------------+-------------------+--------------+ 1925 5.6. Error Message Processing 1927 Special rules apply to the encapsulation and transmission of error 1928 messages. 1930 GIST only generates error messages in response to incoming messages. 1931 (Error messages MUST NOT be generated in response to incoming error 1932 messages.) The routing and encapsulation of the error message is 1933 derived from that of the message that caused the error; in 1934 particular, local routing state is not consulted. Routing state and 1935 messaging association state MUST NOT be created to handle the error, 1936 and error messages MUST NOT be retransmitted explicitly by GIST, 1937 although they are subject to the same rate control as other messages. 1939 o If the incoming message was received in datagram mode, the error 1940 MUST be sent in datagram mode using the 'normal' encapsulation, 1941 using the addressing information from the NLI object in the 1942 incoming message. If the NLI could not be determined, the error 1943 MUST be sent to the IP source of the incoming message if the S 1944 flag was set in it. The NLI object in the GIST-Error message 1945 reports information about the generator of the error. 1947 o If the incoming message was received over a messaging association, 1948 the error MUST be sent back over the same messaging association. 1950 The NSLPID in the common header of the GIST-Error is the null value 1951 (as for GIST-MA-Hello). If for any reason the error message cannot 1952 be sent (for example, because an error message is too large to send 1953 in datagram mode), an error should be logged locally. 1955 5.7. Messaging Association Setup 1957 5.7.1. Overview 1959 A key attribute of GIST is that it is flexible in its ability to use 1960 existing transport and security protocols. Different transport 1961 protocols may have performance attributes appropriate to different 1962 environments; different security protocols may fit appropriately with 1963 different authentication infrastructures. Even given an initial 1964 default mandatory protocol set for GIST, the need to support new 1965 protocols in the future cannot be ruled out, and secure feature 1966 negotation cannot be added to an existing protocol in a backwards- 1967 compatible way. Therefore, some sort of capability discovery is 1968 required. 1970 Capability discovery is carried out in GIST-Query/Response messages, 1971 using Stack-Proposal and Stack-Configuration-Data objects. If a new 1972 messaging association is required it is then set up, followed by a 1973 GIST-Confirm. Messaging association re-use is achieved by short- 1974 circuiting this exchange by sending the GIST-Response or GIST-Confirm 1975 messages on an existing association (Section 4.4.2); whether to do 1976 this is a matter of local policy. The end result of this process is 1977 a messaging association which is a stack of protocols. If multiple 1978 associations exist, it is a matter of local policy how to distribute 1979 messages over them, subject to respecting the transfer attributes 1980 requested for each message. 1982 Every possible protocol for a messaging association has the following 1983 attributes: 1985 o MA-Protocol-ID, a 1-byte IANA assigned value. 1987 o A specification of the (non-negotiable) policies about how the 1988 protocol should be used (for example, in which direction a 1989 connection should be opened). 1991 o Optionally, formats for carrying the protocol addressing and other 1992 configuration information in higher-layer-addressing information 1993 elements in the Stack-Configuration-Data object. (Some protocols 1994 do not require such higher-layer-addressing information.) There 1995 are different formats depending on whether the information is 1996 carried in the Query or Response. 1998 A Stack-Proposal object is simply a list of profiles; each profile is 1999 a sequence of MA-Protocol-IDs. A Stack-Proposal is generally 2000 accompanied by a Stack-Configuration-Data object which can carry 2001 higher-layer-addressing information elements for any protocol listed 2002 in the Stack-Proposal which needs it. A higher-layer-addressing 2003 information element may apply globally (to all instances of the 2004 protocol in the Stack-Proposal) or be tagged as applying to a 2005 specific instance; for example, this can be used to carry different 2006 port numbers for TCP depending on whether it is to be used with or 2007 without TLS. A higher-layer-addressing information element may also 2008 be flagged as 'not usable'; for example, a NAT which could not handle 2009 SCTP would set this in higher-layer-addressing about SCTP. A 2010 protocol flagged this way MUST NOT be used for a messaging 2011 association. If the Stack-Proposal and Stack-Configuration-Data are 2012 both present but not consistent (e.g. they refer to different 2013 protocols, or a higher-layer-addressing element refers to a non- 2014 existent profile), a "Object Value Error" error message 2015 (Appendix A.4.4.10) with subcode 5 ("SP-SCD Mismatch") MUST be 2016 returned and the message dropped. 2018 A node generating a Stack-Configuration-Data object MUST honour the 2019 implied protocol configurations for the period during which a 2020 messaging association might be set up; in particular, it MUST be 2021 immediately prepared to accept incoming datagrams or connections at 2022 the protocol/port combinations advertised. However, the object 2023 contents MUST be retained only for the duration of the Query/Response 2024 exchange and any following association setup, and afterwards 2025 discarded. (They may become invalid because of expired bindings at 2026 intermediate NATs, or because the advertising node is using agile 2027 ports.) 2029 A GIST-Query requesting association setup always contains a Stack- 2030 Proposal and Stack-Configuration-Data object, and unless re-use 2031 occurs, the GIST-Response does so also. For a GIST-Response, the 2032 Stack-Proposal MUST be invariant for the combination of outgoing 2033 interface and NSLPID (it MUST NOT depend on the GIST-Query). Once 2034 the messaging association is set up, the querying node repeats the 2035 responder's Stack-Proposal over it in the GIST-Confirm. The 2036 responding node MUST verify this to ensure that no bidding-down 2037 attack has occurred. 2039 5.7.2. Protocol Definition: Forwards-TCP 2041 This defines a basic configuration for the use of TCP between peers. 2042 Support for this protocol is REQUIRED; associations using it can 2043 carry messages with the transfer attribute Reliable=True. The 2044 connection is opened in the forwards direction, from the querying 2045 node, towards the responder at a previously advertised port. The 2046 higher-layer-addressing formats are: 2048 o downstream: no information (only padding). 2050 o upstream: 2 byte port number at which the connection will be 2051 accepted. 2053 5.7.3. Protocol Definition: Transport Layer Security 2055 This defines the use of transport layer security as a basic channel 2056 security mechanism. Support for this protocol is mandatory; 2057 associations using it can carry messages with the transfer attribute 2058 Secure=True. For use with TCP, implementation of TLS1.0 [7] is 2059 REQUIRED and implementation of TLS1.1 [8] is RECOMMENDED. (If an 2060 unreliable transport such as DCCP or UDP is defined for GIST in the 2061 future, TLS would be implemented with it using DTLS [35].) This 2062 specification makes no additional requirements on the TLS 2063 implementation (e.g. ciphersuites or authentication mechanisms) since 2064 these can be negotiated within TLS itself. 2066 No higher-layer-addressing format is defined for TLS. 2068 5.7.4. Additional Protocol Options 2070 Further protocols or configurations could be defined in the future 2071 for additional performance or flexibility. Examples are: 2073 o SCTP or DCCP as alternatives to TCP, with essentially the same 2074 configuration. 2076 o SigComp [20] for message compression. 2078 o IPsec [31], ssh [32], or HIP/IPsec [33] for channel security. 2080 o Alternative modes of TCP operation, for example where it is set up 2081 from the responder to the querying node. 2083 5.8. Specific Message Routing Methods 2085 Each message routing method (see Section 3.3) requires the definition 2086 of the format of the message routing information (MRI) and Query- 2087 encapsulation rules. These are given in the following subsections 2088 for the various possible message routing methods. 2090 5.8.1. The Path-Coupled MRM 2092 5.8.1.1. Message Routing Information 2094 For the path-coupled MRM, this is essentially the Flow Identifier as 2095 in [24]. Minimally, this could just be the flow destination address; 2096 however, to account for policy based forwarding and other issues a 2097 more complete set of header fields should be used (see Section 4.3.4 2098 and Section 7.2 for further discussion). 2100 MRI = network-layer-version 2101 source-address prefix-length 2102 destination-address prefix-length 2103 IP-protocol 2104 diffserv-codepoint 2105 [ flow-label ] 2106 [ ipsec-SPI / L4-ports] 2108 Additional control information defines whether the flow-label, SPI 2109 and port information are present, and whether the IP-protocol and 2110 diffserv-codepoint fields should be interpreted as significant. The 2111 source and destination addresses MUST be real node addresses, but 2112 prefix lengths other than 32/128 (for IPv4/6) MAY be used to 2113 implement address 'wildcarding', allowing the MRI to refer to traffic 2114 to or from a wider address range. The MRI format allows a 2115 potentially very large number of different flag and field 2116 combinations. A GIST implementation that cannot interpret the MRI in 2117 a message MUST return an "Object Value Error" message 2118 (Appendix A.4.4.10) with subcodes 1 ("Value Not Supported") or 2 2119 ("Invalid Flag-Field Combination") and drop the message. 2121 5.8.1.2. Downstream Query Encapsulation 2123 Where the signaling message is travelling in the same ('downstream') 2124 direction as the flow defined by the MRI, the IP addressing for Query 2125 messages is as follows. Support for this encapsulation is REQUIRED. 2127 o The destination address MUST be the flow destination address as 2128 given in the MRI of the message payload. 2130 o By default, the source address is the flow source address, again 2131 from the MRI. This provides the best likelihood that the message 2132 will be correctly routed through any region performing per-packet 2133 policy-based forwarding or load balancing which takes the source 2134 address into account. However, there may be circumstances where 2135 the use of the signaling source address is preferable, such as: 2137 * In order to receive ICMP error messages about the Query message 2138 (such as unreachable port or address). If these are delivered 2139 to the flow source rather than the signaling source, it will be 2140 very difficult for the querying node to detect that it is the 2141 last GIST node on the path. 2143 * In order to recieve GIST error messages where the error message 2144 sender could not interpret the NLI in the original message. 2146 * In order to attempt to run GIST through an unmodified NAT, 2147 which will only process and translate IP addresses in the IP 2148 header. 2150 Because of these considerations, use of the signaling source 2151 address is allowed as an option, with use based on local policy. 2152 A node SHOULD use the flow source address for initial Query 2153 messages, but SHOULD transition to the signaling source address 2154 for some retransmissions or as a matter of static configuration 2155 (e.g. if a NAT is known to be in the path out of a certain 2156 interface). A flag in the common header tells the message 2157 receiver which option was used. 2159 It is vital that the Query message mimics the actual data flow as 2160 closely as possible, since this is the basis of how the signaling 2161 message is attached to the data path. To this end, GIST SHOULD set 2162 the DiffServ codepoint and (for IPv6) flow label to match the values 2163 in the MRI if this would be needed to ensure correct routing. 2165 Any message sent in datagram mode SHOULD be below a conservative 2166 estimate of the path MTU, for which this specification takes the 2167 value 512 bytes as a default. It is possible that fragmented 2168 datagrams including an RAO will not be correctly handled in the 2169 network, so the sender SHOULD set the DF (do not fragment) bit in the 2170 IPv4 header in order to detect that a message has encountered a link 2171 with an unusually low MTU. In this case, it MUST use the signaling 2172 source address for the IP source address in order to receive the ICMP 2173 error. 2175 A GIST implementation SHOULD apply validation checks to the MRI, to 2176 reject Query messages that are being injected by nodes with no 2177 legitimate interest in the flow being signalled for. In general, if 2178 the GIST node can detect that no flow could arrive over the same 2179 interface as the Query message, it MUST be rejected. (Such checks 2180 apply only to messages with the query encapsulation, since only those 2181 messages are required to track the flow path.) The main checks are 2182 that the IP version should match the version(s) used on that 2183 interface, and that the full range of source addresses (the source- 2184 address masked with its prefix-length) would pass ingress filtering 2185 checks. 2187 5.8.1.3. Upstream Query Encapsulation 2189 In some deployment scenarios it is desirable and logically possible 2190 to set up routing state in the upstream direction (from flow receiver 2191 towards the sender). This could be used to support firewall 2192 signaling to control traffic from an 'un-cooperative' sender, or 2193 signaling in general where the flow sender was not NSIS-capable. 2194 This is incorporated into GIST by defining an encapsulation and 2195 processing rules for sending Query messages upstream. 2197 In general, it is not possible to determine the hop-by-hop route 2198 upstream because of asymmetric routing. However, in particular 2199 cases, the upstream peer can be discovered with a high degree of 2200 confidence, for example: 2202 o The upstream GIST peer is 1 IP hop away, and can be reached by 2203 tracing back through the interface on which the flow arrives. 2205 o The upstream peer is a border router of a single-home (stub) 2206 network. 2208 This section defines an upstream Query encapsulation and validation 2209 checks for when it can be used. The functionality to generate 2210 upstream Queries is OPTIONAL, but if received they MUST be processed 2211 in the normal way (no special functionality is needed for this). It 2212 is possible for routing state (for a given MRI and NSLPID) to be 2213 installed by both upstream and downstream Query exchanges. If the 2214 SIDs are different, these items of routing state MUST be considered 2215 as independent; if they match, that installed by the downstream 2216 exchange MUST take precedence. 2218 The details of the encapsulation are as follows: 2220 o The destination address SHOULD be the flow source address as given 2221 in the MRI of the message payload. An implementation with more 2222 detailed knowledge of local routing MAY use an alternative 2223 destination address (e.g. the address of its default router). 2225 o The source address SHOULD be the signaling node address. 2227 o The DiffServ codepoint and (for IPv6) flow label MAY be set to 2228 match the values from the MRI, as in the downstream case. The 2229 same considerations about message size and fragmentation also 2230 apply as in the downstream case, and RAO setting and UDP port 2231 selection are also the same. 2233 o The IP-TTL of the message MUST be set to 255. 2235 The sending GIST implementation SHOULD attempt to send the Query 2236 message out of the same interface and to the same link layer 2237 neighbour from which the data packets of the flow are arriving. 2239 The receiving GIST node MAY apply validation checks to the message 2240 and MRI, to reject Query messages which have reached a node at which 2241 they can no longer be trusted. In particular, a node SHOULD reject a 2242 message which has been propagated more than one IP hop, with a 2243 "Invalid IP TTL" error message (Appendix A.4.4.11). This can be 2244 determined by examining the received IP TTL, similar to the 2245 generalised IP TTL security mechanism described in [23]. 2246 Alternatively, receipt of an upstream Query at the flow source MAY be 2247 used to trigger setup of NTLP state in the downstream direction. 2248 These restrictions may be relaxed in a future version. 2250 5.8.2. The Loose-End MRM 2252 This MRM is used to discover GIST nodes with particular properties in 2253 the direction of a given address, for example to discover a NAT along 2254 the upstream data path (e.g. as in [28]. 2256 5.8.2.1. Message Routing Information 2258 For the loose-end MRM, only a simplified version of the Flow 2259 Identifier is needed. 2261 MRI = network-layer-version 2262 source-address 2263 destination-address 2265 The source address is the address of the node initiating the 2266 discovery process, for example the node that will be the data 2267 receiver in the NAT discovery case. The destination address is the 2268 address of a node which is expected to be the 'other side' of the 2269 node to be discovered. Additional control information defines the 2270 direction of the message relative to this flow as in the path-coupled 2271 case. 2273 5.8.2.2. Downstream Query Encapsulation 2275 Only one encapsulation is defined for the loose-end MRM; by 2276 convention, this is referred to as the downstream encapsulation, and 2277 is defined as follows: 2279 o The IP destination address MUST be the destination address as 2280 given in the MRI of the message payload. 2282 o By default, the IP source address is the source address, again 2283 from the MRI. However, the use of the signaling source address is 2284 allowed as in the case of the path-coupled MRM. 2286 There are no special requirements on the setting of the DiffServ 2287 codepoint, IP TTL, or (for IPv6) the flow label. Nor are any special 2288 validation checks applied. 2290 Restrictions on message size and setting of the DF (do not fragment) 2291 bit apply as in the case of the path-coupled MRM. 2293 6. Formal Protocol Specification 2295 This section provides a more formal specification of the operation of 2296 GIST processing, in terms of rules for transitions between states of 2297 a set of communicating state machines within a node. The following 2298 description captures only the basic protocol specification; 2299 additional mechanisms can be used by an implementation to accelerate 2300 route change processing, and these are captured in Section 7.1. 2302 Conceptually, GIST processing at a node may be seen in terms of 4 2303 types of cooperating state machine: 2305 1. There is a top-level state machine which represents the node 2306 itself (Node-SM). It is responsible for the processing of events 2307 which cannot be directed towards a more specific state machine, 2308 for example, inbound messages for which no routing state 2309 currently exists. This machine exists permanently, and is 2310 responsible for creating 'per-flow' state machines to manage the 2311 GIST handshake and routing state maintenance procedures. 2313 2. For each flow and signaling direction where the node is 2314 responsible for the creation of routing state, there is an 2315 instance of a Query-Node state machine (Query-SM). This machine 2316 sends Query and Confirm messages and waits for Responses, 2317 according to the requirements from local API commands or timer 2318 processing (e.g. message repetition or routing state refresh). 2320 3. For each flow and signaling direction where the node has accepted 2321 the creation of routing state by a peer, there is an instance of 2322 a Responding-Node state machine (Response-SM). This machine is 2323 responsible for managing the status of the routing state for that 2324 flow. Depending on policy, it MAY be responsible for 2325 [re]transmission of Response messages, or this MAY be handled by 2326 the Node-SM, and a Response-SM is not even created for a flow 2327 until a properly formatted Confirm has been accepted. 2329 4. Messaging assocations have their own lifecycle, represented by 2330 MA-SM, from when they are first created (in an 'incomplete' 2331 state, listening for an inbound connection or waiting for 2332 outbound connections to complete), to when they are active and 2333 available for use. 2335 Apart from the fact that the various machines can be created and 2336 destroyed by each other, there is almost no interaction between them. 2337 The machines for different flows do not interact; the Query-SM and 2338 Response-SM for a single flow and signaling direction do not 2339 interact. That is, the Response-SM which accepts the creation of 2340 routing state for a flow on one interface has no direct interaction 2341 with the Query-SM which sets up routing state on the next interface 2342 along the path. This interaction is mediated instead through the 2343 NSLP. 2345 The state machine descriptions use the terminology rx_MMMM, tg_TTTT 2346 and er_EEEE for incoming messages, API/lower layer triggers and error 2347 conditions respectively. The possible events of these types are 2348 given in the table below. In addition, timeout events denoted 2349 to_TTTT may also occur; the various timers are listed independently 2350 for each type of state machine in the following subsections. 2352 +---------------------+---------------------------------------------+ 2353 | Name | Meaning | 2354 +---------------------+---------------------------------------------+ 2355 | rx_Query | A GIST Query message has been received. | 2356 | | | 2357 | rx_Response | A GIST Response message has been received. | 2358 | | | 2359 | rx_Confirm | A GIST Confirm message has been received. | 2360 | | | 2361 | rx_Data | A GIST Data message has been received. | 2362 | | | 2363 | rx_Message | rx_Query||rx_Response||rx_Confirm||rx_Data. | 2364 | | | 2365 | rx_Hello | A GIST MA-Hello message has been received. | 2366 | | | 2367 | tg_NSLPData | A signaling application has requested data | 2368 | | transfer (via API SendMessage). | 2369 | | | 2370 | tg_Connected | The protocol stack for a messaging | 2371 | | association has completed connecting. | 2372 | | | 2373 | tg_RawData | GIST wishes to transfer data over a | 2374 | | particular messaging association. | 2375 | | | 2376 | er_NoRSM | A "No Routing State" error was received. | 2377 | | | 2378 | er_MAConnect | A messaging association protocol failed to | 2379 | | complete a connection. | 2380 | | | 2381 | er_MAFailure | A messaging association failed. | 2382 +---------------------+---------------------------------------------+ 2384 6.1. Node Processing 2386 The Node level state machine is responsible for processing events for 2387 which no more appropriate messaging association state or routing 2388 state exists. Its structure is trivial: there is a single state 2389 ('Idle'); all events cause a transition back to Idle. Some events 2390 cause the creation of other state machines. The only events that are 2391 processed by this state machine are incoming GIST messages (Query/ 2392 Response/Confirm/Data) and API requests to send data; all other 2393 events are impossible. In addition to this event processing, the 2394 Node level machine is responsible for managing listening endpoints 2395 for messaging associations (although these relate to Responding node 2396 operation, they cannot be handled by the Responder state machine 2397 since they are not created per flow.) The processing rules for each 2398 event are as follows: 2400 Rule 1 (rx_Query): 2402 if (routing state can be created without a full 3-way handshake) then 2403 create R-SM and pass message to it 2404 else 2405 send Response 2407 Rule 2 (rx_Response): 2409 // should already have a Q-SM to handle this 2410 discard message 2411 send "No Routing State" error message 2413 Rule 3 (rx_Confirm): 2415 if (routing state can be created without a full 3-way handshake) then 2416 // should already have R-SM for it which would handle this message 2417 discard message 2418 send "No Routing State" error message 2419 else 2420 create R-SM and pass message to it 2422 Rule 4 (rx_Data): pass directly to NSLP 2424 Rule 5 (tg_NSLPData): 2426 if Q-mode encapsulation is not possible for this MRI 2427 reject message with an error 2428 else 2429 if (local policy & transfer attributes say routing 2430 state is not needed) then 2431 send message statelessly 2432 else 2433 create Q-SM and pass message to it 2435 6.2. Query Node Processing 2437 The Querying-Node state machine (Q-SM) has three states: 2439 o Awaiting Response 2441 o Established 2443 o Awaiting Refresh 2445 The Q-SM is created by the N-SM machine as a result of a request to 2446 send a message for a flow in a signaling direction where the 2447 appropriate state does not exist. The Query is generated immediately 2448 and the No_Response timer is started. The NSLP data MAY be carried 2449 in the Query if local policy and the transfer attributes allow it, 2450 otherwise it MUST be queued locally pending MA establishment. Then 2451 the machine transitions to the Awaiting Response state, in which 2452 timout-based retransmissions are handled. Data messages (rx_Data 2453 events) should not occur in this state; if they do, this may indicate 2454 a lost Response and a node MAY also retransmit a Query for this 2455 reason. 2457 Once a Response has been successfully recieved and routing state 2458 created, the machine transitions to Established, during which NSLP 2459 data can be sent and received normally. Further Responses received 2460 in this state MUST be treated the same way (this may be the result of 2461 a lost Confirm). The Awaiting Refresh state can be considered as a 2462 substate of Established, where a new Query has been generated to 2463 refresh the routing state (as in Awaiting Response) but NSLP data can 2464 be handled normally. 2466 The timers relevant to this state machines are as follows: 2468 Refresh_QNode: Indicates when the routing state stored by this state 2469 machine must be refreshed. It is reset whenever a Response is 2470 received indicating that the routing state is still valid. 2471 Implementations MUST set the period of this timer based on the 2472 value in the RS-validity-time field of a Reponse message to ensure 2473 that a Query is generated before the peer's routing state expires. 2475 No_Response: Indicates that a Response has not been received in 2476 answer to a Query. This is started whenever a Query is sent and 2477 stopped when a Response is received. 2479 Inactive_QNode: Indicates that no traffic is currently being handled 2480 by this state machine. This is reset whenever the state machine 2481 handles NSLP data (in either direction). When it expires, the 2482 state machine MAY be deleted. The period of the timer can be set 2483 at any time via the API (SetStateLifetime), and if the period is 2484 reset in this way the timer itself SHOULD be restarted. 2486 The main events (including all those that cause state transitions) 2487 are shown in the figure below, tagged with the number of the 2488 processing rule that is used to handle the event. These rules are 2489 listed after the diagram. All events not shown or described in the 2490 text above are assumed to be impossible in a correct implementation. 2492 [Initialisation] +-----+ 2493 -------------------------|Birth| 2494 | +-----+ 2495 | rx_Response[4] 2496 | || tg_NSLPData[5] 2497 | tg_NSLPData[1] er_NoRSM[3] || rx_Data[7] 2498 | -------- ------------------ ------- 2499 | | V | V | V 2500 | | V | V | V 2501 | +----------+ | +-----------+ 2502 ---->>| Awaiting | ---------------- |Established| 2503 ------| Response |---------------------------->> | | 2504 | +----------+ rx_Response[4] +-----------+ 2505 | ^ | ^ | 2506 | ^ | ^ | 2507 | -------- | | 2508 | to_No_Response[2] | | 2509 | [!nResp_reached] tg_NSLPData[5] | | 2510 | || rx_Data[7] | | 2511 | -------- | | 2512 | | V | | 2513 | to_No_Response[2] | V | | 2514 | [nResp_reached] +-----------+ rx_Response[4] | | 2515 ---------- -----------| Awaiting |----------------- | 2516 | | | Refresh |<<------------------- 2517 | | +-----------+ to_Refresh_QNode[8] 2518 | | ^ | 2519 | | ^ | 2520 | | -------- 2521 | | to_No_Response[2] 2522 | | [!nResp_reached] 2523 V V 2524 V V 2525 +-----+ 2526 |Death|<<--------------- 2527 +-----+ to_Inactive_QNode[6] 2528 (from all states) 2530 Figure 6: Query Node State Machine 2531 The processing rules are as follows: 2533 Rule 1: Store the message for later transmission 2535 Rule 2: 2537 if number of Queries sent has reached the threshold 2538 // nQuery_isMax is true 2539 indicate No Response error to NSLP 2540 destroy self 2541 else 2542 send Query message 2543 start No_Response timer with new value 2545 Rule 3: 2547 // Assume the Confirm was lost in transit so resend it 2548 // for the last Response we received 2549 send Confirm message 2550 restart Refresh_QNode and Inactive_QNode timers 2552 Rule 4: 2554 if a new MA-SM is needed create one 2555 if a Confirm is required send Confirm message 2556 pass any NSLP data to the NSLP 2557 send any stored Data messages 2558 stop No_Response timer 2559 start Refresh_QNode and Inactive_QNode timers 2561 Rule 5: 2563 send Data message 2564 restart Inactive_QNode timer 2566 Rule 6: Terminate 2568 Rule 7: 2570 pass any data to the NSLP 2571 (re)start Inactive_QNode timer 2573 Rule 8: 2575 send Query message 2576 start No_Response timer 2577 stop Refresh_QNode timer 2579 6.3. Responder Node Processing 2581 The Responding-Node state machine (R-SM) has three states: 2583 o Awaiting Confirm 2585 o Established 2587 o Awaiting Refresh 2589 The policy governing the creation of the R-SM has 3 cases (ignoring 2590 the case of pure stateless operation where a Response may be 2591 generated or the message propagated forwards, but no routing state is 2592 created at the GIST level): 2594 1. It is created on receiving a Query, no Confirm is requested. 2596 2. It is created on receiving a Query, but a Confirm is requested. 2597 A timer is used to retransmit Response messages and the R-SM is 2598 destroyed if no valid Confirm is received. 2600 3. It cannot be created until a valid Confirm is received (the 2601 initial Query will have been handled by the Node level machine). 2603 In case 2 the R-SM is created in the Awaiting Confirm state, and 2604 remains there until a Confirm is received, at which point it 2605 transitions to Established. In cases 1 and 3 the R-SM is created 2606 already in the Established state. In Established state the NSLP can 2607 send and receive data normally, and any additional rx_Confirm events 2608 MUST be silently ignored. The Awaiting Refresh state can be 2609 considered a substate of Established, where a Query has been received 2610 to begin the routing state refresh. 2612 In the Awaiting Refresh state the R-SM behaves as in the Awaiting 2613 Confirm state, except that the NSLP can still send and receive data. 2614 In particular, in both states there is timer-based retransmission of 2615 Response messages until a Confirm is received; additional rx_Query 2616 events in these states MUST also generate a response and restart the 2617 no_Confirm timer. 2619 The timers relevant to the operation of this state machine are as 2620 follows: 2622 Expire_RNode: Indicates when the routing state stored by this state 2623 machine needs to be expired. It is reset whenever a Query or 2624 Confirm (depending on local policy) is received indicating that 2625 the routing state is still valid. Note that state cannot be 2626 refreshed from the R-Node. 2628 No_Confirm: Indicates that a Confirm has not been received in answer 2629 to a Response. This is started/reset whenever a Response is sent 2630 and stopped when a Confirm is received. 2632 The detailed state transitions and processing rules are described 2633 below as in the Query node case. 2635 rx_Query[1] rx_Query[5] 2636 [confirmRequired] +-----+ [!confirmRequired] 2637 -------------------------|Birth|---------------------------- 2638 | +-----+ | 2639 | | rx_Confirm[2] | 2640 | ---------------------------- | 2641 | | | 2642 | tg_NSLPData[3] | | 2643 | tg_NSLPData[7] || rx_Query[5] | | 2644 | || rx_Query[1] || rx_Data[4] | | 2645 | || rx_Data[6] [!confirmRequired] | | 2646 | -------- -------------- | | 2647 | | V | V V V 2648 | | V | V V V 2649 | +----------+ | +-----------+ 2650 ---->>| Awaiting | rx_Confirm[8] -----------|Established| 2651 ------| Confirm |------------------------------>> | | 2652 | +----------+ +-----------+ 2653 | ^ | ^ | 2654 | ^ | tg_NSLPData[3] ^ | 2655 | -------- || rx_Query[1] | | 2656 | to_No_Confirm[9] || rx_Data[4] | | 2657 | [!nConf_reached] -------- | | 2658 | | V | | 2659 | to_No_Confirm[9] | V | | 2660 | [nConf_reached] +-----------+ rx_Confirm[8] | | 2661 ---------- ------------| Awaiting |----------------- | 2662 | | | Refresh |<<------------------- 2663 | | +-----------+ rx_Query[1] 2664 | | ^ | [confirmRequired] 2665 | | ^ | 2666 | | -------- 2667 V V to_No_Confirm[9] 2668 V V [!nConf_reached] 2669 +-----+ 2670 |Death|<<--------------------- 2671 +-----+ to_Expire_RNode[10] 2672 (from all states) 2674 Figure 7: Responder Node State Machine 2675 The processing rules are as follows: 2677 Rule 1: 2679 // a Confirm message is required 2680 send Response message 2681 (re)start No_Confirm timer 2683 Rule 2: 2685 if a new MA-SM would be needed for this peer 2686 create one in listening state 2687 start Expire_RNode timer 2689 Rule 3: send the Data message 2691 Rule 4: pass data to NSLP 2693 Rule 5: 2695 // no Confirm message is required 2696 send Response message 2697 start Expire_RNode timer 2699 Rule 6: send "No Routing State" error message 2701 Rule 7: store Data message 2703 Rule 8: 2705 send any stored Data messages 2706 stop No_Confirm timer 2707 start Expire_RNode timer 2709 Rule 9: 2711 if number of Responses sent has reached threshold 2712 // nResp_isMax is true 2713 destroy self 2714 else 2715 send Response message 2716 start No_Response timer 2718 Rule 10: destroy self 2720 6.4. Messaging Association Processing 2722 Messaging associations are modelled for use within GIST with a simple 2723 3-state process. The Awaiting Connection state indicates that the MA 2724 is waiting for the connection process(es) for every protocol in the 2725 messaging association to complete; this might involve creating 2726 listening endpoints or attempting active connects. Timers may also 2727 be necessary to detect connection failure (e.g. no incoming 2728 connection within a certain period), but these are not modelled 2729 explicitly. The Connected state indicates that the MA is open and 2730 ready to use. In addition there is an Idle state in which the local 2731 node no longer requires the messaging association but the remote node 2732 still wants it to be kept open. 2734 Clearly, many internal details of the messaging assocation protocols 2735 are hidden in this model, especially where the messaging association 2736 uses multiple protocol layers. Note also that although the existence 2737 of messaging associations is not directly visible to NSLPs, there is 2738 some interaction between the two because security-related information 2739 becomes available during the open process, and this may be indicated 2740 to signaling applications if they have requested it. 2742 The timers relevant to the operation of this state machine are as 2743 follows: 2745 SendHello: Indicates that an MAHello message should be sent to the 2746 remote node. The period of this timer is determined by the MA- 2747 Hold-Time sent by the remote node during the Query/Response 2748 exchange. 2750 NoHello: Indicates that no MAHello has been received from the remote 2751 node for a period of time. The period of this timer is sent to 2752 the remote node as the MA-Hold-Time during the Query/Response 2753 exchange. 2755 NoActivity: Indicates that the link has been inactive for a period of 2756 time. The period of this timer is implementation specific but is 2757 likely to be related to the period of the NoHello timer. 2759 The detailed state transitions and processing rules are described 2760 below as in the Query node case. 2762 [Initialisation] +-----+ 2763 ----------------------------|Birth| 2764 | +-----+ 2765 | tg_RawData[1] 2766 | || rx_Message[2] 2767 | || rx_Hello[3] 2768 | tg_RawData[5] || to_SendHello[4] 2769 | -------- -------- 2770 | | V | V 2771 | | V | V 2772 | +----------+ +-----------+ 2773 ---->>| Awaiting | tg_Connected[6] | Connected | 2774 ------|Connection|----------------------->>| | 2775 | +----------+ +-----------+ 2776 | ^ | 2777 | tg_RawData[1] ^ | 2778 | || rx_Message[2] | |to_NoActivity[7] 2779 | | V 2780 | | V 2781 | er_MAConnect[8] +-----+ to_NoHello[8] +-----------+ 2782 ---------------->>|Death|<<----------------| Idle | 2783 +-----+ | | 2784 ^ +-----------+ 2785 ^ ^ | 2786 | ^ | 2787 --------------- -------- 2788 er_MAFailure[8] rx_Hello[3] 2789 (from all states) 2791 Figure 8: Messaging Association State Machine 2793 The processing rules are as follows: 2795 Rule 1: 2797 pass message to transport layer 2798 (re)start NoActivity timer 2799 (re)start SendHello 2801 Rule 2: 2803 pass message to N-SM 2804 (re)start NoActivity timer 2805 Rule 3: 2807 if reply requested 2808 send MA-Hello 2809 restart NoHello timer 2811 Rule 4: 2813 send MA-Hello message 2814 restart NoHello timer 2816 Rule 5: queue message for later transmission 2818 Rule 6: 2820 pass outstanding queued messages to transport layer 2821 stop any timers controlling connection establishment 2822 start NoActivity timer 2823 start SendHello timer 2825 Rule 7: 2827 stop NoActivity timer 2828 stop sendHello timer 2829 start NoHello timer 2831 Rule 8: destroy self 2833 7. Advanced Protocol Features 2835 7.1. Route Changes and Local Repair 2837 7.1.1. Introduction 2839 When re-routing takes place in the network, GIST and signaling 2840 application state need to be updated for all flows whose paths have 2841 changed. The updates to signaling application state are usually 2842 signaling application dependent: for example, if the path 2843 characteristics have actually changed, simply moving state from the 2844 old to the new path is not sufficient. Therefore, GIST cannot carry 2845 out the complete path update processing. Its responsibilities are to 2846 detect the route change, update its local routing state consistently, 2847 and inform interested signaling applications at affected nodes. 2849 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 2850 x +--+ +--+ +--+ x Initial 2851 x .|C1|_.....|D1|_.....|E1| x Configuration 2852 x . +--+. .+--+. .+--+\. x 2853 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 2854 +-+ +-+ . .. .. . +-+ 2855 ...|A|.......|B|/ .. .. .|F|_.... 2856 +-+ +-+ . . . . . . +-+ 2857 . . . . . . 2858 . +--+ +--+ +--+ . 2859 .|C2|_.....|D2|_.....|E2|/ 2860 +--+ +--+ +--+ 2862 +--+ +--+ +--+ Configuration 2863 .|C1|......|D1|......|E1| after failure 2864 . +--+ .+--+ +--+ of D1-E link 2865 . \. . \. ./ 2866 +-+ +-+. .. .. +-+ 2867 ...|A|.......|B|. .. .. .|F|_.... 2868 +-+ +-+\ . . . . . +-+ 2869 >>xxxxxxxxxxxxx . . . . . . xxxxxx>> 2870 x . +--+ +--+ +--+ . x 2871 x .|C2|_.....|D2|......|E2|/ x 2872 x +--+ +--+ +--+ x 2873 xxxxxxxxxxxxxxxxxxxxxxxxxxxx 2875 ........... = physical link topology 2876 >>xxxxxxx>> = flow direction 2877 _.......... = outgoing link for flow xxxxxx given 2878 by local forwarding table 2880 Figure 9: A Re-Routing Event 2881 Route change management is complicated by the distributed nature of 2882 the problem. Consider the re-routing event shown in Figure 9. An 2883 external observer can tell that the main responsibility for 2884 controlling the updates will probably lie with nodes B and F; 2885 however, E1 is best placed to detect the event quickly at the GIST 2886 level, and C1 and D1 could also attempt to initiate the repair. 2888 On the assumption that NSLPs are soft-state based and operate end to 2889 end, and because GIST also periodically updates its picture of 2890 routing state, route changes will eventually be repaired 2891 automatically. The specification as already given includes this 2892 functionality. However, especially if NSLP refresh times are 2893 extended to reduce signaling load, the duration of inconsistent state 2894 may be very long indeed. Therefore, GIST includes logic to exchange 2895 prompt notifications with NSLPs, to allow local repair if possible. 2896 The additional mechanisms to achieve this are described in the 2897 following subsections. To a large extent, these additions can be 2898 seen as implementation issues; the protocol messages and their 2899 significance are not changed, but there are extra interactions 2900 through the API between GIST and signaling applications, and 2901 additional triggers for transitions between the various GIST states. 2903 7.1.2. Route Change Detection Mechanisms 2905 There are two aspects to detecting a route change at a single node: 2907 o Detecting that the outgoing path, in the direction of the Query, 2908 has (or may have) changed. 2910 o Detecting that the incoming path, in the direction of the 2911 Response, has (or may have) changed (in which case the node may no 2912 longer be on the path at all). 2914 At a single node, these processes are largely independent, although 2915 clearly a change in one direction at a node corresponds to a change 2916 the opposite direction at its peer. Note that there are two possible 2917 forms for a route change: the interface through which a flow leaves 2918 or enters a node may change, and the adjacent peer may change. In 2919 general, a route change can include one or the other or both (or 2920 indeed neither, although such changes are very hard to detect). 2922 The route change detection mechanisms available to a node depend on 2923 the MRM in use and the role the node played in setting up the routing 2924 state in the first place (i.e. as Querying or Responding node). The 2925 following discussion is specific to the case of the path-coupled MRM 2926 using downstream Queries only; other scenarios may require other 2927 methods. However, the repair logic described in the subsequent 2928 subsections is intended to be universal. 2930 There are five mechanisms for a node to detect that a route change 2931 has occurred, which are listed below. They apply differently 2932 depending on whether the change is in the Query or Response 2933 direction, and these differences are summarised in the following 2934 table. 2936 Local Trigger: In trigger mode, GIST finds out from the local 2937 forwarding table that the next hop has changed. This only works 2938 if the routing change is local, not if it happens a few routing 2939 hops away (including the case that it happens at a GIST-unaware 2940 node). 2942 Extended Trigger: Here, GIST checks a link-state topology database to 2943 discover that the path has changed. This makes certain 2944 assumptions on consistency of route computation and only works 2945 within a single area for OSPF and similar link-state protocols. 2946 Where available, this offers the most accurate and rapid 2947 indication of route changes, but requires more access to the 2948 routing internals than a typical OS may provide. 2950 GIST C-mode Monitoring: GIST may find that C-mode packets are 2951 arriving (from either peer) with a different TTL or on a different 2952 interface. This provides no direct information about the new flow 2953 path, but indicates that routing has changed and that rediscovery 2954 may be required. 2956 Data Plane Monitoring: The signaling application on a node may detect 2957 a change in behaviour of the flow, such as TTL change, arrival on 2958 a different interface, or loss of the flow altogether. The 2959 signaling application on the node is allowed to notify this 2960 information locally to GIST (Appendix B.6). 2962 GIST Probing: According to the specification, each GIST node MUST 2963 periodically repeat the discovery (GIST-Query/GIST-Response) 2964 operation. The querying node will discover the route change by a 2965 modification in the Network-Layer-Information in the GIST- 2966 Response. The period can be negotiated independently for each 2967 GIST hop, so nodes that have access to the other techniques listed 2968 above MAY use long periods for the probing operation. 2970 +------------+--------------------------+---------------------------+ 2971 | Method | Query direction | Response direction | 2972 +------------+--------------------------+---------------------------+ 2973 | Local | Discovers new interface | Not applicable | 2974 | Trigger | (and peer if local) | | 2975 | | | | 2976 | Extended | Discovers new interface | May determine that route | 2977 | Trigger | and may determine new | from peer will have | 2978 | | peer | changed | 2979 | | | | 2980 | C-Mode | Provides hint that | Provides hint that change | 2981 | Monitoring | change has occurred | has occurred | 2982 | | | | 2983 | Data Plane | Not applicable | NSLP informs GIST that a | 2984 | Monitoring | | change may have occurred | 2985 | | | | 2986 | Probing | Discovers changed NLI in | Discovers changed NLI in | 2987 | | GIST-Response | GIST-Query | 2988 +------------+--------------------------+---------------------------+ 2990 7.1.3. GIST Behaviour Supporting Re-Routing 2992 The GIST behaviour necessary to support re-routing can be modelled 2993 using a 3-level classification of the validity of each item of 2994 routing state. (This classification applies separately to the 2995 Querying and Responding node for each pair of GIST peers.) The 2996 levels are: 2998 Bad: The routing state is either missing altogether, or not safe to 2999 use to send data. 3001 Tentative: The routing state may have changed, but it is still usable 3002 for sending NSLP data pending verification. 3004 Good: The routing state has been established and no events affecting 3005 it have since been detected. 3007 These classifications are not identical to the states described in 3008 Section 6, but there are dependencies between them. Specifically, 3009 routing state is considered Bad until the machine first enters the 3010 Established state, at which point it becomes Good. Thereafter, the 3011 status may be invalidated for any of the reasons discussed above; it 3012 is an implementation issue to decide which techniques to implement in 3013 any given node, and how to reclassify routing state (as Bad or 3014 Tentative) for each. The status returns to Good, either when the 3015 state machine re-enters the Established state, or if GIST can 3016 determine from direct examination of the routing or forwarding tables 3017 that the peer has not changed. When the status returns to Good, GIST 3018 MUST if necessary update its routing state table so that the 3019 relationships between MRI/SID/NSLPID tuples and messaging 3020 associations are up to date. 3022 When classification of the routing state for the downstream direction 3023 changes to Bad/Tentative because of local routing indications, GIST 3024 MAY automatically change the classification in the upstream direction 3025 to Tentative unless local routing indicates that this is not 3026 necessary. This SHOULD NOT be done in the case where the initial 3027 change was indicated by the NSLP. This mechanism accounts for the 3028 fact that a routing change may affect several nodes, and so can be an 3029 indication that upstream routing may also have changed. In any case, 3030 whenever GIST updates the routing status, it informs the NSLPs with 3031 the NetworkNotification API (Appendix B.4), unless the change was 3032 caused via the API in the first place. 3034 The GIST behaviour for state repair is different for the Querying and 3035 Responding node. At the Responding node, there is no additional 3036 behaviour, since the Responding node cannot initiate protocol 3037 transitions autonomously, it can only react to the Querying node. 3038 The Querying node has three options, depending on how the transition 3039 from 'Good' was initially caused: 3041 1. To inspect the routing/forwarding table and verifying that the 3042 next peer has not changed. This technique MUST NOT be used if 3043 the transition was caused by an NSLP, but SHOULD be used 3044 otherwise if available. 3046 2. To move to the 'Awaiting Refresh' state. This technique MUST NOT 3047 be used if the current status is 'Bad', since data is being 3048 incorrectly delivered. 3050 3. To move to the 'Awaiting Response' state. This technique may be 3051 used at any time, but has the effect of freezing NSLP 3052 communication while GIST state is being repaired. 3054 The second and third techniques trigger the execution of a GIST 3055 handshake to carry out the repair. It may be desirable to delay the 3056 start of the handshake process, either to wait for the network to 3057 stabilise, to avoid flooding the network with Query traffic for a 3058 large number of affected flows, or to wait for confirmation that the 3059 node is still on the path from the upstream peer. One approach is to 3060 delay the handshake until there is NSLP data to be transmitted. 3061 Implementation of such delays is a matter of local policy; however, 3062 GIST MUST begin the handshake immediately if the status change was 3063 caused by an InvalidateRoutingState API call is marked as 'Urgent', 3064 and SHOULD begin it if the upstream routing state is still known to 3065 be Good. 3067 7.1.4. Signaling Application Operation 3069 Signaling applications can use these functions as provided by GIST to 3070 carry out rapid local repair following re-routing events. The 3071 signaling application instances carry out the multi-hop aspects of 3072 the procedure, including crossover node detection, and tear down/ 3073 reinstall signaling application state; they also trigger GIST to 3074 carry out the local routing state maintenance operations over each 3075 individual hop. The local repair procedures depend heavily on the 3076 fact that stateful NSLP nodes are a single GIST hop apart; this is 3077 enforced by the details of the GIST peer-discovery process. 3079 The following outline description of a possible set of NSLP actions 3080 takes the scenario of Figure 9 as an example. 3082 1. The NSLP at node E1 is notified by GIST of route changes 3083 affecting the downstream and upstream directions. The downstream 3084 status was updated to Bad because of a trigger from the local 3085 forwarding tables, and the upstream status changed automatically 3086 to Tentative as a consequence. The NSLP at E1 MAY begin local 3087 repair immediately, or MAY propagate a notification upstream to 3088 D1 that re-routing has occurred. 3090 2. The NSLP at node D1 is notified of the route change, either by 3091 NSLP level notifications or from the GIST level (e.g. by a 3092 trigger from a link-state topology database). If the information 3093 propagates faster within the routing protocol, GIST will change 3094 the upstream/downstream routing state to Tentative/Bad 3095 automatically, and this will cause the NSLP to propagate the 3096 notification further upstream. 3098 3. This process continues until the notification reaches node A. 3099 Here, there is no downstream routing change, so GIST only learns 3100 of the update via the NSLP trigger. Since the upstream status is 3101 still Good, it therefore begins the repair handshake immediately. 3103 4. The handshake initiated by node A causes its downstream routing 3104 state to be confirmed as Good and unchanged there; it also 3105 confirms the (Tentative) upstream routing state at B as Good. 3106 This is enough to identify B as the crossover router, and the 3107 NSLP and GIST can begin the local repair process. 3109 An alternative way to reach step (4) is that node B is able to 3110 determine autonomously that there is no likelihood of an upstream 3111 route change (e.g. it is an area border router and the route change 3112 is only intra-area). In this case, the NSLP and GIST will see that 3113 the upstream state is Good and can begin the local repair directly. 3115 After a route change, a signaling application may wish to remove 3116 state at another node which is no longer on the path. However, since 3117 it is no longer on the path, in principle GIST can no longer send 3118 messages to it. (In general, provided this state is soft, it will 3119 time out anyway; however, the timeouts involved may have been set to 3120 be very long to reduce signaling load.) The requirement to remove 3121 state in a specific peer node is identified in [29]. 3123 This requirement can be met provided that GIST is able to use the old 3124 path to the signaling application peer for some period while the NSLP 3125 still needs it. Since NSLP peers are a single GIST hop apart, the 3126 necessary information is just the old entry in the node's routing 3127 state table for that flow. Rather than requiring the GIST level to 3128 maintain multiple generations of this information, it can just be 3129 provided to the signaling application in the same node (in an opaque 3130 form), which can store it if necessary and provide it back to the 3131 GIST layer in case it needs to be used. This information is denoted 3132 as 'SII-Handle' in the abstract API of Appendix B. Messages sent 3133 this way MUST bypass the GIST routing state tables at the sender, and 3134 this is indicated by setting the E flag in the common header 3135 (Appendix A.1); at the receiver, GIST MUST NOT validate the MRI/SID/ 3136 NSLPID against local routing state and instead indicates the mode of 3137 reception to signaling applications through the API (Appendix B.2). 3138 Signaling applications should validate the source and effect of the 3139 message themselves. 3141 7.2. NAT Traversal 3143 GIST messages must carry packet addressing and higher layer 3144 information as payload data in order to define the flow signalled 3145 for. (This applies to all GIST messages, regardless of how they are 3146 encapsulated or which direction they are travelling in.) At an 3147 addressing boundary the data flow packets will have their headers 3148 translated; if the signaling payloads are not translated 3149 consistently, the signaling messages will refer to incorrect (and 3150 probably meaningless) flows after passing through the boundary. In 3151 addition, GIST handshake messages carry additional addressing 3152 information about the GIST nodes themselves, and this must also be 3153 processed appropriately when traversing a NAT. 3155 The simplest solution to this problem is to require that a NAT is 3156 GIST-aware, and to allow it to modify messages based on the contents 3157 of the MRI. (This is makes the assumption that NATs only rewrite the 3158 header fields included in this payload, and not other higher layer 3159 identifiers.) Provided this is done consistently with the data flow 3160 header translation, signaling messages will be valid each side of the 3161 boundary, without requiring the NAT to be signaling application 3162 aware. (Note, however, that if the NAT does not understand the MRI, 3163 it should reject the message with an appropriate error.) 3165 This specification defines an additional object that a NAT can insert 3166 into Query-encapsulated messages and which is echoed back in any 3167 responses to those messages. The new object, the NAT-Traversal 3168 object (Appendix A.3.8), carries the translation between the 'public' 3169 and 'private' MRI. It also carries a list of which other objects in 3170 the message have been translated. This should always include the 3171 NLI, and the Stack-Configuration-Data (if present); if GIST is 3172 extended with further objects that carry addressing data, this list 3173 allows a message receiver to know if the new objects were supported 3174 by the NAT. Finally, the NAT-Traversal object MAY be used to carry 3175 data to be used in back-translating datagram mode responses; this 3176 could be the original NLI or SCD, or opaque equivalents in the case 3177 of topology hiding. 3179 A consequence of this approach is that the routing state tables at 3180 the signaling application peers (each side of the NAT) are no longer 3181 directly compatible. In particular, the values for Message-Routing- 3182 Information are different, which is why the unmodified MRI is 3183 propagated in the NAT-Traversal payload to allow subsequent C-mode 3184 messages to be interpreted correctly. 3186 This specification does not define normative behaviour for a NAT 3187 translating GIST messages, since much of this will depend on NAT 3188 policy about allocating bindings; the description is purely 3189 informative. However, it does define the behaviour of a GIST node 3190 receiving a message containing a NAT-Traversal object. 3192 A possible set of operations for a NAT to process a Query- 3193 encapsulated message is as follows: 3195 1. Verify that bindings for the data flow are actually in place. 3197 2. Create a new Message-Routing-Information object with fields 3198 modified according to the data flow bindings. 3200 3. Create bindings for subsequent C-mode signaling (based on the 3201 information in the Network-Layer-Information and Stack- 3202 Configuration-Data objects). 3204 4. Create new Network-Layer-Information and if necessary Stack- 3205 Configuration-Data objects with fields to force D-mode response 3206 messages through the NAT, and to allow C-mode exchanges using the 3207 C-mode signaling bindings. 3209 5. Add a NAT-Traversal payload, listing the objects which have been 3210 modified and including the unmodified MRI and any other data 3211 needed to interpret the response. (If a NAT-Traversal object is 3212 already present, in the case of a sequence of NATs, the list of 3213 modified objects may be updated and further opaque data added, 3214 but the MRI contained in it is left unchanged.) 3216 6. Encapsulate the message according to the normal rules of this 3217 specification for the Query-encapsulation. If the S-flag was set 3218 in the original message, the same IP source address selection 3219 policy should be applied to the forwarded message. 3221 7. Forward the message with these new payloads. 3223 A GIST node receiving such a message MUST verify that all mandatory 3224 objects containing addressing have been translated correctly, or else 3225 reject the message with a 'Object Type Error' message 3226 (Appendix A.4.4.9) with subcode 4 ('Untranslated Object'). The error 3227 message MUST include the NAT-Traversal object as the first TLV after 3228 the common header (this is true for any other error message generated 3229 as a response). Otherwise, the message is processed essentially as 3230 normal. If no state needs to be updated for the message, the NAT- 3231 Traversal object can be effectively ignored. The other possibility 3232 is that a Response must be returned, either because the message is 3233 the beginning of a handshake for a new flow, or it is a refresh for 3234 existing state. In both cases, the GIST node MUST create the 3235 Response message in the normal way using the 'local' form of the MRI, 3236 and its own NLI and (if necessary) SCD. It MUST also include the 3237 NAT-Traversal object as the first object in the Response after the 3238 common header. 3240 A NAT will intercept datagram mode messages with the normal 3241 encapsulation containing such echoed NAT-Traversal objects. (All 3242 other GIST messages, either in connection mode, or datagram mode 3243 messages with no NAT-Traversal object, should be treated as 'normal' 3244 data traffic by the NAT, i.e. with IP and transport layer translation 3245 but no GIST-specific processing.) The NAT processing is a subset of 3246 the processing for the Query-encapsulated case: 3248 1. Verify the existence of bindings for the data flow. 3250 2. Leave the Message-Routing-Information object unchanged. 3252 3. Modify the NLI and SCD objects for the Responding node if 3253 necessary, and create or update any bindings for C-mode signaling 3254 traffic. 3256 4. Forward the message. 3258 A GIST node receiving such a message MUST use the MRI from the NAT- 3259 Traversal object as the key to index its internal routing state; it 3260 MAY also store the 'translated' MRI for additional (e.g. diagnostic) 3261 information, but this is not used in the GIST processing. The 3262 remainder of GIST processing is unchanged. 3264 Note that Confirm messages are not translated. Thus, a Responding 3265 node has available only the untranslated MRI describing the flow, and 3266 the untranslated NLI as peer routing state. This would prevent the 3267 correct interpretation of the signaling messages; also, subsequent 3268 Query (refresh) messages would always be seen as route changes 3269 because of the NLI change. Therefore, a Responding node that wishes 3270 to delay state installation until receiving a Confirm must somehow 3271 reconstruct the translations when the Confirm arrives. How to do 3272 this is an implementation issue; one approach is to carry the 3273 translated objects as part of the Responder cookie which is echoed in 3274 the Confirm. (Indeed, for one of the cookie constructions in 3275 Section 8.5 this is automatic.) 3277 7.3. Interaction with IP Tunnelling 3279 The interaction between GIST and IP tunnelling is very simple. An IP 3280 packet carrying a GIST message is treated exactly the same as any 3281 other packet with the same source and destination addresses: in other 3282 words, it is given the tunnel encapsulation and forwarded with the 3283 other data packets. 3285 Tunnelled packets will not be identifiable as GIST messages until 3286 they leave the tunnel, since any router alert option and the standard 3287 GIST protocol encapsulation (e.g. port numbers) will be hidden within 3288 the standard tunnel encapsulation. If signaling is needed for the 3289 tunnel itself, this has to be initiated as a separate signaling 3290 session by one of the tunnel endpoints - that is, the tunnel counts 3291 as a new flow. Because the relationship between signaling for the 3292 'microflow' and signaling for the tunnel as a whole will depend on 3293 the signaling application in question, it is a signaling application 3294 responsibility to be aware of the fact that tunnelling is taking 3295 place and to carry out additional signaling if necessary; in other 3296 words, at least one tunnel endpoint must be signaling application 3297 aware. 3299 In some cases, it is the tunnel exit point (i.e. the node where 3300 tunnelled data and downstream signaling packets leave the tunnel) 3301 that will wish to carry out the tunnel signaling, but this node will 3302 not have knowledge or control of how the tunnel entry point is 3303 carrying out the data flow encapsulation. The information about how 3304 the inner MRI/SID relate to the tunnel MRI/SID needs to be carried in 3305 the signaling data from the tunnel entry point (this functionality is 3306 the equivalent to the RSVP SESSION_ASSOC object of [12]). In the 3307 NSIS protocol suite, these bindings are managed by the signaling 3308 applications, either implicitly (e.g. by SID re-use) or explicitly 3309 (by carrying objects that bind the inner and outer SIDs as part of 3310 the NSLP payload). 3312 7.4. IPv4-IPv6 Transition and Interworking 3314 GIST itself is essentially IP version neutral: version dependencies 3315 are isolated in the formats of the Message-Routing-Information, 3316 Network-Layer-Information and Stack-Configuration-Data objects, and 3317 GIST also depends on the version independence of the protocols that 3318 support messaging associations. In mixed environments, GIST 3319 operation will be influenced by the IP transition mechanisms in use. 3320 This section provides a high level overview of how GIST is affected, 3321 considering only the currently predominant mechanisms. 3323 Dual Stack: (As described in [30].) In mixed environments, GIST MUST 3324 use the same IP version as the flow it is signaling for Query- 3325 encapsulated messages and SHOULD do so for other signaling also 3326 (see Section 5.2.2). The IP version used in datagram mode is 3327 closely tied to the IP version used by the data flow, so it is 3328 intrinsically impossible for a IPv4-only or IPv6-only GIST node to 3329 support signaling for flows using the other IP version. Hosts 3330 which are dual stack for applications and routers which are dual 3331 stack for forwarding need GIST implementations which can support 3332 both IP versions. Applications with a choice of IP versions might 3333 select a version based on which could be supported in the network 3334 by GIST, which could be established by invoking parallel discovery 3335 procedures. 3337 Packet Translation: (Applicable to SIIT [6] and NAT-PT [13].) Some 3338 transition mechanisms allow IPv4 and IPv6 nodes to communicate by 3339 placing packet translators between them. From the GIST 3340 perspective, this should be treated essentially the same way as 3341 any other NAT operation (e.g. between 'public' and 'private' 3342 addresses) as described in Section 7.2. The translating node 3343 needs to be GIST-aware; it will have to translate the addressing 3344 payloads between IPv4 and IPv6 formats for flows which cross 3345 between the two. The translation rules for the fields in the MRI 3346 payload (including e.g. DiffServ-codepoint and flow-label) are as 3347 defined in [6]. 3349 Tunnelling: (Applicable to 6to4 [15].) Many transition mechanisms 3350 handle the problem of how an end to end IPv6 (or IPv4) flow can be 3351 carried over intermediate IPv4 (or IPv6) regions by tunnelling; 3352 the methods tend to focus on minimising the tunnel administration 3353 overhead. 3355 From the GIST perspective, the treatment should be as similar as 3356 possible to any other IP tunnelling mechanism, as described in 3357 Section 7.3. In particular, the end to end flow signaling will 3358 pass transparently through the tunnel, and signaling for the 3359 tunnel itself will have to be managed by the tunnel endpoints. 3360 However, additional considerations may arise because of special 3361 features of the tunnel management procedures. In particular, [16] 3362 is based on using an anycast address as the destination tunnel 3363 endpoint. GIST MAY use anycast destination addresses in the 3364 Query-encapsulation of D-mode messages if necessary, but MUST NOT 3365 use them in the Network-Layer-Information addressing field; normal 3366 unicast addresses MUST be used instead. Note that the addresses 3367 from the IP header are not used by GIST in matching requests and 3368 responses, so there is no requirement to use anycast source 3369 addresses. 3371 8. Security Considerations 3373 The security requirement for GIST is to protect the signaling plane 3374 against identified security threats. For the signaling problem as a 3375 whole, these threats have been outlined in [25]; the NSIS framework 3376 [24] assigns a subset of the responsibilities to the NTLP. The main 3377 issues to be handled can be summarised as: 3379 Message Protection: Signaling message content can be protected 3380 against eavesdropping, modification, injection and replay while in 3381 transit. This applies both to GIST payloads, and GIST should also 3382 provide such protection as a service to signaling applications 3383 between adjacent peers. 3385 Routing State Integrity Protection: It is important that signaling 3386 messages are delivered to the correct nodes, and nowhere else. 3387 Here, 'correct' is defined as 'the appropriate nodes for the 3388 signaling given the Message-Routing-Information'. In the case 3389 where the MRI is based on the Flow Identification for path-coupled 3390 signaling, 'appropriate' means 'the same nodes that the 3391 infrastructure will route data flow packets through'. (GIST has 3392 no role in deciding whether the data flow itself is being routed 3393 correctly; all it can do is ensure the signaling is routed 3394 consistently with it.) GIST uses internal state to decide how to 3395 route signaling messages, and this state needs to be protected 3396 against corruption. 3398 Prevention of Denial of Service Attacks: GIST nodes and the network 3399 have finite resources (state storage, processing power, 3400 bandwidth). The protocol tries to minimise exhaustion attacks 3401 against these resources and not allow GIST nodes to be used to 3402 launch attacks on other network elements. 3404 The main additional issue is handling authorisation for executing 3405 signaling operations (e.g. allocating resources). This is assumed to 3406 be done in each signaling application. 3408 In many cases, GIST relies on the security mechanisms available in 3409 messaging associations to handle these issues, rather than 3410 introducing new security measures. Obviously, this requires the 3411 interaction of these mechanisms with the rest of the GIST protocol to 3412 be understood and verified, and some aspects of this are discussed in 3413 Section 5.7. 3415 8.1. Message Confidentiality and Integrity 3417 GIST can use messaging association functionality, specifically in 3418 this version TLS (Section 5.7.3), to ensure message confidentiality 3419 and integrity. Implementation of this functionality is REQUIRED but 3420 its use for any given flow or signaling application is OPTIONAL. In 3421 some cases, confidentiality of GIST information itself is not likely 3422 to be a prime concern, in particular since messages are often sent to 3423 parties which are unknown ahead of time, although the content visible 3424 even at the GIST level gives significant opportunities for traffic 3425 analysis. Signaling applications may have their own mechanism for 3426 securing content as necessary; however, they may find it convenient 3427 to rely on protection provided by messaging associations, since it 3428 runs unbroken between signaling application peers. 3430 8.2. Peer Node Authentication 3432 Cryptographic protection (of confidentiality or integrity) requires a 3433 security association with session keys. These can be established by 3434 an authentication and key exchange protocol based on shared secrets, 3435 public key techniques or a combination of both. Authentication and 3436 key agreement is possible using the protocols associated with the 3437 messaging association being secured (TLS incorporates this 3438 functionality directly; IKE, IKEv2 or KINK could provide it for 3439 IPsec). GIST nodes rely on these protocols to authenticate the 3440 identity of the next hop, and GIST has no authentication capability 3441 of its own. 3443 With routing state discovery, there are few effective ways to know 3444 what is the legitimate next or previous hop as opposed to an 3445 impostor. In other words, cryptographic authentication here only 3446 provides assurance that a node is 'who' it is (i.e. the legitimate 3447 owner of identity in some namespace), not 'what' it is (i.e. a node 3448 which is genuinely on the flow path and therefore can carry out 3449 signaling for a particular flow). Authentication provides only 3450 limited protection, in that a known peer is unlikely to lie about its 3451 role. Additional methods of protection against this type of attack 3452 are considered in Section 8.3 below. 3454 It is an implementation issue whether peer node authentication should 3455 be made signaling application dependent; for example, whether 3456 successful authentication could be made dependent on presenting 3457 credentials related to a particular signaling role (e.g. "signaling 3458 for QoS"). The abstract API of Appendix B leaves open such policy 3459 and authentication interactions between GIST and the NSLP it is 3460 serving. However, it does allow applications to inspect the 3461 authenticated identity of the peer to which a message will be sent 3462 before transmission. 3464 8.3. Routing State Integrity 3466 Internal state in a node (see Section 4.2) is used to route messages. 3468 If this state is corrupted, signaling messages may be misdirected. 3470 In the case where the message routing method is path-coupled, the 3471 messages need to be routed identically to the data flow described by 3472 the MRI, and the routing state table is the GIST view of how these 3473 flows are being routed through the network in the immediate 3474 neighbourhood of the node. Routes are only weakly secured (e.g. 3475 there is no cryptographic binding of a flow to a route), and there is 3476 no authoritative information about flow routes other than the current 3477 state of the network itself. Therefore, consistency between GIST and 3478 network routing state has to be ensured by directly interacting with 3479 the routing mechanisms to ensure that the signaling peers are the 3480 appropriate ones for any given flow. An overview of security issues 3481 and techniques in this context is provided in [34]. 3483 In one direction, peer identification is installed and refreshed only 3484 on receiving a GIST-Reponse message (compare Figure 4). This MUST 3485 echo the cookie from a previous GIST-Query message, which will have 3486 been sent along the flow path (in datagram mode, i.e. end-to-end 3487 addressed). Hence, only the true next peer or an on-path attacker 3488 will be able to generate such a message, provided freshness of the 3489 cookie can be checked at the querying node. 3491 In the other direction, peer identification MAY be installed directly 3492 on receiving a GIST-Query message containing addressing information 3493 for the signaling source. However, any node in the network could 3494 generate such a message (indeed, many nodes in the network could be 3495 the genuine upstream peer for a given flow). To protect against 3496 this, three strategies are used: 3498 Filtering: the receiving node MAY reject signaling messages which 3499 claim to be for flows with flow source addresses which could be 3500 ruled out by ingress filtering. An extension of this technique 3501 would be for the receiving node to monitor the data plane and to 3502 check explicitly that the flow packets are arriving over the same 3503 interface and if possible from the same link layer neighbour as 3504 the datagram mode signaling packets. (If they are not, it is 3505 likely that at least one of the signaling or flow packets is being 3506 spoofed.) Signaling applications SHOULD only install state on the 3507 route taken by the data itself. 3509 Authentication (weak or strong): the receiving node MAY refuse to 3510 install upstream state until it has completed a GIST-Confirm 3511 handshake with the peer. This echoes the Response cookie of the 3512 GIST-Response, and discourages nodes from using forged source 3513 addresses. This also plays a role in denial of service 3514 prevention, see below. A stronger approach is to require full 3515 peer authentication within the messaging association, the 3516 reasoning being that an authenticated peer can be trusted not to 3517 pretend that it is on path when it is not. 3519 SID segregation: The routing state lookup for a given MRI and NSLPID 3520 MUST also take the SID into account. A malicious node can only 3521 overwrite existing routing state if it can guess the corresponding 3522 SID; it can insert state with random SID values, but generally 3523 this will not be used to route messages for which state has 3524 already been legitimately established. 3526 8.4. Denial of Service Prevention 3528 GIST is designed so that in general each Query message only generates 3529 at most one Response, so that a GIST node cannot become the source of 3530 a denial of service amplification attack. (There is a special case 3531 of retransmitted Response messages, see Section 5.3.3.) 3533 However, GIST can still be subjected to denial-of-service attacks 3534 where an attacker using forged source addresses forces a node to 3535 establish state without return routability, causing a problem similar 3536 to TCP SYN flood attacks. Furthermore, an adversary might use 3537 modified or replayed unprotected signaling messages as part of such 3538 an attack. There are two types of state attacks and one 3539 computational resource attack. In the first state attack, an 3540 attacker floods a node with messages that the node has to store until 3541 it can determine the next hop. If the destination address is chosen 3542 so that there is no GIST-capable next hop, the node would accumulate 3543 messages for several seconds until the discovery retransmission 3544 attempt times out. The second type of state-based attack causes GIST 3545 state to be established by bogus messages. A related computational/ 3546 network-resource attack uses unverified messages to cause a node to 3547 make AAA queries or attempt to cryptographically verify a digital 3548 signature. 3550 We use a combination of two defences against these attacks: 3552 1. The responding node need not establish a session or discover its 3553 next hop on receiving the GIST-Query message, but MAY wait for a 3554 GIST-Confirm message, possibly on a secure channel. If the 3555 channel exists, the additional delay is one one-way delay and the 3556 total is no more than the minimal theoretically possible delay of 3557 a three-way handshake, i.e., 1.5 node-to-node round-trip times. 3558 The delay gets significantly larger if a new connection needs to 3559 be established first. 3561 2. The Response to the Query message contains a cookie, which is 3562 repeated in the Confirm. State is only established for messages 3563 that contain a valid cookie. The setup delay is also 1.5 round- 3564 trip times. (This mechanism is similar to that in SCTP [14] and 3565 other modern protocols.) 3567 Once a node has decided to establish routing state, there may still 3568 be transport and security state to be established between peers. 3569 This state setup is also vulnerable to denial of service attacks. 3570 GIST relies on the lower layer protocols that make up messaging 3571 associations to mitigate such attacks. In the current specification, 3572 the querying node is always the one wishing to establish a messaging 3573 association, so it is the responding node that needs to be protected. 3575 8.5. Requirements on Cookie Mechanisms 3577 The requirements on the Query cookie can be summarised as follows: 3579 Liveness: The cookie must be live (must change from one handshake to 3580 the next). To prevent replay attacks. 3582 Unpredictability: The cookie must not be guessable (e.g. not from a 3583 sequence or timestamp). To prevent direct forgery based on seeing 3584 a history of captured messages. 3586 Easily validated: It must be efficient for the Q-Node to validate 3587 that a particular cookie matches an in-progress handshake, for a 3588 routing state machine which already exists. To discard spoofed 3589 responses, or responses to spoofed queries. 3591 Uniqueness: The cookie must be unique to a given handshake (since it 3592 is actually used to match the Response to a handshake anyway, e.g. 3593 during messaging association re-use). 3595 Likewise, the requirements on the Responder cookie can be summarised 3596 as follows: 3598 Liveness: The cookie must be live (must change from one handshake to 3599 the next). To prevent replay attacks. 3601 Creation simplicity: The cookie must be lightweight to generate. To 3602 avoid resource exhaustion at the responding node. 3604 Validation simplicity: It must be simple for the R-node to validate 3605 that an R-cookie was generated by itself (and no-one else), 3606 without storing state about the handshake it was generated for. 3608 Binding: The cookie must be bound to the routing state that will be 3609 installed. To prevent use with different routing state e.g. in a 3610 modified Confirm. The routing state here includes: 3612 The NLI of the Query 3614 The MRI/NSLPID for the messaging 3616 The interface on which the Query was received 3618 A suitable implementation for the Q-Cookie is a cryptographically 3619 random number which is unique for this routing state machine 3620 handshake. A node SHOULD implement this or an equivalently strong 3621 mechanism. 3623 A suitable implementation for the R-Cookie is as follows: 3625 R-Cookie = liveness data + hash (locally known secret, 3626 Q-Node NLI, MRI, NSLPID, 3627 reception interface, 3628 liveness data) 3630 A node SHOULD implement this or an equivalently strong mechanism. 3631 There are several alternatives for the liveness data. One is to use 3632 a timestamp like SCTP. Another is to use a local secret with (rapid) 3633 rollover, with the liveness data as the generation number of the 3634 secret, like IKEv2. In both cases, the liveness data has to be 3635 carried outside the hash, to allow the hash to be verified at the 3636 Responder. Another approach is to replace the hash with encryption 3637 under a locally known secret, in which case the liveness data does 3638 not need to be carried in the clear. Any symmetric cipher immune to 3639 known plaintext attacks can be used. 3641 If a node recieves a message for which cookie validation fails, it 3642 MAY return an "Object Value Error" error message (Appendix A.4.4.10) 3643 with subcode 4 ("Invalid Cookie") to the sender, as well as dropping 3644 the message. However, doing so in general makes a node a source of 3645 backscatter. Therefore, this SHOULD only be enabled selectively, 3646 e.g. during initial deployment or debugging. 3648 8.6. Residual Threats 3650 Taking the above security mechanisms into account, the main residual 3651 threats against NSIS are three types of on-path attack. 3653 An on-path attacker who can intercept the initial Query can do most 3654 things it wants to the subsequent signaling. It is very hard to 3655 protect against this at the GIST level; the only defence is to use 3656 strong messaging association security to see whether the Responding 3657 node is authorised to take part in NSLP signaling exchanges. To some 3658 extent, this behaviour is logically indistinguishable from correct 3659 operation, so it is easy to see why defence is difficult. Note than 3660 an on-path attacker of this sort can do anything to the traffic as 3661 well as the signaling. Therefore, the additional threat induced by 3662 the signaling weakness seems tolerable. 3664 At the NSLP level, there is a concern about transitivity of trust of 3665 correctness of routing along the signaling chain. The NSLP at the 3666 querying node can have good assurance that it is communicating with 3667 an on-path peer (or a node delegated by the on-path node). However, 3668 it has no assurance that the node beyond the responder is also on- 3669 path, or that the MRI (in particular) is not being modified by the 3670 responder to refer to a different flow. Therefore, if it sends 3671 signaling messages with payloads (e.g. authorisation tokens) which 3672 are "valuable" to nodes beyond the adjacent hop, it is up to the NSLP 3673 to ensure that the appropriate chain of trust exists, which must in 3674 general use messaging association (strong) security. 3676 There is a further residual attack by a node which is not on the path 3677 of the flow, but is on the path of the Response, or is able to use a 3678 Response from one handshake to interfere with another. The attacker 3679 modifies the Response to cause the Querying node to form an adjacency 3680 with it rather than the true downstream node. In principle, this 3681 attack could be prevented by including an additional cryptographic 3682 object in the Response message which ties the Response to the initial 3683 Query and the routing state and can be verified by the Querying node. 3685 9. IANA Considerations 3687 This section defines the registries and initial codepoint assignments 3688 for GIST. It also defines the procedural requirements to be followed 3689 by IANA in allocating new codepoints. Guidelines on the technical 3690 criteria to be followed in evaluating requests for new codepoint 3691 assignments are given for the overall NSIS protocol suite in a 3692 separate NSIS extensibility document [36]. 3694 This specification allocates the following codepoints in existing 3695 registries: 3697 Well-known UDP port XXX as the destination port for Query- 3698 encapsulated GIST messages (Section 5.3). 3700 This specification creates the following registries with the 3701 structures as defined below: 3703 NSLP Identifiers: Each signaling application requires the assignment 3704 of one of more NSLPIDs. The following NSLPID is allocated by this 3705 specification: 3707 +---------+---------------------------------------------------------+ 3708 | NSLPID | Application | 3709 +---------+---------------------------------------------------------+ 3710 | 0 | Used for GIST messages not related to any signaling | 3711 | | application. | 3712 +---------+---------------------------------------------------------+ 3714 Every other NSLPID MUST be associated with a specific RAO value 3715 (multiple NSLPIDs MAY be associated with the same value). The 3716 NSLPID is a 16 bit integer, and allocation policies for further 3717 values are as follows: 3719 1-32703: IESG Approval 3721 32704-32767: Private/Experimental Use 3723 32768-65536: Reserved 3725 GIST Message Type: The GIST common header (Appendix A.1) contains a 1 3726 byte message type field. The following values are allocated by 3727 this specification: 3729 +---------+----------+ 3730 | MType | Message | 3731 +---------+----------+ 3732 | 0 | Query | 3733 | | | 3734 | 1 | Response | 3735 | | | 3736 | 2 | Confirm | 3737 | | | 3738 | 3 | Data | 3739 | | | 3740 | 4 | Error | 3741 | | | 3742 | 5 | MAHello | 3743 +---------+----------+ 3745 Allocation policies for further values are as follows: 3747 6-63: Standards Action 3749 64-119: Expert Review 3751 120-127: Private/Experimental Use 3753 128-255: Reserved 3755 Object Types: There is a 12-bit field in the object header 3756 (Appendix A.2). The following values for object type are defined 3757 by this specification: 3759 +---------+-----------------------------+ 3760 | OType | Object Type | 3761 +---------+-----------------------------+ 3762 | 0 | Message Routing Information | 3763 | | | 3764 | 1 | Session ID | 3765 | | | 3766 | 2 | Network Layer Information | 3767 | | | 3768 | 3 | Stack Proposal | 3769 | | | 3770 | 4 | Stack Configuration Data | 3771 | | | 3772 | 5 | Query Cookie | 3773 | | | 3774 | 6 | Responder Cookie | 3775 | | | 3776 | 7 | NAT Traversal | 3777 | | | 3778 | 8 | NSLP Data | 3779 | | | 3780 | 9 | Error | 3781 +---------+-----------------------------+ 3783 Allocation policies for further values are as follows: 3785 10-1023: Standards Action 3787 1024-1999: Specification Required 3789 2000-2047: Private/Experimental Use 3791 2048-4095: Reserved 3793 When a new object type is defined, the extensibility bits (A/B, 3794 see Appendix A.2.1) must also be defined. 3796 Message Routing Methods: GIST allows the idea of multiple message 3797 routing methods (see Section 3.3). The message routing method is 3798 indicated in the leading byte of the MRI object (Appendix A.3.1). 3799 This specification defines the following values: 3801 +---------+------------------------+ 3802 | MRM | Message Routing Method | 3803 +---------+------------------------+ 3804 | 0 | Path Coupled MRM | 3805 | | | 3806 | 1 | Loose End MRM | 3807 +---------+------------------------+ 3809 Allocation policies for further values are as follows: 3811 2-63: Standards Action 3813 64-119: Expert Review 3815 120-127: Private/Experimental Use 3817 128-255: Reserved 3819 When a new MRM is defined, the information described in 3820 Section 3.3 must be provided. 3822 MA-Protocol-IDs: Each upper layer protocol that can be used in a 3823 messaging association is identified by a 1-byte MA-Protocol-ID 3824 (Section 5.7). This is used as a tag in the Stack-Proposal and 3825 Stack-Configuration-Data objects (Appendix A.3.4 and 3826 Appendix A.3.5). The following values are defined by this 3827 specification: 3829 +---------------------+-----------------------------------------+ 3830 | MA-Protocol-ID | Higher Layer Protocol | 3831 +---------------------+-----------------------------------------+ 3832 | 1 | TCP opened in the forwards direction | 3833 | | | 3834 | 2 | TLS initiated in the forwards direction | 3835 +---------------------+-----------------------------------------+ 3837 Allocation policies for further values are as follows: 3839 3-63: Standards Action 3841 64-119: Expert Review 3843 120-127: Private/Experimental Use 3845 128-255: Reserved 3847 Allocating a new MA-Protocol-ID requires defining the higher layer 3848 addressing information (if any) in the Stack-Configuration-Data 3849 object that is needed to define its configuration. Note that the 3850 MA-Protocol-ID is not an IP Protocol number (indeed, some of the 3851 messaging association protocols - such as TLS - do not have an IP 3852 Protocol number). 3854 Error Codes/Subcodes: There is a 2 byte error code and 1 byte subcode 3855 in the Value field of the Error object (Appendix A.4.1). Error 3856 codes 1-12 are defined in Appendix A.4.4 together with subcodes 3857 0-3 for code 1, 0-4 for code 9 and 0-5 for code 10. Additional 3858 codes and subcodes are allocated on a first-come, first served 3859 basis. When a new error code/subcode combination is allocated, 3860 the Error Class and the format of any associated error-specific 3861 information must also be defined. 3863 10. Acknowledgements 3865 This document is based on the discussions within the IETF NSIS 3866 working group. It has been informed by prior work and formal and 3867 informal inputs from: Cedric Aoun, Attila Bader, Roland Bless, Bob 3868 Braden, Marcus Brunner, Benoit Campedel, Luis Cordeiro, Elwyn Davies, 3869 Christian Dickmann, Pasi Eronen, Xiaoming Fu, Ruediger Geib, Eleanor 3870 Hepworth, Cheng Hong, Cornelia Kappler, Georgios Karagiannis, Chris 3871 Lang, John Loughney, Allison Mankin, Jukka Manner, Pete McCann, 3872 Andrew McDonald, Glenn Morrow, Dave Oran, Andreas Pashaldis, Henning 3873 Peters, Tom Phelan, Takako Sanda, Charles Shen, Melinda Shore, Martin 3874 Stiemerling, Mike Thomas, Hannes Tschofenig, Sven van den Bosch, 3875 Michael Welzl, and Lars Westberg. In particular, Hannes Tschofenig 3876 provided a detailed set of review comments on the security section, 3877 and Andrew McDonald provided the formal description for the initial 3878 packet formats. Chris Lang's implementation work provided objective 3879 feedback on the clarity and feasibility of the specification, and he 3880 also provided the state machine description and the initial error 3881 catalogue and formats. We look forward to inputs and comments from 3882 many more in the future. 3884 11. References 3886 11.1. Normative References 3888 [1] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 3890 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3891 Levels", BCP 14, RFC 2119, March 1997. 3893 [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3894 Specifications: ABNF", RFC 2234, November 1997. 3896 [4] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 3897 the Differentiated Services Field (DS Field) in the IPv4 and 3898 IPv6 Headers", RFC 2474, December 1998. 3900 [5] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 3901 RFC 2711, October 1999. 3903 [6] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 3904 RFC 2765, February 2000. 3906 [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 3907 RFC 2246, January 1999. 3909 [8] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", 3910 draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005. 3912 11.2. Informative References 3914 [9] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 3915 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 3916 Specification", RFC 2205, September 1997. 3918 [10] Kent, S. and R. Atkinson, "Security Architecture for the 3919 Internet Protocol", RFC 2401, November 1998. 3921 [11] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 3922 RFC 2409, November 1998. 3924 [12] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP 3925 Operation Over IP Tunnels", RFC 2746, January 2000. 3927 [13] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 3928 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 3930 [14] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 3931 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 3933 Paxson, "Stream Control Transmission Protocol", RFC 2960, 3934 October 2000. 3936 [15] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 3937 IPv4 Clouds", RFC 3056, February 2001. 3939 [16] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 3940 RFC 3068, June 2001. 3942 [17] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 3943 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 3944 September 2001. 3946 [18] Grossman, D., "New Terminology and Clarifications for 3947 Diffserv", RFC 3260, April 2002. 3949 [19] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 3950 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 3951 Session Initiation Protocol", RFC 3261, June 2002. 3953 [20] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 3954 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 3955 RFC 3320, January 2003. 3957 [21] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 3958 Haukka, "Security Mechanism Agreement for the Session 3959 Initiation Protocol (SIP)", RFC 3329, January 2003. 3961 [22] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 3962 - Simple Traversal of User Datagram Protocol (UDP) Through 3963 Network Address Translators (NATs)", RFC 3489, March 2003. 3965 [23] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 3966 Security Mechanism (GTSM)", RFC 3682, February 2004. 3968 [24] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 3969 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 3970 June 2005. 3972 [25] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 3973 Steps in Signaling (NSIS)", RFC 4081, June 2005. 3975 [26] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 3976 draft-ietf-dccp-spec-11 (work in progress), March 2005. 3978 [27] Conta, A., "Internet Control Message Protocol (ICMPv6) for the 3979 Internet Protocol Version 6 (IPv6) Specification", 3980 draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005. 3982 [28] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 3983 (NSLP)", draft-ietf-nsis-nslp-natfw-07 (work in progress), 3984 July 2005. 3986 [29] Bosch, S., "NSLP for Quality-of-Service signalling", 3987 draft-ietf-nsis-qos-nslp-07 (work in progress), July 2005. 3989 [30] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 3990 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 (work in 3991 progress), March 2005. 3993 [31] Kent, S. and K. Seo, "Security Architecture for the Internet 3994 Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), 3995 April 2005. 3997 [32] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 3998 draft-ietf-secsh-architecture-22 (work in progress), 3999 March 2005. 4001 [33] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 4002 (work in progress), June 2005. 4004 [34] Nikander, P., "Mobile IP version 6 Route Optimization Security 4005 Design Background", draft-ietf-mip6-ro-sec-03 (work in 4006 progress), May 2005. 4008 [35] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4009 Security", draft-rescorla-dtls-05 (work in progress), 4010 June 2005. 4012 [36] Loughney, J., "NSIS Extensibility Model", 4013 draft-loughney-nsis-ext-01 (work in progress), July 2005. 4015 Appendix A. Bit-Level Formats and Error Messages 4017 This appendix provides formats for the various component parts of the 4018 GIST messages defined abstractly in Section 5.2. 4020 Each GIST message consists of a header and a sequence of objects. 4021 The GIST header has a specific format, described in more detail in 4022 Appendix A.1 below. An NSLP message is one object within a GIST 4023 message. Note that GIST itself provides the message length 4024 information and signaling application identification. General object 4025 formatting guidelines are provided in Appendix A.2 below, followed in 4026 Appendix A.3 by the format for each object. Finally, Appendix A.4 4027 provides the formats used for error reporting. 4029 In the following object diagrams, '//' is used to indicate a variable 4030 sized field and ':' is used to indicate a field that is optionally 4031 present. 4033 A.1. The GIST Common Header 4035 This header precedes all GIST messages. It has a fixed format, as 4036 shown below. 4038 0 1 2 3 4039 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 4040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4041 | Version | GIST hops | Message length | 4042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4043 | Signaling Application ID | Type |S|R|E| Reserved| 4044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4046 Message length = the total number of words in the message after 4047 the common header itself 4048 Type = the GIST message type (Query, Response, etc.) 4049 S flag = S=1 if the IP source address is the same as the 4050 signaling source address, S=0 if it is different 4051 R flag = R=1 if a reply to this message is explicitly 4052 requested 4053 E flag = E=1 if is the message was explicitly routed 4054 Section 7.1.4 4056 The rules governing the use of the R-flag depend on the GIST message 4057 type. It MUST always be set (R=1) in Query messages (these always 4058 elicit a Response), and never in Confirm, Data or Error messages. It 4059 is optional in a MA-Hello; if set, another MA-Hello is sent in reply. 4060 It is optional in a Response (but MUST be set if the Response 4061 contains a Responder cookie); if set, a Confirm is sent in reply. 4063 Parsing failures may be caused by unknown Version or Type values, 4064 inconsistent R flag setting, or a Message Length inconsistent with 4065 the set of objects carried. In all cases the receiver MUST if 4066 possible return an "Common Header Parse Error" message 4067 (Appendix A.4.4.1) with the appropriate subcode, and not process the 4068 message further. 4070 A.2. General Object Format 4072 Each object begins with a fixed header giving the object Type and 4073 object Length. This is followed by the object Value, which is a 4074 whole number of 32-bit words long. 4076 0 1 2 3 4077 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 4078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4079 |A|B|r|r| Type |r|r|r|r| Length | 4080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4081 // Value // 4082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4084 The individual components are as follows: 4086 o The bits marked 'A' and 'B' are extensibility flags which are 4087 defined below; the remaining bits marked 'r' are reserved. 4089 o Length has the units of 32 bit words, and measures the length of 4090 Value. If there is no Value, Length=0. If the Length is not 4091 consistent with the contents of the object, an "Object Value 4092 Error" message (Appendix A.4.4.10) with subcode 0 "Incorrect 4093 Length" MUST be returned and the message dropped. 4095 o Value is (therefore) a whole number of 32 bit words. If there is 4096 any padding required, the length and location must be defined by 4097 the object-specific format information; objects which contain 4098 variable length (e.g. string) types may need to include additional 4099 length subfields to do so. 4101 Any part of the object used for padding or defined as reserved MUST 4102 be set to 0 on transmission and MUST be ignored on reception. 4104 A.2.1. Object Extensibility 4106 The leading two bits of the common TLV header are used to signal the 4107 desired treatment for objects whose treatment has not been defined in 4108 the protocol specification in question (i.e. whose Type field is 4109 unknown at the receiver). The following three categories of object 4110 have been identified, and are described here. 4112 AB=00 ("Mandatory"): If the object is not understood, the entire 4113 message containing it MUST be rejected with a "Object Type Error" 4114 message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object"). 4116 AB=01 ("Ignore"): If the object is not understood, it MUST be deleted 4117 and the rest of the message processed as usual. 4119 AB=10 ("Forward"): If the object is not understood, it MUST be 4120 retained unchanged in any message forwarded as a result of message 4121 processing, but not stored locally. 4123 The combination AB=11 is reserved. Note that the concept of 4124 retaining an unknown object and including it in refresh messages 4125 further up or down the signaling path does not apply to GIST, since 4126 refresh operations only take place between adjacent peers. 4128 A.3. GIST TLV Objects 4130 A.3.1. Message-Routing-Information 4132 Type: Message-Routing-Information 4134 Length: Variable (depends on message routing method) 4136 0 1 2 3 4137 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 4138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4139 | MRM-ID | Reserved | | 4140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4141 // Method-specific addressing information (variable) // 4142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4144 A.3.1.1. Path-Coupled MRM 4146 In the case of basic path-coupled routing, the addressing information 4147 takes the following format: 4149 0 1 2 3 4150 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 4151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4152 |IP-Ver |P|T|F|S|A|B|D|Reserved | 4153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4154 // Source Address // 4155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4156 // Destination Address // 4157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4158 | Source Prefix | Dest Prefix | Protocol | DS-field |Rsv| 4159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4160 : Reserved | Flow Label : 4161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4162 : SPI : 4163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4164 : Source Port : Destination Port : 4165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4167 The flags are: 4168 P - P=1 means that IP Protocol should be interpreted 4169 T - T=1 means that DS-Field should be interpreted; see [4] and [18] 4170 F - F=1 means that flow Label is present and should be interpreted 4171 S - S=1 means that SPI is present and should be interpreted; see [10] 4172 A/B - Source/Destination Port (see below) 4173 D - Direction of message relative to flow 4175 The source and destination addresses are always present and of the 4176 same type; their length depends on the value in the IP-Ver field. In 4177 the normal case where the MRI refers only to traffic between specific 4178 host addresses, the Source/Dest Prefix values would both be 32/128 4179 for IPv4/6 respectively. 4181 In the case of IPv6, the Protocol field refers to the true upper 4182 layer protocol carried by the packets, i.e. excluding any IP option 4183 headers. This is therefore not necessarily the same as the Next 4184 Header value from the base IPv6 header. 4186 F may only be set if IP-Ver is 6. If F is not set, the entire 32 bit 4187 word for the FLow Label is absent. 4189 The S/A/B flags can only be set if P is set. The SPI field is only 4190 present if the S flag is set. 4192 If either of A, B is set (value=1), the word containing the port 4193 numbers is included in the object. However, the contents of each 4194 field is only significant if the corresponding flag is set; 4195 otherwise, the contents of the field is regarded as padding, and the 4196 MRI refers to all ports (i.e. acts as a wildcard). If the flag is 4197 set and Port=0x0000, the MRI will apply to a specific port, whose 4198 value is not yet known. If neither of A or B is set, the word is 4199 absent. 4201 The Direction flag has the following meaning: the value 0 means 'in 4202 the same direction as the flow' (or "downstream"), and the value 1 4203 means 'in the opposite direction to the flow' (or "upstream"). 4205 A.3.1.2. Loose-End MRM 4207 In the case of the loose-end message routing method, the addressing 4208 information takes the following format: 4210 0 1 2 3 4211 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 4212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4213 |IP-Ver |D| Reserved | 4214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4215 // Source Address // 4216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4217 // Destination Address // 4218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4220 The only flag defined is: 4221 D - Direction (always 0 for "downstream") 4223 The source and destination addresses are always present and of the 4224 same type; their length depends on the value in the IP-Ver field. 4226 A.3.2. Session Identification 4228 Type: Session-Identification 4230 Length: Fixed (4 32-bit words) 4232 0 1 2 3 4233 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 4234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4235 | | 4236 + + 4237 | | 4238 + Session ID + 4239 | | 4240 + + 4241 | | 4242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4244 A.3.3. Network-Layer-Information 4246 Type: Network-Layer-Information 4248 Length: Variable (depends on length of Peer-Identity and IP version) 4250 0 1 2 3 4251 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 4252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4253 | PI-Length | IP-TTL |IP-Ver | Reserved | 4254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4255 | Routing State Validity Time | 4256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4257 // Peer Identity // 4258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4259 // Interface Address // 4260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4262 Routing State Validity Time = the time for which the routing state 4263 for this flow can be considered correct without a 4264 refresh. Given in milliseconds. 4265 PI-Length = the byte length of the Peer-Identity field 4266 (note that the Peer-Identity field itself is padded 4267 to a whole number of words) 4268 IP-TTL = initial or reported IP-TTL 4269 IP-Ver = the IP version for the Interface-Address field 4271 A.3.4. Stack Proposal 4273 Type: Stack-Proposal 4275 Length: Variable (depends on number of profiles and size of each 4276 profile) 4278 0 1 2 3 4279 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 4280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4281 | Prof-Count | Reserved | 4282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4283 // Profile 1 // 4284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4285 : : 4286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4287 // Profile 2 // 4288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4289 Prof-Count = The number of profiles in the proposal. MUST be > 0. 4291 Each profile is itself a sequence of protocol layers, and the profile 4292 is formatted as a list as follows: 4294 o The first byte is a count of the number of layers in the profile. 4296 o This is followed by a sequence of 1-byte MA-Protocol-IDs as 4297 described in Section 5.7. 4299 o The profile is padded to a word boundary with 0, 1, 2 or 3 zero 4300 bytes. 4302 If there are no profiles (i.e. all bytes are null), then a "Object 4303 Value Error" message (Appendix A.4.4.10) with subcode 3 ("Empty 4304 List") MUST be returned and the message dropped. 4306 A.3.5. Stack-Configuration-Data 4308 Type: Stack-Configuration-Data 4310 Length: Variable (depends on number of protocols and size of each 4311 protocol configuration data) 4313 0 1 2 3 4314 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 4315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4316 | HL-Count | Reserved | 4317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4318 | MA-Hold-Time | 4319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4320 // Higher-Layer-Information 1 // 4321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4322 : : 4323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4324 // Higher-Layer-Information N // 4325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4326 MA-Hold-Time = the time for which the messaging association will 4327 be held open without traffic or a hello message. 4328 Given in milliseconds. 4329 HL-Count = the number of higher-layer-information fields 4330 (these contain their own length information) 4332 The higher layer information fields are formatted as follows: 4334 0 1 2 3 4335 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 4336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4337 |MA-Protocol-ID | Proposal | Length |D| Reserved | 4338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4339 // Higher-Layer-Addressing // 4340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4341 MA-Protocol-ID = Protocol identifier as described in 4342 Section 5.7 4343 . 4344 Proposal = Tag indicating which proposal from the accompanying 4345 Stack-Proposal object this applies to. Proposals 4346 are numbered from 1 upwards; the special value 0 4347 indicates 'applies to all proposals'. 4348 Length = the byte length of higher layer addressing 4349 information that follows. This will be zero-padded 4350 up to the next word boundary. 4351 D flag = If set (D=1), this protocol MUST not be used for a 4352 messaging assocation. 4354 Note that the format of the higher-layer-addressing data may differ 4355 depending on whether the object is in a GIST-Query or GIST-Response. 4357 A.3.6. Query Cookie 4359 Type: Query-Cookie 4361 Length: Variable (selected by querying node) 4363 0 1 2 3 4364 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 4365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4366 // Query Cookie // 4367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4369 The contents are implementation defined. See Section 8.5 for further 4370 discussion. 4372 A.3.7. Responder Cookie 4374 Type: Responder-Cookie 4376 Length: Variable (selected by responding node) 4377 0 1 2 3 4378 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 4379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4380 // Responder Cookie // 4381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4383 The contents are implementation defined. See Section 8.5 for further 4384 discussion. 4386 A.3.8. NAT Traversal 4388 Type: NAT-Traversal 4390 Length: Variable (depends on length of contained fields) 4392 This object is used to support the NAT traversal mechanisms described 4393 in Section 7.2. 4395 0 1 2 3 4396 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 4397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4398 | MRI-Length | Type-Count | NAT-Count | Reserved | 4399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4400 // Original Message-Routing-Information // 4401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4402 // List of translated objects // 4403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4404 | Length of opaque information | | 4405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 4406 // Information replaced by NAT #1 | 4407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4408 : : 4409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4410 | Length of opaque information | | 4411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 4412 // Information replaced by NAT #N | 4413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4415 MRI-Length = the word length of the included MRI payload 4416 Type-Count = the number of GIST payloads translated by the 4417 NAT; the Type numbers are included as a list 4418 (padded with 2 null bytes if necessary) 4419 NAT-Count = the number of NATs traversed by the message, and the 4420 number of opaque payloads at the end of the object 4422 The length fields in the body of the message are byte counts, not 4423 including the 2 bytes of the length field itself. Note that each 4424 opaque information field is zero-padded to the next 32-bit word 4425 boundary if necessary. 4427 A.3.9. NSLP Data 4429 Type: NSLP-Data 4431 Length: Variable (depends on NSLP) 4433 0 1 2 3 4434 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 4435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4436 // NSLP Data // 4437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4439 A.4. Errors 4441 A.4.1. Error Object 4443 Type: Error 4445 Length: Variable (depends on error) 4447 0 1 2 3 4448 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 4449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4450 | Error Class | Error Code | Error Subcode | 4451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4452 |S|M|C|D|Q| Reserved | MRI Length | Info Count | 4453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4454 | | 4455 + Common Header + 4456 | (of original message) | 4457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4458 : Session Id : 4459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4460 : Message Routing Information : 4461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4462 : Additional Information : 4463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4464 : Debugging Comment : 4465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4466 The flags are: 4467 S - S=1 means the Session ID object is present 4468 M - M=1 means MRI object is present 4469 C - C=1 means a debug Comment is present after header. 4470 D - D=1 means the original message was received in D-Mode 4471 Q - Q=1 means the original message was received Q-Mode encapsulated 4472 (can't be set if D=0). 4474 A GIST Error object contains an error-class (see Appendix A.4.3), an 4475 error-code, an error-subcode, and as much information about the 4476 message which triggered the error as is available. This information 4477 MUST include the Common header of the original message and SHOULD 4478 also include the Session Id and MRI objects if these could be decoded 4479 correctlty. These objects are included in their entirety, except for 4480 their TLV Headers. 4482 The Info Count field contains the number of Additional Information 4483 fields in the object. This count is usually 0 or 1, but may be more 4484 for certain messages; the precise set of fields to include is defined 4485 with the error code/subcode. The field formats are given in 4486 Appendix A.4.2 and their use for the different errors is given in the 4487 error catalogue Appendix A.4.4. The Debugging Comment is a null- 4488 terminated UTF-8 string, padded if necessary to a whole number of 32- 4489 bit words with more null characters. 4491 A.4.2. Additional Information Fields 4493 The Common Error Header may be followed by some Additional 4494 Information objects. The possible formats of these objects are shown 4495 below. 4497 Message Length Info: 4499 0 1 2 3 4500 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 4501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4502 | Calculated Length | Reserved | 4503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4505 Calculated Length = the length of the original message calculated 4506 by adding up all the objects in the message. 4508 MTU Info: 4510 0 1 2 3 4511 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 4512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4513 | Link MTU | Reserved | 4514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4516 This object provides information about the MTU for a link along 4517 which a message could not be sent. 4519 Object Type Info: 4521 0 1 2 3 4522 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 4523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4524 | Object Type | Reserved | 4525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4527 This object provides information about the type of object which 4528 caused the error. 4530 Object Value Info: 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 | Rsvd | Real Object Length | Offset | 4536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4537 // Object // 4538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4540 Real Object Length: Since the length in the original TLV header 4541 may be inaccurate, this field provides the actual 4542 length of the object (including the TLV Header) 4543 included in the error message. 4544 Offset: The byte in the object at which the GIST node 4545 found the error. 4546 Object: The invalid TLV object (including the TLV Header) 4548 This object carries information about a TLV object which was found 4549 to be invalid in the original message. An error message may contain 4550 more than one Object Value Info object. 4552 A.4.3. Error Classes 4554 The first byte of the error object, "Error Class", indicates the 4555 severity level. The currently defined severity levels are: 4557 Informational: response data which should not be thought of as 4558 changing the condition of the protocol state machine. 4560 Success: response data which indicates that the message being 4561 responded to has been processed successfully in some sense. 4563 Protocol-Error: the message has been rejected because of a protocol 4564 error (e.g. an error in message format). 4566 Transient-Failure: the message has been rejected because of a 4567 particular local node status which may be transient (i.e. it may 4568 be worthwhile to retry after some delay). 4570 Permanent-Failure: the message has been rejected because of local 4571 node status which will not change without additional out of band 4572 (e.g. management) operations. 4574 Additional error class values are reserved. 4576 The allocation of error classes to particular errors is not precise; 4577 the above descriptions are deliberately informal. Actual error 4578 processing should take into account the specific error in question; 4579 the error class may be useful supporting information (e.g. in network 4580 debugging). 4582 A.4.4. Error Catalogue 4584 This section lists all the possible GIST errors, including when they 4585 are raised and what additiona information fields should be carried in 4586 the error object. 4588 A.4.4.1. Common Header Parse Error 4590 Class: Protocol-Error 4591 Code: 1 4592 Additional Info: Depends on subcode 4594 This message is sent if a GIST node receives a message where the 4595 common header cannot be parsed correctly, or where an error in the 4596 overall message format is detected. Note that in this case the 4597 original MRI and Session ID are not included in the Error Object. 4598 This error code is split into subcodes as follows: 4600 0: Unknown Version: The GIST version is unknown. The (highest) 4601 supported version supported by the node can be inferred from the 4602 Common Header of the GIST-Error message itself. 4604 1: Unknown Type: The GIST message type is unknown. 4606 2: Invalid R-flag: The R flag in the header is inconsistent with the 4607 message type. 4609 3: Incorrect Message Length: The overall message length is not 4610 consistent with the set of objects carried. An Additional Info 4611 field of Message Length Info carries the calculated message 4612 length. 4614 A.4.4.2. Hop Limit Exceeded 4616 Class: Permanent-Failure 4617 Code: 2 4618 Additional Info: None 4620 This message is sent if a GIST node receives a message with a GIST 4621 Hop Limit of zero, or a GIST node decrements a packet's GIST Hop 4622 Limit to zero. This message indicates either a routing loop or too 4623 small an initial Hop Limit value. 4625 A.4.4.3. Incorrect Encapsulation 4627 Class: Protocol-Error 4628 Code: 3 4629 Additional Info: None 4631 This message is sent if a GIST node receives a message which uses an 4632 incorrect encapsulation method (e.g. a Query arrives over an MA). 4634 A.4.4.4. Incorrectly Delivered Message 4636 Class: Protocol-Error 4637 Code: 4 4638 Additional Info: None 4640 This message is sent if a GIST node receives a message over an MA 4641 which is not associated with the MRI/NSLPID/SID combination in the 4642 message. 4644 A.4.4.5. No Routing State 4646 Class: Protocol-Error 4647 Code: 5 4648 Additional Info: None 4650 This message is sent if a node receives a message for which there is 4651 no matching routing state (and therefore no appropriate Q/R-SM). 4653 This can occur either at a Querying node which receives an unexpected 4654 Response message, or at a Responding node which receives an 4655 unexpected Data message. 4657 A.4.4.6. Unknown NSLPID 4659 Class: Permanent-Failure 4660 Code: 6 4661 Additional Info: None 4663 This message is sent if a router receives a directly addressed 4664 message for an NSLP which it does not support. 4666 A.4.4.7. Endpoint Found 4668 Class: Informational 4669 Code: 7 4670 Additional Info: None 4672 This message is sent if a GIST node at a flow endpoint receives a 4673 Query message for an NSLP which it does not support. 4675 A.4.4.8. Message Too Large 4677 Class: Permanent-Failure 4678 Code: 8 4679 Additional Info: MTU Info 4681 A router receives a message which it can't forward because it exceeds 4682 the MTU on the next or subsequent hops. 4684 A.4.4.9. Object Type Error 4686 Class: Protocol-Error 4687 Code: 9 4688 Additional Info: Object Type Info 4690 This message is sent if a GIST node receives a message containing a 4691 TLV object with an invalid type. The message includes the type of 4692 the object at fault. This error code is split into subcodes as 4693 follows: 4695 0: Duplicate Object: This subcode is used if a GIST node receives a 4696 message containing multiple instances of an object which may only 4697 appear once in a message (in the current specification this 4698 applies to all objects). 4700 1: Unrecognised Object: This subcode is used if a GIST node receive a 4701 message containing an object which it does not support, and the 4702 extensibility flags AB=00. 4704 2: Missing Object: This subcode is used if a GIST node receives a 4705 message which is missing one or more mandatory objects. This 4706 message is also sent if a Stack Proposal is sent without a 4707 matching Stack Configuration Data object when one was necessary, 4708 or vice versa. 4710 3: Invalid Object: This subcode is used if the object type is known, 4711 but it is not valid for this particular GIST message type. 4713 4: Untranslated Object: This subcode is used if the object type is 4714 known, but it is mandatory to interpret, contains addressing data, 4715 but has not been translated by an intervening NAT. 4717 A.4.4.10. Object Value Error 4719 Class: Protocol-Error 4720 Code: 10 4721 Additional Info: Object Value Info 4723 This message is sent if a router receives a packet containing an 4724 object which cannot be properly parsed. The message contains a 4725 single Object Value Info object, unless otherwise stated below. This 4726 error code is split into subcodes as follows: 4728 0: Incorrect Length: The overall length does not match the object 4729 length calculated from the object contents. 4731 1: Value Not Supported: The value of a field is not supported by the 4732 GIST node. 4734 2: Invalid Flag-Field Combination: An object contains an invalid 4735 combination of flags and/or fields. At the moment this only 4736 relates to the Path-Coupled MRM object, but in future there may be 4737 more. 4739 3: Empty List: At the moment this only relates to Stack Proposals. 4740 The error message is sent if a stack proposal with a length > 0 (a 4741 length of 0 is handled as "Value Not Supported") contains only 4742 null bytes. 4744 4: Invalid Cookie: The message contains a cookie which could not be 4745 verified by the node. 4747 5: SP-SCD Mismatch: This subcode is used if a GIST node receives a 4748 message in which the data in the Stack Proposal object is 4749 inconsistent with the information in the Stack Configuration Data 4750 object. In this case, both the Stack Proposal object and Stack 4751 Configuration Data object are included in the message, in separate 4752 Object Value Info fields. 4754 A.4.4.11. Invalid IP TTL 4756 Class: Permanent-Failure 4757 Code: 11 4758 Additional Info: None 4760 This error indicates that a message was received with an IP-TTL 4761 outside an acceptable range; for example, that an upstream Query was 4762 received with an IP-TTL of less than 254 (i.e. more than one IP hop 4763 from the sender). The actual IP distance can be derived from the IP- 4764 TTL information in the NLI object carried in the same message. 4766 A.4.4.12. MRI Too Wild 4768 Class: Permanent-Failure 4769 Code: 12 4770 Additional Info: Object Value Info 4772 This error indicates that a message was received with an MRI that 4773 contained too much wildcarding (e.g. too short a destination address 4774 prefix) to be forwarded correctly down a single path. The Object 4775 Value Info includes the MRI so the error originator can indicate a 4776 part of the MRI which includes too much wildcarding. 4778 Appendix B. API between GIST and NSLP 4780 This appendix provides an abstract API between GIST and NSLPs. It 4781 should not constrain implementors, but rather help clarify the 4782 interface between the different layers of the NSIS protocol suite. 4783 In addition, although some of the data types carry the information 4784 from GIST information elements, this does not imply that the format 4785 of that data as sent over the API has to be the same. 4787 Conceptually the API has similarities to the sockets API, 4788 particularly that for unconnected UDP sockets. An extension for an 4789 API like that for UDP connected sockets could be considered. In this 4790 case, for example, the only information needed in a SendMessage 4791 primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle 4792 (which can be null). Other information which was persistent for a 4793 group of messages could be configured once for the socket. Such 4794 extensions may make a concrete implementation more efficient but do 4795 not change the API semantics, and so are not considered further here. 4797 B.1. SendMessage 4799 This primitive is passed from an NSLP to GIST. It is used whenever 4800 the NSLP wants to initiate sending a message. 4802 SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, 4803 NSLP-Id, Session-ID, MRI, 4804 SII-Handle, Transfer-Attributes, Timeout, IP-TTL, GHC ) 4806 The following arguments are mandatory. 4808 NSLP-Data: The NSLP message itself. 4810 NSLP-Data-Size: The length of NSLP-Data. 4812 NSLP-Message-Handle: A handle for this message, that can be used 4813 later by GIST to reference it in MessageStatus notifications 4814 (Appendix B.3), in particular about errors or what security 4815 attributes will be used for the message. A NULL handle may be 4816 supplied if the NSLP is not interested in notifications. 4818 NSLP-Id: An identifier indicating which NSLP this is. 4820 Session-ID: The NSIS session identifier. Note that it is assumed 4821 that the signaling application provides this to GIST rather than 4822 GIST providing a value itself. 4824 MRI: Message routing information for use by GIST in determining the 4825 correct next GIST hop for this message. The MRI implies the 4826 message routing method to be used and the message direction. 4828 The following arguments are optional. 4830 SII-Handle: A handle, previously supplied by GIST, to a data 4831 structure that should be used to route the message explicitly to a 4832 particular GIST next hop. 4834 Transfer-Attributes: Attributes defining how the message should be 4835 handled (see Section 4.1.2). The following attributes can be 4836 considered: 4838 Reliability: Values 'unreliable' or 'reliable'. 4840 Security: This attribute allows the NSLP to specify what level of 4841 security protection is requested for the message (selected from 4842 'integrity' and 'confidentiality'), and can also be used to 4843 specify what authenticated signaling source and destination 4844 identities should be used to send the message. The 4845 possibilities can be learned by the NSLP from prior 4846 MessageStatus or RecvMessage notifications. If an NSLP- 4847 Message-Handle is provided, GIST will inform the NSLP of what 4848 values it has actually chosen for this attribute via a 4849 MessageStatus callback. This might take place either 4850 synchronously (where GIST is selecting from available messaging 4851 associations), or asynchronously (when a new messaging 4852 association needs to be created). 4854 Local Processing: This attribute contains hints from the NSLP 4855 about what local policy should be applied to the message; in 4856 particular, its transmission priority relative to other 4857 messages, or whether GIST should attempt to set up or maintain 4858 forward routing state. 4860 Timeout: Length of time GIST should attempt to send this message 4861 before indicating an error. 4863 IP-TTL: The value of the IP TTL that should be used when sending this 4864 message (may be overridden by GIST for particular messages). 4866 GHC: The value for the GIST hop count when sending the message. 4868 B.2. RecvMessage 4870 This primitive is passed from GIST to an NSLP. It is used whenever 4871 GIST receives a message from the network, including the case of 4872 'null' messages (zero length NSLP payload), typically initial Query 4873 messages. This primitive can return a value from the NSLP which 4874 indicates whether GIST should retain message routing state. 4876 RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Id, Session-ID, MRI, 4877 Adjacency-Check, SII-Handle, Transfer-Attributes, 4878 IP-TTL, IP-Distance, GHC ) 4880 NSLP-Data: The NSLP message itself (may be empty). 4882 NSLP-Data-Size: The length of NSLP-Data (may be zero). 4884 NSLP-Id: An identifier indicating which NSLP this is message is for. 4886 Session-ID: The NSIS session identifier. 4888 MRI: Message routing information that was used by GIST in forwarding 4889 this message. Implicitly defines the message routing method that 4890 was used and the direction of the message relative to the MRI. 4892 Adjacency-Check: This boolean is True if GIST is checking with the 4893 NSLP to see if a signaling adjacency should be formed (see 4894 Section 4.3.2). If True, the signaling application should return 4895 the following values via the RecvMessage call: 4897 A boolean indicating whether to form the adjacency. 4899 Optionally, an NSLP-Payload to carry in the generated GIST- 4900 Response or forwarded Query/Data message respectively. 4902 SII-Handle: A handle to a data structure, identifying a peer address 4903 and interface. Can be used to identify route changes and for 4904 explicit routing to a particular GIST next hop. 4906 Transfer-Attributes: The reliability and security attributes that 4907 were associated with the reception of this particular message. As 4908 well as the attributes associated with SendMessage, GIST may 4909 indicate the level of verification of the addresses in the MRI. 4910 Three attributes can be indicated: 4912 * Whether the signaling source address is one of the flow 4913 endpoints (i.e. whether this is the first or last GIST hop); 4915 * Whether the signaling source address has been validated by a 4916 return routability check. 4918 * Whether the message was explicitly routed (and so has not been 4919 validated by GIST as delivered consistently with local routing 4920 state). 4922 IP-TTL: The value of the IP TTL this message was received with (if 4923 available). 4925 IP-Distance: The number of IP hops from the peer signaling node which 4926 sent this message along the path, or 0 if this information is not 4927 available. 4929 GHC: The value of the GIST hop count the message was received with, 4930 after being decremented in the GIST receive-side processing. 4932 B.3. MessageStatus 4934 This primitive is passed from GIST to an NSLP. It is used to notify 4935 the NSLP that a message that it requested to be sent could not be 4936 dispatched, or to inform the NSLP about the transfer attributes that 4937 have been selected for the message (specifically, security 4938 attributes). The NSLP can respond to this message with a return code 4939 to abort the sending of the message if the attributes are not 4940 acceptable. 4942 MessageStatus (NSLP-Message-Handle, Transfer-Attributes, Error-Type) 4944 NSLP-Message-Handle: A handle for the message provided by the NSLP in 4945 SendMessage. 4947 Transfer-Attributes: The reliability and security attributes that 4948 will be used to transmit this particular message. 4950 Error-Type: Indicates the type of error that occurred. For example, 4951 'no next node found'. 4953 B.4. NetworkNotification 4955 This primitive is passed from GIST to an NSLP. It indicates that a 4956 network event of possible interest to the NSLP occurred. 4958 NetworkNotification ( MRI, Network-Notification-Type ) 4960 MRI: Provides the message routing information to which the network 4961 notification applies. 4963 Network-Notification-Type: Indicates the type of event that caused 4964 the notification and associated additional data. Two events have 4965 been identified: 4967 Last Node: GIST has detected that this is the last NSLP-aware node 4968 in the path. See Section 4.3.4. 4970 Routing Status Change: GIST has detected that the routing state 4971 may no longer be valid, or has re-established the routing 4972 state. See Section 7.1.3. The new status is reported; if the 4973 status is Good, the SII-Handle of the peer is also reported, as 4974 for RecvMessage. 4976 B.5. SetStateLifetime 4978 This primitive is passed from an NSLP to GIST. It indicates the 4979 lifetime for which GIST should retain its routing state. It can also 4980 give a hint that the NSLP is no longer interested in the state. 4982 SetStateLifetime ( MRI, State-Lifetime ) 4984 MRI: Provides the message routing information to which the routing 4985 state lifetime applies; includes the direction (in the D flag). 4987 State-Lifetime: Indicates the lifetime for which the NSLP wishes GIST 4988 to retain its routing state (may be zero, indicating that the NSLP 4989 has no further interest in the GIST state). 4991 B.6. InvalidateRoutingState 4993 This primitive is passed from an NSLP to GIST. It indicates that the 4994 NSLP has knowledge that the next signaling hop known to GIST may no 4995 longer be valid, either because of changes in the network routing or 4996 the processing capabilities of NSLP nodes. See Section 7.1. 4998 InvalidateRoutingState ( NSLP-Id, MRI, Status, Urgent ) 5000 NSLP-Id: The NSLP originating the message. May be null (in which 5001 case the invalidation applies to all signaling applications). 5003 MRI: The flow for which routing state should be invalidated; includes 5004 the direction of the change (in the D flag). 5006 Status: The new status that should be assumed for the routing state, 5007 one of Bad or Tentative (see Section 7.1.3). 5009 Urgent: A hint as to whether rediscovery should take place 5010 immediately, or only with the next signaling message. 5012 Appendix C. Example Routing State Table and Handshake Message Sequence 5014 Figure 10 shows a signaling scenario for a single flow being managed 5015 by two signaling applications using the path-coupled message routing 5016 method. The flow sender and receiver and one router support both, 5017 two other routers support one each. The figure also shows the 5018 routing state table at node B. 5020 A B C D E 5021 +------+ +-----+ +-----+ +-----+ +--------+ 5022 | Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow | 5023 |Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver| 5024 | | +-+ +-+ |GIST | |GIST | |GIST | | | 5025 +------+ +-----+ +-----+ +-----+ +--------+ 5026 Flow Direction ------------------------------>> 5028 +------------------------------------+---------+--------+-----------+ 5029 | Message Routing Information | Session | NSLP | Routing | 5030 | | ID | ID | State | 5031 +------------------------------------+---------+--------+-----------+ 5032 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | IP-A | 5033 | {IP-A, IP-E, proto/ports}; D=up | | | | 5034 | | | | | 5035 | MRM = Path Coupled; Flow ID = | 0xABCD | NSLP1 | (null) | 5036 | {IP-A, IP-E, proto/ports}; D=down | | | | 5037 | | | | | 5038 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | IP-A | 5039 | {IP-A, IP-E, proto/ports}; D=up | | | | 5040 | | | | | 5041 | MRM = Path Coupled; Flow ID = | 0x1234 | NSLP2 | Points to | 5042 | {IP-A, IP-E, proto/ports}; D=down | | | B-D MA | 5043 +------------------------------------+---------+--------+-----------+ 5045 Figure 10: A Signaling Scenario 5047 The upstream state is just the same address for each application. 5048 For the downstream direction, NSLP1 only requires datagram mode 5049 messages and so no explicit routing state towards C is needed. NSLP2 5050 requires a messaging association for its messages towards node D, and 5051 node C does not process NSLP2 at all, so the peer state for NSLP2 is 5052 a pointer to a messaging association that runs directly from B to D. 5053 Note that E is not visible in the state table (except implicitly in 5054 the address in the message routing information); routing state is 5055 stored only for adjacent peers. (In addition to the peer 5056 identification, IP hop counts are stored for each peer where the 5057 state itself if not null; this is not shown in the table.) 5059 Figure 11 shows the message sequence for a GIST handshake that sets 5060 up the messaging association for B-D signaling. It shows the 5061 exchange of Stack Proposals and higher layer configuration data in 5062 each direction. Then the Querying node selects TLS/TCP as the stack 5063 configuration to use and sets up the messaging association over which 5064 it sends the Confirm. 5066 -----------------------GIST-Query ---------------------> 5067 IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=GIST; Dst=0x6789) 5068 GIST(Header(Type=Query; NSLPID=NSLP2; R=1; S=0) 5069 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 5070 SessionID(0x1234) 5071 NLI(Peer='string1'; IA=IP#B) 5072 QueryCookie(0x139471239471923526) 5073 StackProposal(#Proposals=3;1=TLS/TCP; 2=TLS/SCTP; 3=TCP) 5074 StackConfigurationData(#HLI=2; 5075 TCP(Applicable: all; Data: null) 5076 SCTP(Applicable: all; Data: null))) 5078 <---------------------GIST-Response--------------------- 5079 IP(Src=IP#D; Dst=IP#B); UDP(Src=0x6789; Dst=GIST) 5080 GIST(Header(Type=Response; NSLPID=NSLP2; R=1; S=1) 5081 MRI(MRM=Path-Coupled; Flow=F; Direction=up) 5082 SessionID(0x1234) 5083 NLI(Peer='stringr2, IA=IP#D) 5084 QueryCookie(0x139471239471923526) 5085 ResponderCookie(0xacdefedcdfaeeeded) 5086 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP) 5087 StackConfigurationData(#HLI=3; 5088 TCP(Applicable: 3; Data: port=6123) 5089 TCP(Applicable: 1; Data: port=5438) 5090 SCTP(Applicable: all; Data: port=3333))) 5092 -------------------------TCP SYN-----------------------> 5093 <----------------------TCP SYN/ACK---------------------- 5094 -------------------------TCP ACK-----------------------> 5095 TCP connect(IP Src=IP#B; IP Dst=IP#D; Src Port=91234; Dst Port=6123) 5096 <-----------------------TLS INIT-----------------------> 5098 ----------------------GIST-Confirm---------------------> 5099 [Sent within messaging association] 5100 GIST(Header(Type=Confirm; NSLPID=NSLP2; R=0; S=1) 5101 MRI(MRM=Path-Coupled; Flow=F; Direction=down) 5102 SessionID(0x1234) 5103 NLI(Peer='string1'; IA=IP#R) 5104 ResponderCookie(0xacdefedcdfaeeeded) 5105 StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)) 5107 Figure 11: GIST Handshake Message Sequence 5109 Appendix D. Change History 5111 D.1. Changes In Version -08 5113 1. Changed the protocol name from GIMPS to GIST (everywhere). 5115 2. Inserted RFC2119 language (MUST etc.) in the appropriate places. 5117 3. Added references to the actions to be taken in various error 5118 conditions, including the error messages to be send 5119 (throughout). 5121 4. Added legacy NAT traversal to the list of excluded functions in 5122 Section 1.1. 5124 5. Included some text at the end of Section 3.3 analysing the case 5125 of a GIST node which does not support a particular MRM. 5127 6. Added a flag to mark when messages have been explicitly routed, 5128 so they can bypass validation against current routing state (see 5129 Section 4.3.1, TBD). 5131 7. Re-wrote the discussion in Section 4.3.4 to cover all cases of 5132 nodes not hosting an NSLP (including end systems), in particular 5133 the validations that can be performed at intermediate GIST nodes 5134 (this replaces the old section 7.2). 5136 8. Clarified the rules about R and S flag setting in the common 5137 header and D flag in the MRI (Section 5). 5139 9. Included discussion of how a node with a choice of interfaces or 5140 IP versions should select one to use in the NLI (Section 5.2.2). 5142 10. Modified the description of messaging association protocol 5143 selections (Section 5.7 and elsewhere) to clarify that this is 5144 essentially capability discovery rather than an open ended 5145 protocol negotiation. 5147 11. Modified the description of how higher layer addressing 5148 information is carried (Section 5.7.1 and Appendix A.3.5) to 5149 allow the data to be tagged against a specific profile if 5150 necessary, or omitted if the protocol does not need it. 5152 12. Added a higher layer protocol definition for TLS in 5153 Section 5.7.3. 5155 13. Simplified and restructured the state machine presentation in 5156 Section 6, in particular using a single list for the events and 5157 eliminating the transition tables. Also modified the operation 5158 of the Responder machine to handle retransmitted Query messages 5159 correctly. 5161 14. Re-wrote the route change handling text in Section 7.1 to 5162 clarify the relative responsibilities of GIST and NSLPs and 5163 their interaction through the API. Notifications are now 5164 assumed to be a signaling application responsibility, and GIST 5165 behaviour is defined in terms of handling changes in a 3-state 5166 model of the correctness of the routing state for each 5167 direction. 5169 15. Updated the NAT traversal description in Section 7.2, including 5170 normative text about how GIST nodes should handle messages 5171 containing NAT-Traversal objects. 5173 16. Likewise, clarified that the responsibility for session/flow 5174 binding in the case of tunnelling is handled by NSLPs 5175 (Section 7.3). 5177 17. Formalised the IANA considerations (Section 9). 5179 18. Extended the routing state example (Appendix C) to include a 5180 message sequence for association setup. 5182 19. Re-arranged the sequence of sections, including placing this 5183 change history at the end. 5185 D.2. Changes In Version -07 5187 1. The open issues section has finally been removed in favour of the 5188 authoritative list of open issues in an online issue tracker at h 5189 ttp://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index. 5191 2. Clarified terminology on peering and adjacencies that there may 5192 be NSIS nodes between GIMPS peers that do some message 5193 processing, but that are not explicitly visible in the peer state 5194 tables. 5196 3. Added a description of the loose-end MRM (Section 5.8.2 and 5197 Appendix A.3.1.2). 5199 4. Added a description of an upstream Query encapsulation for the 5200 path-coupled MRM, Section 5.8.1.3, including rationale for and 5201 restrictions on its use. 5203 5. The formal description of the protocol in Section 6 has been 5204 significantly updated and extended in terms of detail. 5206 6. Modified the description of the interaction between NSLPs and 5207 GIMPS for handling inbound messages for which no routing state 5208 exists, to allow the NSLP to indicate whether state setup should 5209 proceed and to provide NSLP payloads for the Response or 5210 forwarded message (Section 3.5, Section 4.3.2 and Appendix B). 5212 7. Included new text, Section 5.6, on the processing and 5213 encapsulation of error messages. Also added formats and an error 5214 message catalogue in Appendix A.4, including a modified format 5215 for the overall GIMPS-Error message and the GIMPS-Error-Data 5216 object. 5218 8. Removed the old section 5.3.3 on NSLPID/RAO setting on the 5219 assumption that this will be covered in the extensibility 5220 document. 5222 9. Included a number of other minor corrections and clarifications. 5224 D.3. Changes In Version -06 5226 Version -06 does not introduce any major structural changes to the 5227 protocol definition, although it does clarify a number of details and 5228 resolve some outstanding open issues. The primary changes are as 5229 follows: 5231 1. Added a new high level Section 3.3 which gathers together the 5232 various aspects of the message routing method concept. 5234 2. Added a new high level Section 3.4 which explains the concept 5235 and significance of the session identifier. Also clarified that 5236 the routing state always depends on the session identifier. 5238 3. Added notes about the level of address validation performed by 5239 GIMPS in Section 4.1.2 and extensions to the API in Appendix B. 5241 4. Split the old Node-Addressing object into a Network-Layer- 5242 Information object and Stack-Configuration-Data object. The 5243 former refers to basic information about a node, and the latter 5244 carries information about messaging association configuration. 5245 Redefined the content of the various handshake messages 5246 accordingly in Section 4.4.1 and Section 5.1. 5248 5. Re-wrote Section 4.4.3 to clarify the rules on refresh and purge 5249 of routing state and messaging associations. Also, moved the 5250 routing state lifetime into the Network-Layer-Information object 5251 and added a messaging association lifetime to the Stack- 5252 Configuration-Data object (Section 5.2). 5254 6. Added specific message types for errors and MA-Refresh in 5255 Section 5.1. The error object is now GIMPS-specific 5256 (Appendix A.4.1). 5258 7. Moved the Flow-Identifier information about the message routing 5259 method from the general description of the object to the path- 5260 coupled MRM section (Section 5.8.1.1), and made a number of 5261 clarifications to the bit format (Appendix A.3.1.1). 5263 8. Removed text about assumptions on the version numbering of 5264 NSLPs, and restricted the scope of the description of TLV objct 5265 formats and extensibility flags to GIMPS rather than the whole 5266 of NSIS (Appendix A). 5268 9. Added a new Section 5.5 explaining the possible relationships 5269 between message types and encapsulation formats. 5271 10. Added a new Section 6 in outline form, to capture the formal 5272 specification of the protocol operation. 5274 11. Added new security sections on cookie requirements (Section 8.5) 5275 and residual threats (Section 8.6). 5277 D.4. Changes In Version -05 5279 Version -05 reformulates the specification, to describe routing state 5280 maintenance in terms of exchanging explicitly identified Query/ 5281 Response/Confirm messages, leaving the upstream/downstream 5282 distinction as a specific detail of how Query messages are 5283 encapsulated. This necessitated widespread changes in the 5284 specification text, especially Section 4.2.1, Section 4.4, 5285 Section 5.1 and Section 5.3 (although the actual message sequences 5286 are unchanged). A number of other issues, especially in the area of 5287 message encapsulation, have also been closed. The main changes are 5288 the following: 5290 1. Added a reference to an individual draft on the Loose End MRM as 5291 a concrete example of an alternative message routing method. 5293 2. Added further text (particularly in Section 2) on what GIMPS 5294 means by the concept of 'session'. 5296 3. Firmed up the selection of UDP as the encapsulation choice for 5297 datagram mode, removing the open issue on this topic. 5299 4. Defined the interaction between GIMPS and signaling applications 5300 for communicating about the cryptographic security properties of 5301 how a message will be sent or has been received (see 5302 Section 4.1.2 and Appendix B). 5304 5. Closed the issue on whether Query messages should use the 5305 signaling or flow source address in the IP header; both options 5306 are allowed by local policy and a flag in the common header 5307 indicates which was used. (See Section 5.8.1.2.) 5309 6. Added the necessary information elements to allow the IP hop 5310 count between adjacent GIMPS peers to be measures and reported. 5311 (See Section 5.2.2 and Appendix A.3.3.) 5313 7. The old open-issue text on selection of IP router alert option 5314 values has been moved into the main specification to capture the 5315 technical considerations that should be used in assigning such 5316 values (in old section 5.3.3). 5318 8. Resolved the open issue on lost Confirm messages by allowing a 5319 choice of timer-based retransmission of the Response, or an 5320 error message from the responding node which causes the 5321 retransmission of the Confirm (see Section 5.3.3). 5323 9. Closed the open issue on support for message scoping (this is 5324 now assumed to be a NSLP function). 5326 10. Moved the authoritative text for most of the remaining open 5327 issues to an online issue tracker. 5329 D.5. Changes In Version -04 5331 Version -04 includes mainly clarifications of detail and extensions 5332 in particular technical areas, in part to support ongoing 5333 implementation work. The main details are as follows: 5335 1. Substantially updated Section 4, in particular clarifying the 5336 rules on what messages are sent when and with what payloads 5337 during routing and messaging association setup, and also adding 5338 some further text on message transfer attributes. 5340 2. The description of messaging association protocol setup 5341 including the related object formats has been centralised in a 5342 new Section 5.7, removing the old Section 6.6 and also closing 5343 old open issues 8.5 and 8.6. 5345 3. Made a number of detailed changes in the message format 5346 definitions (Appendix A), as well as incorporating initial rules 5347 for encoding message extensibility information. Also included 5348 explicit formats for a general purpose Error object, and the 5349 objects used to discover supported messaging association 5350 protocols. Updated the corresponding open issues section (old 5351 section 9.3) with a new item on NSLP versioning. 5353 4. Updated the GIMPS API (Appendix B), including more precision on 5354 message transfer attributes, making the NSLP hint about storing 5355 reverse path state a return value rather than a separate 5356 primitive, and adding a new primitive to allow signaling 5357 applications to invalidate GIMPS routing state. Also, added a 5358 new parameter to SendMessage to allow signaling applications to 5359 'bypass' a message statelessly, preserving the source of an 5360 input message. 5362 5. Added an outline for the future content of an IANA 5363 considerations section (Section 9). Currently, this is 5364 restricted to identifying the registries and allocations 5365 required, without defining the allocation policies and other 5366 considerations involved. 5368 6. Shortened the background design discussion in Section 3. 5370 7. Made some clarifications in the terminology section relating to 5371 how the use of C-mode does and does not mandate the use of 5372 transport or security protection. 5374 8. The ABNF for message formats in Section 5.1 has been re-written 5375 with a grammar structured around message purpose rather than 5376 message direction, and additional explanation added to the 5377 information element descriptions in Section 5.2. 5379 9. The description of the datagram mode transport in Section 5.3 5380 has been updated. The encapsulation rules (covering IP 5381 addressing and UDP port allocation) have been corrected, and a 5382 new subsection on message retransmission and rate limiting has 5383 been added, superceding the old open issue on the same subject 5384 (section 8.10). 5386 10. A new open issue on IP TTL measurement to detect non-GIMPS 5387 capable hops has been added (old section 9.5). 5389 D.6. Changes In Version -03 5391 Version -03 includes a number of minor clarifications and extensions 5392 compared to version -02, including more details of the GIMPS API and 5393 messaging association setup and the node addressing object. The full 5394 list of changes is as follows: 5396 1. Added a new section pinning down more formally the interaction 5397 between GIMPS and signaling applications (Section 4.1), in 5398 particular the message transfer attributes that signaling 5399 applications can use to control GIMPS (Section 4.1.2). 5401 2. Added a new open issue identifying where the interaction between 5402 the security properties of GIMPS and the security requirements of 5403 signaling applications should be identified (old section 9.10). 5405 3. Added some more text in Section 4.2.1 to clarify that GIMPS has 5406 the (sole) responsibility for generating the messages that 5407 refresh message routing state. 5409 4. Added more clarifying text and table to GHC and IP TTL handling 5410 discussion of Section 4.3.4. 5412 5. Split Section 4.4 into subsections for different scenarios, and 5413 added more detail on Node-Addressing object content and use to 5414 handle the case where association re-use is possible in 5415 Section 4.4.2. 5417 6. Added strawman object formats for Node-Addressing and Stack- 5418 Proposal objects in Section 5.1 and Appendix A. 5420 7. Added more detail on the bundling possibilities and appropriate 5421 configurations for various transport protocols in Section 5.4.1. 5423 8. Included some more details on NAT traversal in Section 7.2, 5424 including a new object to carry the untranslated address-bearing 5425 payloads, the NAT-Traversal object. 5427 9. Expanded the open issue discussion in old section 9.3 to include 5428 an outline set of extensibility flags. 5430 D.7. Changes In Version -02 5432 Version -02 does not represent any radical change in design or 5433 structure from version -01; the emphasis has been on adding details 5434 in some specific areas and incorporation of comments, including early 5435 review comments. The full list of changes is as follows: 5437 1. Added a new Section 1.1 which summarises restrictions on scope 5438 and applicability; some corresponding changes in terminology in 5439 Section 2. 5441 2. Closed the open issue on including explicit GIMPS state teardown 5442 functionality. On balance, it seems that the difficulty of 5443 specifying this correctly (especially taking account of the 5444 security issues in all scenarios) is not matched by the saving 5445 of state enabled. 5447 3. Removed the option of a special class of message transfer for 5448 reliable delivery of a single message. This can be implemented 5449 (inefficiently) as a degenerate case of C-mode if required. 5451 4. Extended Appendix A with a general discussion of rules for 5452 message and object formats across GIMPS and other NSLPs. Some 5453 remaining open issues are noted in old section 9.3 (since 5454 removed). 5456 5. Updated the discussion of RAO/NSLPID relationships to take into 5457 account the proposed message formats and rules for allocation of 5458 NSLP id, and propose considerations for allocation of RAO 5459 values. 5461 6. Modified the description of the information used to route 5462 messages (first given in Section 4.2.1 but also throughout the 5463 document). Previously this was related directly to the flow 5464 identification and described as the Flow-Routing-Information. 5465 Now, this has been renamed Message-Routing-Information, and 5466 identifies a message routing method and any associated 5467 addressing. 5469 7. Modified the text in Section 4.3 and elsewhere to impose sanity 5470 checks on the Message-Routing-Information carried in C-mode 5471 messages, including the case where these messages are part of a 5472 GIMPS-Query/Response exchange. 5474 8. Added rules for message forwarding to prevent message looping in 5475 a new Section 4.3.4, including rules on IP TTL and GIMPS hop 5476 count processing. These take into account the new RAO 5477 considerations described above. 5479 9. Added an outline mechanism for messaging association protocol 5480 stack setup, with the details in a new Section 6.6 and other 5481 changes in Section 4.4 and the various sections on message 5482 formats. 5484 10. Removed the open issue on whether storing reverse routing state 5485 is mandatory or optional. This is now explicit in the API 5486 (under the control of the local NSLP). 5488 11. Added an informative annex describing an abstract API between 5489 GIMPS and NSLPs in Appendix B. 5491 D.8. Changes In Version -01 5493 The major change in version -01 is the elimination of 5494 'intermediaries', i.e. imposing the constraint that signaling 5495 application peers are also GIMPS peers. This has the consequence 5496 that if a signaling application wishes to use two classes of 5497 signaling transport for a given flow, maybe reaching different 5498 subsets of nodes, it must do so by running different signaling 5499 sessions; and it also means that signaling adaptations for passing 5500 through NATs which are not signaling application aware must be 5501 carried out in datagram mode. On the other hand, it allows the 5502 elimination of significant complexity in the connection mode handling 5503 and also various other protocol features (such as general route 5504 recording). 5506 The full set of changes is as follows: 5508 1. Added a worked example in Section 3.5. 5510 2. Stated that nodes which do not implement the signaling 5511 application should bypass the message (Section 4.3). 5513 3. Decoupled the state handling logic for routing state and 5514 messaging association state in Section 4.4. Also, allow 5515 messaging associations to be used immediately in both directions 5516 once they are opened. 5518 4. Added simple ABNF for the various GIMPS message types in a new 5519 Section 5.1, and more details of the common header and each 5520 object in Section 5.2, including bit formats in Appendix A. The 5521 common header format means that the encapsulation is now the 5522 same for all transport types (Section 5.4.1). 5524 5. Added some further details on datagram mode encapsulation in 5525 Section 5.3, including more explanation of why a well known port 5526 is needed. 5528 6. Removed the possibility for fragmentation over DCCP 5529 (Section 5.4.1), mainly in the interests of simplicity and loss 5530 amplification. 5532 7. Removed all the tunnel mode encapsulations (old sections 5.3.3 5533 and 5.3.4). 5535 8. Fully re-wrote the route change handling description 5536 (Section 7.1), including some additional detection mechanisms 5537 and more clearly distinguishing between upstream and downstream 5538 route changes. Included further details on GIMPS/NSLP 5539 interactions, including where notifications are delivered and 5540 how local repair storms could be avoided. Removed old 5541 discussion of propagating notifications through signaling 5542 application unaware nodes (since these are now bypassed 5543 automatically). Added discussion on how to route messages for 5544 local state removal on the old path. 5546 9. Revised discussion of policy-based forwarding (old Section 7.2) 5547 to account for actual FLow-Routing-Information definition, and 5548 also how wildcarding should be allowed and handled. 5550 10. Removed old route recording section (old Section 6.3). 5552 11. Extended the discussion of NAT handling (Section 7.2) with an 5553 extended outline on processing rules at a GIMPS-aware NAT and a 5554 pointer to implications for C-mode processing and state 5555 management. 5557 12. Clarified the definition of 'correct routing' of signaling 5558 messages in Section 8 and GIMPS role in enforcing this. Also, 5559 opened the possibility that peer node authentication could be 5560 signaling application dependent. 5562 13. Removed old open issues on Connection Mode Encapsulation 5563 (section 8.7); added new open issues on Message Routing (old 5564 Section 9.3 of version -05, later moved to Section 3.3) and 5565 Datagram Mode congestion control. 5567 14. Added this change history. 5569 Authors' Addresses 5571 Henning Schulzrinne 5572 Columbia University 5573 Department of Computer Science 5574 450 Computer Science Building 5575 New York, NY 10027 5576 US 5578 Phone: +1 212 939 7042 5579 Email: hgs+nsis@cs.columbia.edu 5580 URI: http://www.cs.columbia.edu 5582 Robert Hancock 5583 Siemens/Roke Manor Research 5584 Old Salisbury Lane 5585 Romsey, Hampshire SO51 0ZN 5586 UK 5588 Email: robert.hancock@roke.co.uk 5589 URI: http://www.roke.co.uk 5591 Intellectual Property Statement 5593 The IETF takes no position regarding the validity or scope of any 5594 Intellectual Property Rights or other rights that might be claimed to 5595 pertain to the implementation or use of the technology described in 5596 this document or the extent to which any license under such rights 5597 might or might not be available; nor does it represent that it has 5598 made any independent effort to identify any such rights. Information 5599 on the procedures with respect to rights in RFC documents can be 5600 found in BCP 78 and BCP 79. 5602 Copies of IPR disclosures made to the IETF Secretariat and any 5603 assurances of licenses to be made available, or the result of an 5604 attempt made to obtain a general license or permission for the use of 5605 such proprietary rights by implementers or users of this 5606 specification can be obtained from the IETF on-line IPR repository at 5607 http://www.ietf.org/ipr. 5609 The IETF invites any interested party to bring to its attention any 5610 copyrights, patents or patent applications, or other proprietary 5611 rights that may cover technology that may be required to implement 5612 this standard. Please address the information to the IETF at 5613 ietf-ipr@ietf.org. 5615 Disclaimer of Validity 5617 This document and the information contained herein are provided on an 5618 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5619 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 5620 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 5621 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 5622 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5623 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5625 Copyright Statement 5627 Copyright (C) The Internet Society (2005). This document is subject 5628 to the rights, licenses and restrictions contained in BCP 78, and 5629 except as set forth therein, the authors retain all their rights. 5631 Acknowledgment 5633 Funding for the RFC Editor function is currently provided by the 5634 Internet Society.