idnits 2.17.1 draft-ietf-nsis-ntlp-06.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 4315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4299. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4305. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (May 17, 2005) is 6918 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 224 -- Looks like a reference, but probably isn't: 'Flow' on line 236 == Unused Reference: '1' is defined on line 3481, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 3489, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 3512, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 3531, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 3539, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 3553, 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. '5') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2960 (ref. '6') (Obsoleted by RFC 4960) == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-11 == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-icmp-v3-06 -- Possible downref: Normative reference to a draft: ref. '8' -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '10') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '12') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. '14') (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '19') (Obsoleted by RFC 5389) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-06 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-06 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-02 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-ro-sec-02 == Outdated reference: A later version (-04) exists of draft-bound-dstm-exp-02 == Outdated reference: A later version (-02) exists of draft-stiemerling-nsis-natfw-mrm-01 Summary: 7 errors (**), 0 flaws (~~), 16 warnings (==), 14 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: November 18, 2005 R. Hancock 5 Siemens/RMR 6 May 17, 2005 8 GIMPS: General Internet Messaging Protocol for Signaling 9 draft-ietf-nsis-ntlp-06 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 November 18, 2005. 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 Messaging Protocol for Signaling (GIMPS), which provides a universal 47 service for diverse signaling applications. GIMPS does not handle 48 signaling application state itself, but manages its own internal 49 state and the configuration of the underlying transport and security 50 protocols to enable the transfer of messages in both directions along 51 the flow path. The combination of GIMPS and the lower layer 52 transport and security protocols provides a solution for the base 53 protocol 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 . . . . . . . . . . . . . . . . . 11 64 3.4 Signalling Sessions . . . . . . . . . . . . . . . . . . . 12 65 3.5 Example of Operation . . . . . . . . . . . . . . . . . . . 13 66 4. GIMPS Processing Overview . . . . . . . . . . . . . . . . . 16 67 4.1 GIMPS Service Interface . . . . . . . . . . . . . . . . . 16 68 4.2 GIMPS State . . . . . . . . . . . . . . . . . . . . . . . 17 69 4.3 Basic Message Processing . . . . . . . . . . . . . . . . . 19 70 4.4 Routing State and Messaging Association Maintenance . . . 24 71 5. Message Formats and Transport . . . . . . . . . . . . . . . 30 72 5.1 GIMPS Messages . . . . . . . . . . . . . . . . . . . . . . 30 73 5.2 Information Elements . . . . . . . . . . . . . . . . . . . 32 74 5.3 Datagram Mode Transport . . . . . . . . . . . . . . . . . 35 75 5.4 Connection Mode Transport . . . . . . . . . . . . . . . . 39 76 5.5 Message Type/Encapsulation Relationships . . . . . . . . . 41 77 5.6 Messaging Association Negotiation . . . . . . . . . . . . 42 78 5.7 Specific Message Routing Methods . . . . . . . . . . . . . 44 79 6. Formal Protocol Specification . . . . . . . . . . . . . . . 47 80 6.1 Node Processing . . . . . . . . . . . . . . . . . . . . . 48 81 6.2 Query Node Processing . . . . . . . . . . . . . . . . . . 49 82 6.3 Responder Node Processing . . . . . . . . . . . . . . . . 50 83 6.4 Messaging Association Processing . . . . . . . . . . . . . 51 84 7. Advanced Protocol Features . . . . . . . . . . . . . . . . . 52 85 7.1 Route Changes and Local Repair . . . . . . . . . . . . . . 52 86 7.2 Policy-Based Forwarding and Flow Wildcarding . . . . . . . 58 87 7.3 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 58 88 7.4 Interaction with IP Tunnelling . . . . . . . . . . . . . . 60 89 7.5 IPv4-IPv6 Transition and Interworking . . . . . . . . . . 61 90 8. Security Considerations . . . . . . . . . . . . . . . . . . 63 91 8.1 Message Confidentiality and Integrity . . . . . . . . . . 63 92 8.2 Peer Node Authentication . . . . . . . . . . . . . . . . . 64 93 8.3 Routing State Integrity . . . . . . . . . . . . . . . . . 64 94 8.4 Denial of Service Prevention . . . . . . . . . . . . . . . 66 95 8.5 Summary of Requirements on Cookie Mechanisms . . . . . . . 67 96 8.6 Residual Threats . . . . . . . . . . . . . . . . . . . . . 68 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 70 99 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 72 100 10.1 Additional Discovery Mechanisms . . . . . . . . . . . . 72 101 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 73 102 11.1 Changes In Version -06 . . . . . . . . . . . . . . . . . 73 103 11.2 Changes In Version -05 . . . . . . . . . . . . . . . . . 74 104 11.3 Changes In Version -04 . . . . . . . . . . . . . . . . . 75 105 11.4 Changes In Version -03 . . . . . . . . . . . . . . . . . 76 106 11.5 Changes In Version -02 . . . . . . . . . . . . . . . . . 77 107 11.6 Changes In Version -01 . . . . . . . . . . . . . . . . . 78 108 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 109 12.1 Normative References . . . . . . . . . . . . . . . . . . 81 110 12.2 Informative References . . . . . . . . . . . . . . . . . 81 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 83 112 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84 113 B. Example Message Routing State Table . . . . . . . . . . . . 85 114 C. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . 86 115 C.1 General GIMPS Formatting Guidelines . . . . . . . . . . . 86 116 C.2 The GIMPS Common Header . . . . . . . . . . . . . . . . . 86 117 C.3 General Object Characteristics . . . . . . . . . . . . . . 87 118 C.4 GIMPS TLV Objects . . . . . . . . . . . . . . . . . . . . 88 119 D. API between GIMPS and NSLP . . . . . . . . . . . . . . . . . 95 120 D.1 API Concepts . . . . . . . . . . . . . . . . . . . . . . . 95 121 D.2 SendMessage . . . . . . . . . . . . . . . . . . . . . . . 95 122 D.3 RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 97 123 D.4 MessageStatus . . . . . . . . . . . . . . . . . . . . . . 98 124 D.5 NetworkNotification . . . . . . . . . . . . . . . . . . . 98 125 D.6 SetStateLifetime . . . . . . . . . . . . . . . . . . . . . 99 126 D.7 InvalidateRoutingState . . . . . . . . . . . . . . . . . . 99 127 Intellectual Property and Copyright Statements . . . . . . . 100 129 1. Introduction 131 Signaling involves the manipulation of state held in network 132 elements. 'Manipulation' could mean setting up, modifying and 133 tearing down state; or it could simply mean the monitoring of state 134 which is managed by other mechanisms. 136 This specification concentrates on "path-coupled" signaling, which 137 involves network elements which are located on the path taken by a 138 particular data flow, possibly including but not limited to the flow 139 endpoints. Indeed, there are almost always more than two 140 participants in a path-coupled-signaling session, although there is 141 no need for every node on the path to participate. Path-coupled 142 signaling thus excludes end-to-end higher-layer application signaling 143 (except as a degenerate case) such as ISUP (telephony signaling for 144 Signaling System #7) messages being transported by SCTP between two 145 nodes. 147 In the context of path-coupled signaling, examples of state 148 management include network resource allocation (for "resource 149 reservation"), firewall configuration, and state used in active 150 networking; examples of state monitoring are the discovery of 151 instantaneous path properties (such as available bandwidth, or 152 cumulative queuing delay). Each of these different uses of path- 153 coupled signaling is referred to as a signaling application. 155 Every signaling application requires a set of state management rules, 156 as well as protocol support to exchange messages along the data path. 157 Several aspects of this protocol support are common to all or a large 158 number of signaling applications, and hence can be developed as a 159 common protocol. The NSIS framework given in [20] provides a 160 rationale for a function split between the common and application 161 specific protocols, and gives outline requirements for the former, 162 the 'NSIS Transport Layer Protocol' (NTLP). 164 This specification provides a concrete solution for the NTLP. It is 165 based on the use of existing transport and security protocols under a 166 common messaging layer, the General Internet Messaging Protocol for 167 Signaling (GIMPS). GIMPS does not handle signaling application state 168 itself; in that crucial respect, it differs from application 169 signaling protocols such as SIP, RTSP, and the control component of 170 FTP. Instead, GIMPS manages its own internal state and the 171 configuration of the underlying transport and security protocols to 172 ensure the transfer of signaling messages on behalf of signaling 173 applications in both directions along the flow path. 175 1.1 Restrictions on Scope 177 This section briefly lists some important restrictions on GIMPS 178 applicability and functionality. In some cases, these are implicit 179 consequences of the functionality split developed in the NSIS 180 framework; in others, they are restrictions on the types of scenario 181 in which GIMPS can operate correctly. 183 Flow splitting: In some cases, e.g. where packet-level load sharing 184 has been implemented, the path taken by a single flow in the 185 network may not be well defined. If this is the case, GIMPS 186 cannot route signaling meaningfully. (In some circumstances, 187 GIMPS implementations could detect this condition, but even this 188 cannot be guaranteed.) 190 Multicast: GIMPS does not handle multicast flows. This includes 191 'classical' IP multicast and any of the 'small group multicast' 192 schemes recently proposed. 194 2. Requirements Notation and Terminology 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in [2]. 200 The terminology used in this specification is fully defined in this 201 section. The basic entities relevant at the GIMPS level are shown in 202 Figure 1. 204 Source GIMPS (adjacent) peer nodes Destination 206 IP address IP addresses = Signaling IP address 207 = Flow Source/Destination Addresses = Flow 208 Source (depending on signaling direction) Destination 209 Address | | Address 210 V V 211 +--------+ +------+ Data Flow +------+ +--------+ 212 | Flow |-----------|------|-------------|------|-------->| Flow | 213 | Sender | | | | | |Receiver| 214 +--------+ |GIMPS |============>|GIMPS | +--------+ 215 | Node |<============| Node | 216 +------+ Signaling +------+ 217 GN1 Flow GN2 219 >>>>>>>>>>>>>>>>> = Downstream direction 220 <<<<<<<<<<<<<<<<< = Upstream direction 222 Figure 1: Basic Terminology 224 [Data] Flow: A set of packets identified by some fixed combination of 225 header fields. Flows are unidirectional (a bidirectional 226 communication is considered a pair of unidirectional flows). 228 Session: A single application layer flow of information for which 229 some state information is to be manipulated or monitored. See 230 Section 3.4 for further detailed discussion. 232 [Flow] Sender: The node in the network which is the source of the 233 packets in a flow. Could be a host, or a router (e.g. if the flow 234 is actually an aggregate). 236 [Flow] Receiver: The node in the network which is the sink for the 237 packets in a flow. 239 Downstream: In the same direction as the data flow. 241 Upstream: In the opposite direction to the data flow. 243 GIMPS Node: Any node along the data path supporting GIMPS (regardless 244 of what signaling applications it supports). 246 Adjacent Peer: The next GIMPS node along the data path, in the 247 upstream or downstream direction. Whether two nodes are adjacent 248 is determined implicitly by the GIMPS peer discovery mechanisms; 249 it is possible for adjacencies to 'skip over' intermediate GIMPS 250 nodes if it can be determined that they have no interest in the 251 signaling messages being exchanged. 253 Datagram Mode: A mode of sending GIMPS messages between nodes without 254 using any transport layer state or security protection. Datagram 255 mode uses UDP encapsulation, with IP addresses derived either from 256 the flow definition or previously discovered adjacency 257 information. 259 Connection Mode: A mode of sending GIMPS messages directly between 260 nodes using point to point "messaging associations" (see below). 261 Connection mode allows the re-use of existing transport and 262 security protocols where such functionality is required. 264 Messaging Association: A single connection between two explicitly 265 identified GIMPS adjacent peers, i.e. between a given signaling 266 source and destination address. A messaging association may use a 267 specific transport protocol and known ports. If security 268 protection is required, it may use a specific network layer 269 security association, or use a transport layer security 270 association internally. A messaging association is bidirectional; 271 signaling messages can be sent over it in either direction, and 272 can refer to flows of either direction. 274 Message Routing Method: Even in the path-coupled case, there can be 275 different algorithms for discovering the route that signaling 276 messages should take. These are referred to as message routing 277 methods, and GIMPS supports alternatives within a common protocol 278 framework. See Section 3.3. 280 Transfer Attributes: A description of the requirements which a 281 signaling application has for the delivery of a particular 282 message; for example, whether the message should be delivered 283 reliably. See Section 4.1.2. 285 3. Design Overview 287 3.1 Overall Design Approach 289 The generic requirements identified in the NSIS framework [20] for 290 transport of path-coupled signaling messages are essentially two- 291 fold: 293 "Routing": Determine how to reach the adjacent signaling node along 294 each direction of the data path (the GIMPS peer), and if necessary 295 explicitly establish addressing and identity information about 296 that peer; 298 "Transport": Deliver the signaling information to that peer. 300 To meet the routing requirement, one possibility is for the node to 301 use local routing state information to determine the identity of the 302 GIMPS peer explicitly. GIMPS defines a 3-way handshake (Query/ 303 Response/optional Confirm) which sets up the necessary routing state 304 between adjacent peers during which signalling application data can 305 also be exchanged; the Query message is encapsulated in a special 306 way, depending on the message routing method, in order to probe the 307 network infrastructure so that the correct peer will intercept it. 308 If the routing state does not exist, it may be possible for GIMPS to 309 send a message anyway, with the same encapsulation as used for a 310 Query message. 312 Once the routing decision has been made, the node has to select a 313 mechanism for transport of the message to the peer. GIMPS divides 314 the transport problems into two categories, the easy and the 315 difficult. It handles the easy cases internally, and uses well- 316 understood transport protocols for the harder cases. Here, with 317 details discussed later, "easy" messages are those that are sized 318 well below the lowest MTU along a path, are infrequent enough not to 319 cause concerns about congestion and flow control, and do not need 320 security protection or guaranteed delivery. 322 In [20] all of these routing and transport requirements are assigned 323 to a single notional protocol, the 'NSIS Transport Layer Protocol' 324 (NTLP). The strategy of splitting the transport problem leads to a 325 layered structure for the NTLP, as a specialised GIMPS 'messaging' 326 layer running over standard transport and security protocols, as 327 shown in Figure 2. This also shows GIMPS offering its services to 328 upper layers at an abstract interface, the GIMPS API, further 329 discussed in Section 4.1. 331 ^^ +-------------+ 332 || | Signaling | 333 NSIS +------------|Application 2| 334 Signaling | Signaling +-------------+ 335 Application |Application 1| | 336 Level +-------------+ | 337 || | | 338 VV | | 339 =========|===================|===== <-- GIMPS API 340 | | 341 ^^ +------------------------------------------------+ 342 || |+-----------------------+ +--------------+ | 343 || || GIMPS | | GIMPS State | | 344 || || Encapsulation |<<<>>>| Maintenance | | 345 || |+-----------------------+ +--------------+ | 346 || |GIMPS: Messaging Layer | 347 || +------------------------------------------------+ 348 NSIS | | | | 349 Transport ............................. 350 Level . Transport Layer Security . 351 ("NTLP") ............................. 352 || | | | | 353 || +----+ +----+ +----+ +----+ 354 || |UDP | |TCP | |SCTP| |DCCP|.... 355 || +----+ +----+ +----+ +----+ 356 || | | | | 357 || ............................. 358 || . IP Layer Security . 359 || ............................. 360 VV | | | | 361 =========================|=======|=======|=======|=============== 362 | | | | 363 +----------------------------------------------+ 364 | IP | 365 +----------------------------------------------+ 367 Figure 2: Protocol Stacks for Signaling Transport 369 3.2 Modes and Messaging Associations 371 Internally, GIMPS has two modes of operation: 373 Datagram mode ('D mode') is used for small, infrequent messages with 374 modest delay constraints; it is also used at least for the Query 375 message of the 3-way handshake. 377 Connection mode ('C mode') is used for larger data objects or where 378 fast state setup in the face of packet loss is desirable, or where 379 channel security is required. 381 Datagram mode uses UDP, as this is the only encapsulation which does 382 not require per-message shared state to be maintained between the 383 peers. The connection mode can in principal use any stream or 384 message-oriented transport protocol; this specification currently 385 defines the use of TCP as the initial choice. It may employ specific 386 network layer security associations (such as IPsec), or an internal 387 transport layer security association (such as TLS). When GIMPS 388 messages are carried in connection mode, they are treated just like 389 any other traffic by intermediate routers between the GIMPS peers. 390 Indeed, it would be impossible for intermediate routers to carry out 391 any processing on the messages without terminating the transport and 392 security protocols used. Also, signaling messages are only ever 393 delivered between peers established in GIMPS-Query/Response 394 exchanges. 396 It is possible to mix these two modes along a path. This allows, for 397 example, the use of datagram mode at the edges of the network and 398 connection mode in the core of the network. Such combinations may 399 make operation more efficient for mobile endpoints, while allowing 400 multiplexing of signaling messages across shared security 401 associations and transport connections between core routers. 403 It must be understood that the routing and transport decisions made 404 by GIMPS are not independent. If the message transfer has 405 requirements that enforce the use of connection mode (e.g. the 406 message is so large that fragmentation is required), this can only be 407 used between explicitly identified nodes. In such cases, GIMPS must 408 carry out the 3-way handshake initially in datagram mode to identify 409 the peer and then set up the necessary transport connection if it 410 does not already exist. It must also be understood that the 411 signaling application does not make the D/C mode selection directly; 412 rather, this decision is made by GIMPS on the basis of the message 413 characteristics and the transfer attributes stated by the 414 application. The distinction is not visible at the GIMPS service 415 interface. 417 In general, the state associated with connection mode messaging to a 418 particular peer (signaling destination address, protocol and port 419 numbers, internal protocol configuration and state information) is 420 referred to as a "messaging association". There may be any number of 421 messaging associations between two GIMPS peers (although the usual 422 case is 0 or 1), and they are set up and torn down by management 423 actions within GIMPS itself. 425 3.3 Message Routing Methods 427 The baseline message routing functionality in GIMPS is that 428 signalling messages follow a route defined by an existing flow in the 429 network, visiting a subset of the nodes through which it passes. 430 This is the appropriate behaviour for application scenarios where the 431 purpose of the signalling is to manipulate resources for that flow. 432 However, there are scenarios for which other behaviours are 433 applicable. Two examples are: 435 Predictive Routing: Here, the intent is to send signaling along a 436 path that the data flow may or will follow in the future. 437 Possible cases are pre-installation of state on the backup path 438 that would be used in the event of a link failure; and predictive 439 installation of state on the path that will be used after a mobile 440 node handover. 442 NAT Address Reservations: This applies to the case where a node 443 behind a NAT wishes to use NSIS signaling to reserve an address 444 from which it can be reached by a sender on the other side. This 445 requires a message to be sent outbound from what will be the flow 446 receiver although no reverse routing state exists. 448 Most of the details of GIMPS operation are independent of which 449 alternative is being used. Therefore, the GIMPS design encapsulates 450 the routing-dependent details as a message routing method (MRM), and 451 allows multiple MRMs to be defined. The default is the path-coupled 452 MRM, which corresponds to the baseline functionality described above; 453 an additional possible MRM for the NAT Address Reservation case is 454 described in [29]. 456 The content of a MRM definition is as follows, using the path-coupled 457 MRM as an example: 459 o The format of the information that describes the path that the 460 signalling should take, the Message Routing Information (MRI). 461 For the path-coupled MRM, this is just the Flow Identifier (see 462 Section 5.7.1.1). The MRI includes an element to distinguish 463 between the two directions that signalling messages can take, 464 'upstream' and 'downstream'. 466 o A specification of how GIMPS should encapsulate the messages at 467 the IP level that probe the network to discover the adjacent 468 peers. A downstream encapsulation must be defined; an upstream 469 encapsulation is optional. For the path-coupled MRM, this 470 information is given in Section 5.7.1.2. 472 o A specification of what validation checks GIMPS should apply to 473 the probe messages, for example to protect against IP address 474 spoofing attacks. For the path-coupled MRM this is basically a 475 form of ingress filtering, also discussed in Section 5.7.1.2. 477 In addition, it should be noted that NAT traversal almost certainly 478 requires transformation of the MRI field in GIMPS messages (see 479 Section 7.3). Although the transformation does not have to be 480 defined as part of the standard, the impact on existing GIMPS NAT 481 implementations should be considered. 483 3.4 Signalling Sessions 485 GIMPS allows signalling applications to associate the message it 486 handles with a "signalling session". Informally, given an 487 application layer exchange of information for which some network 488 control state information is to be manipulated or monitored, the 489 corresponding signalling messages should be associated with the same 490 session by a signalling application. Signalling applications provide 491 the session identifier (SID) whenever they wish to send a message, 492 and GIMPS reports the SID when a message is received. 494 Most GIMPS processing and state information is related to the flow 495 (defined by the MRI, see above) and NSLPID. There are several 496 possible relationships between flows and sessions, for example: 498 o The simplest case is that all messages for the same flow have the 499 same SID. 501 o Messages for more than one flow may use the same SID, for example 502 because one flow is replacing another in a mobility or multihoming 503 scenario. 505 o A single flow may have messages for different SIDs, for example 506 from independently operating signalling applications. 508 Because of this range of options, GIMPS does not perform any 509 validation on how signalling applications map between flows and 510 sessions, nor does it perform any validation on the properties of the 511 SID itself. In particular, when a new SID is needed, logically it 512 should be generated by the NSLP. (NSIS implementations could provide 513 common functionality to generate SIDs for use by any NSLP, but this 514 is not part of GIMPS.) GIMPS only defines the syntax of the SID as 515 an opaque 128-bit number. 517 The SID assignment has the following impact on GIMPS processing: 519 o Messages with the same SID to be delivered reliably between the 520 same GIMPS peers are delivered in order. 522 o All other messagse are handled independently. 524 o GIMPS identifies routing state (upstream and downstream peer) by 525 the triplet (MRI, NSLPID, SID). 527 Strictly, the routing state should not depend on the SID. However, 528 if the routing state is keyed only by (MRI, NSLPID) there is a 529 trivial denial of service attack (see Section 8.3) where a malicious 530 off-path node asserts that it is the peer for a particular flow. 531 Instead, the routing state is also segregated between different SIDs, 532 which means that the attacking node can only disrupt a signalling 533 session if it can guess the corresponding SID. A consequence of this 534 design is that signalling applications should choose SIDs so that 535 they are cryptographically random, and should not use several SIDs 536 for the same flow unless strictly necessary, to avoid additional load 537 on the routing state maintenance. 539 3.5 Example of Operation 541 This section presents an example of GIMPS usage in a relatively 542 simple (in particular, NAT-free) signaling scenario, to illustrate 543 its main features. 545 Consider the case of an RSVP-like signaling application which 546 allocates resources for a single unicast flow. We will consider how 547 GIMPS transfers messages between two adjacent peers along the path, 548 GN1 and GN2 (see Figure 1). In this example, the end-to-end exchange 549 is initiated by the signaling application instance in the sender; we 550 take up the story at the point where the first message is being 551 processed (above the GIMPS layer) by the signaling application in 552 GN1. 554 1. The signaling application in GN1 determines that this message is 555 a simple description of resources that would be appropriate for 556 the flow. It determines that it has no special security or 557 transport requirements for the message, but simply that it should 558 be transferred to the next downstream signaling application peer 559 on the path that the flow will take. 561 2. The message payload is passed to the GIMPS layer in GN1, along 562 with a definition of the flow and description of the message 563 transfer attributes {unsecured, unreliable}. GIMPS determines 564 that this particular message does not require fragmentation and 565 that it has no knowledge of the next peer for this flow and 566 signaling application; however, it also determines that this 567 application is likely to require secured upstream and downstream 568 transport of large messages in the future. This determination is 569 a function of node-local policy; see Appendix D.1 for some 570 additional discussion. 572 3. GN1 therefore constructs a GIMPS-Query message, which is a UDP 573 datagram carrying the signaling application payload and 574 additional payloads at the GIMPS level to be used to initiate the 575 setup of a messaging association. The Query is injected into the 576 network, addressed towards the flow destination and with a Router 577 Alert Option included. 579 4. The Query message passes through the network towards the flow 580 receiver, and is seen by each router in turn. GIMPS-unaware 581 routers will not recognise the RAO value and will forward the 582 message unchanged; GIMPS-aware routers which do not support the 583 signaling application in question will also forward the message 584 basically unchanged, although they may need to process more of 585 the message to decide this. 587 5. The message is intercepted at GN2. The GIMPS layer identifies 588 the message as relevant to a local signaling application, and 589 passes the signaling application payload and flow description 590 upwards to it. There, the signaling application in GN2 continues 591 to process this message as in GN1 (compare step 1), and this will 592 eventually result in the message reaching the flow receiver. 594 6. In parallel, the GIMPS instance in GN2 recognises, by the fact 595 that the message is a GIMPS-Query, that GN1 is attempting to 596 discover GN2 in order to set up a messaging association for 597 future signaling for the flow. There are two basic possible 598 cases for sending back the necessary GIMPS-Response: 600 A. GN1 and GN2 already have an appropriate association. GN2 601 simply records the identity of GN1 as its upstream peer for 602 that flow and signaling application, and sends a GIMPS- 603 Response back to GN1 over the association identifying itself 604 as the peer for this flow. 606 B. No messaging association exists. GN2 sends the GIMPS- 607 Response in D mode directly to GN1, identifying itself and 608 agreeing to the association setup. The protocol exchanges 609 needed to complete this will proceed in the background. 611 7. Eventually, another signaling application message works its way 612 upstream from the receiver to GN2. This message contains a 613 description of the actual resources requested, along with 614 authorisation and other security information. The signaling 615 application in GN2 passes this payload to the GIMPS level, along 616 with the flow definition and transfer attributes {secured, 617 reliable}. 619 8. The GIMPS layer in GN2 identifies the upstream peer for this flow 620 and signaling application as GN1, and determines that it has a 621 messaging association with the appropriate properties. The 622 message is queued on the association for transmission (this may 623 mean some delay if the negotiations begun in step 6.B have not 624 yet completed). 626 Further messages can be passed in each direction in the same way. 627 The GIMPS layer in each node can in parallel carry out maintenance 628 operations such as route change detection (this can be done by 629 sending additional GIMPS-Query messages, see Section 7.1 for more 630 details). 632 It should be understood that several of these details of GIMPS 633 operations can be varied, either by local policy or according to 634 signaling application requirements. The authoritative details are 635 contained in the remainder of this document. 637 4. GIMPS Processing Overview 639 This section defines the basic structure and operation of GIMPS. 640 Section 4.1 describes the way in which GIMPS interacts with (local) 641 signaling applications in the form of an abstract service interface. 642 Section 4.2 describes the per-flow and per-peer state that GIMPS 643 maintains for the purpose of transferring messages. Section 4.3 644 describes how messages are processed in the case where any necessary 645 messaging associations and routing state already exist; this includes 646 the simple scenario of pure datagram mode operation, where no 647 messaging associations are necessary in the first place. Finally, 648 Section 4.4 describes how routing state and messaging associations 649 are created and managed. 651 4.1 GIMPS Service Interface 653 This section defines the service interface that GIMPS presents to 654 signaling applications in terms of abstract properties of the message 655 transfer. Note that the same service interface is presented at every 656 GIMPS node; however, applications may invoke it differently at 657 different nodes (e.g. depending on local policy). In addition, the 658 service interface is defined independently of any specific transport 659 protocol, or even the distinction between datagram and connection 660 mode. The initial version of this specification defines how to 661 support the service interface using a connection mode based on TCP; 662 if additional transport protocol support is added, this will support 663 the same interface and so be invisible to applications (except as a 664 possible performance improvement). A more detailed description of 665 this service interface is given in Appendix D. 667 4.1.1 Message Handling 669 Fundamentally, GIMPS provides a simple message-by-message transfer 670 service for use by signaling applications: individual messages are 671 sent, and individual messages are received. At the service 672 interface, the signalling application payload (which is opaque to 673 GIMPS) is accompanied by control information expressing the 674 application's requirements about how the message should be routed, 675 and the application also provides the session identifier (see 676 Section 3.4). Additional message transfer attributes control the 677 specific transport and security properties that the signaling 678 application desires for the message. 680 The distinction between GIMPS connection and datagram modes is not 681 visible at the service interface. In addition, the invocation of 682 GIMPS functionality to handle fragmentation and reassembly, bundling 683 together of small messages (for efficiency), and congestion control 684 is not directly visible at the service interface; GIMPS will take 685 whatever action is necessary based on the properties of the messages 686 and local node state. 688 4.1.2 Message Transfer Attributes 690 Message transfer attributes are used to define certain performance 691 and security related aspects of message processing. The attributes 692 available are as follows: 694 Reliability: This attribute may be 'true' or 'false'. For the case 695 'true', messages will be delivered to the signaling application in 696 the peer exactly once or not at all; if there is a chance that the 697 message was not delivered, an error will be indicated to the local 698 signaling application identifying the routing information for the 699 message in question. For the case 'false', a message may be 700 delivered, once, several times or not at all, with no error 701 indications in any case. 703 Security: This attribute defines the security properties that the 704 signaling application requires for the message, including the type 705 of protection required, and what authenticated identities should 706 be used for the signaling source and destination. This 707 information maps onto the corresponding properties of the security 708 associations established between the peers in connection mode. It 709 can be specified explicitly by the signaling application, or 710 reported by GIMPS to the signaling application (either on 711 receiving a message, or just before sending a message but after 712 configuring or selecting the messaging association to be used for 713 it). This attribute can also be used to convey information about 714 any address validation carried out by GIMPS (for example, whether 715 a return routability check has been carried out). Further details 716 are discussed in Appendix D. 718 Local Processing: An NSLP may provide hints to GIMPS to enable more 719 efficient or appropriate processing. For example, the NSLP may 720 select a priority from a range of locally defined values to 721 influence the sequence in which messages leave a node. Any 722 priority mechanism must respect the ordering requirements for 723 reliable messages within a session, and priority values are not 724 carried in the protocol or available at the signaling peer or 725 intermediate nodes. An NSLP may also indicate that reverse path 726 routing state will not be needed for this flow, to inhibit the 727 node requesting its downstream peer to create it. 729 4.2 GIMPS State 730 4.2.1 Message Routing State 732 For each flow, the GIMPS layer can maintain message routing state to 733 manage the processing of outgoing messages. This state is 734 conceptually organised into a table with the following structure. 736 The primary key (index) for the table is the combination of the 737 information about how the message is to be routed, the session being 738 signalled for, and the signaling application itself: 740 Message Routing Information (MRI): This defines the method to be used 741 to route the message, the direction in which to send the message, 742 and any associated addressing information; see Section 3.3. 744 Session Identification (SID): The signalling session with which this 745 message should be associated; see Section 3.4. 747 Signaling Application Identification (NSLPID): This is an IANA 748 assigned identifier of the signaling application which is 749 generating messages for this flow. The inclusion of this 750 identifier allows the routing state to be different for different 751 signaling applications (e.g. because of different adjacencies). 753 The information for a given key consists of two items: the routing 754 state to reach the upstream and the downstream peer, with respect to 755 the MRI in each case. The routing state includes information about 756 the peer identity (see Section 4.4.2), and a UDP port number (for 757 datagram mode) or a reference to one or more messaging associations 758 (for connection mode). All of this information is learned from prior 759 GIMPS exchanges. 761 It is also possible for the state information for either direction to 762 be null. There are several possible cases: 764 o The signaling application has indicated that no messages will 765 actually be sent in that direction. 767 o The node is a flow endpoint, so there can be no signaling peer in 768 one or other direction. 770 o The node is the endpoint of the signalling path (for example, 771 because it is acting as a proxy, or because it has determined 772 explicitly that there are no further signalling nodes in that 773 direction). 775 o The node can use other techniques to route the message. For 776 example, it can encapsulate it the same way as a Query message and 777 rely on the peer to intercept it. 779 Each item of routing state has an associated validity timer for how 780 long it can be considered accurate; when this timer expires, it is 781 purged if it has not been refreshed. Installation and maintenance of 782 routing state is described in more detail in Section 4.4. 784 Note also that the routing state is described as a table of flows, 785 but that there is no implied constraint on how the information is 786 stored. However, in general, and especially if GIMPS peers are 787 several IP hops away, there is no way to identify the correct 788 downstream peer for a flow and signaling application from the local 789 forwarding table using prefix matching, and the same applies always 790 to upstream peer state because of the possibility of asymmetric 791 routing: per-flow state has to be stored, just as for RSVP [9]. 793 4.2.2 Messaging Association State 795 The per-flow message routing state is not the only state stored by 796 GIMPS. There is also the state required to manage the messaging 797 associations. Since these associations are typically per-peer rather 798 than per-flow, they are stored in a separate table, including the 799 following information: 801 o messages pending transmission while an association is being 802 established; 804 o a timer for how long since the peer re-stated its desire to keep 805 the association open (see Section 4.4.3). 807 In addition, per-association state is held in the messaging 808 association protocols themselves. However, the details of this state 809 are not directly visible to GIMPS, and they do not affect the rest of 810 the protocol description. 812 4.3 Basic Message Processing 814 This section describes how signaling application messages are 815 processed in the case where any necessary messaging associations and 816 routing state are already in place. The description is divided into 817 several parts. Firstly, message reception, local processing and 818 message transmission are described for the case where the node 819 handles the NSLPID in the message. Secondly, the case where the 820 message is forwarded directly in the IP or GIMPS layer (because there 821 is no matching signaling application on the node) is given. An 822 overview is given in Figure 3. 824 +---------------------------------------------------------+ 825 | >> Signaling Application Processing >> | 826 | | 827 +--------^---------------------------------------V--------+ 828 ^ V 829 ^ NSLP Payloads V 830 ^ V 831 +--------^---------------------------------------V--------+ 832 | >> GIMPS >> | 833 | ^ ^ ^ Processing V V V | 834 +--x-----------N--Q---------------------Q--N-----------x--+ 835 x N Q Q N x 836 x N Q>>>>>>>>>>>>>>>>>>>>>Q N x 837 x N Q Bypass at Q N x 838 +--x-----+ +--N--Q--+ GIMPS level +--Q--N--+ +-----x--+ 839 | C-mode | | D-mode | | D-mode | | C-mode | 840 |Handling| |Handling| |Handling| |Handling| 841 +--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+ 842 x N Q Q N x 843 x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x 844 x N Q Bypass at Q N x 845 +--x--N--+ +-----Q--+ router +--Q-----+ +--N--x--+ 846 |IP Host | | RAO | alert level | RAO | |IP Host | 847 |Handling| |Handling| |Handling| |Handling| 848 +--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+ 849 x N Q Q N x 850 +--x--N-----------Q--+ +--Q-----------N--x--+ 851 | IP Layer | | IP Layer | 852 | (Receive Side) | | (Transmit Side) | 853 +--x--N-----------Q--+ +--Q-----------N--x--+ 854 x N Q Q N x 855 x N Q Q N x 856 x N Q Q N x 858 NNNNNNNNNNNNNN = 'Normal' datagram mode messages 859 QQQQQQQQQQQQQQ = Datagram mode messages which 860 are Queries or likewise encapsulated 861 xxxxxxxxxxxxxx = connection mode messages 862 RAO = Router Alert Option 864 Figure 3: Message Paths through a GIMPS Node 866 4.3.1 Message Reception 868 Messages can be received in connection or datagram mode, and in the 869 latter case with two types of message encapsulation. 871 Reception in connection mode is simple: incoming packets undergo the 872 security and transport treatment associated with the messaging 873 association, and the messaging association provides complete messages 874 to the GIMPS layer for further processing. Unless the message is 875 protected by a query/response cookie exchange (see Section 4.4), the 876 routing state table is checked to ensure that this messaging 877 association is associated with the MRI/NSLPID/SID combination given 878 in the message. 880 Reception in datagram mode depends on the message type. 'Normal' 881 messages arrive UDP encapsulated and addressed directly to the 882 receiving signaling node, at an address and port learned previously. 883 Each datagram contains a single complete message which is passed to 884 the GIMPS layer for further processing, just as in the connection 885 mode case. 887 Where GIMPS is sending messages to be intercepted by the appropriate 888 peer rather than directly addressed to it (in particular, Query 889 messages), these are UDP encapsulated with an IP router alert option. 890 Each signaling node will therefore 'see' all such messages. The case 891 where the NSLPID does not match a local signaling application is 892 considered below in Section 4.3.4; otherwise, it is passed up to the 893 GIMPS layer for further processing as in the other cases. 895 4.3.2 Local Processing 897 Once a message has been received, by any method, it is processed 898 locally within the GIMPS layer. The GIMPS processing to be done 899 depends on the message type and payloads carried; most of the GIMPS- 900 internal payloads are associated with state maintenance and are 901 covered in Section 4.4. There is also a hop count to prevent message 902 looping, see Section 4.3.4. 904 The remainder of the GIMPS message consists of an NSLP payload. This 905 is delivered locally to the signaling application identified at the 906 GIMPS level; the format of the NSLP payload is not constrained by 907 GIMPS, and the content is not interpreted. 909 Signaling applications can generate their messages for transmission, 910 either asynchronously, or in response to an input message, and GIMPS 911 can also generate messages autonomously. Regardless of the source, 912 outgoing messages are passed downwards for message transmission. 914 4.3.3 Message Transmission 916 When a message is available for transmission, GIMPS uses internal 917 policy and the stored routing state to determine how to handle it. 918 The following processing applies equally to locally generated 919 messages and messages forwarded from within the GIMPS or signaling 920 application levels. 922 The main decision is whether the message must be sent in connection 923 mode or datagram mode. Reasons for using the former could be: 925 o NSLP requirements: for example, the signaling application has 926 requested channel secured delivery, or reliable delivery; 928 o protocol specification: for example, this document specifies that 929 a message that requires fragmentation MUST be sent over a 930 messaging association; 932 o local GIMPS policy: for example, a node may prefer to send 933 messages over a messaging association to benefit from adaptive 934 congestion control. 936 In principle, as well as determining that some messaging association 937 must be used, GIMPS could select between a set of alternatives, e.g. 938 for load sharing or because different messaging associations provide 939 different transport or security attributes. 941 If the use of a messaging association is selected, the message is 942 queued on the association found from the routing state table, and 943 further output processing is carried out according to the details of 944 the protocol stacks used. If no appropriate association exists, the 945 message is queued while one is created (see Section 4.4). If no 946 association can be created, this is an error condition, and should be 947 indicated back to the local NSLP. 949 If a messaging association is not required, the message is sent in 950 datagram mode. The processing in this case depends on the message 951 type and whether routing state exists or not. 953 o If the message is not a Query, and routing state exists, it is UDP 954 encapsulated and sent directly to the address from the routing 955 state table. 957 o If the message is a Query, then it is UDP encapsulated with IP 958 address and router alert option determined from the MRI and NSLPID 959 (further details depend on the message routing method). 961 o If no routing state exists, GIMPS can attempt to use the same IP/ 962 UDP encapsulation as in the Query case. If this is not possible 963 (e.g. because the encapsulation algorithm for the message routing 964 method is only defined valid for one message direction), then this 965 is an error condition which is reported back to the local NSLP. 967 4.3.4 Bypass Forwarding 969 A node may have to handle messages for which it has no signaling 970 application corresponding to the message NSLPID. There are several 971 possible cases depending mainly on the RAO setting (see Section 5.3.3 972 for more details): 974 1. A datagram mode message contains an RAO value which is relevant 975 to NSIS but not to the specific node, but the IP layer is unable 976 to recognise whether it needs to be passed to GIMPS for further 977 processing or whether the packet should be forwarded just like a 978 normal IP datagram. 980 2. A datagram mode message contains an RAO value which is relevant 981 to the node, but the specific signaling application for the 982 actual NSLPID in the message is not processed there. 984 3. A message is delivered directly to the node for which there is no 985 corresponding signaling application. (According to the rules of 986 the current specification, this should never happen. However, 987 future versions might find a use for such a feature.) 989 +-------------+-------------+-------------------+-------------------+ 990 | Match RAO? | Match | IP TTL Handling | GHC Handling | 991 | | NSLPID? | | | 992 +-------------+-------------+-------------------+-------------------+ 993 | No | N/A (NSLPID | Decrement; | Ignore | 994 | | not | forward message | | 995 | | examined) | | | 996 | | | | | 997 | Yes | No | Decrement; | Decremented | 998 | | | forward message | | 999 | | | | | 1000 | Message | No | Reset | Decrement and | 1001 | directly | | | forward at GIMPS | 1002 | addressed | | | level (not | 1003 | | | | possible in | 1004 | | | | current | 1005 | | | | specification) | 1006 | | | | | 1007 | Yes, or | Yes | Locally delivered | N/A (ignored) | 1008 | message | | | | 1009 | directly | | | | 1010 | addressed | | | | 1011 +-------------+-------------+-------------------+-------------------+ 1013 In all cases, the role of GIMPS is to forward the message 1014 essentially unchanged. However, a GIMPS implementation must ensure 1015 that the IP TTL field and GIMPS hop count are managed correctly to 1016 prevent message looping, and this should be done consistently 1017 independently of whether the processing (e.g. for case (1)) takes 1018 place on the fast path or in GIMPS-specific code. The rules are that 1019 in cases (1) and (2), the IP TTL is decremented just as if the 1020 message was a normal IP forwarded packet; in cases (2) and (3) the 1021 GIMPS hop count is decremented as in the case of normal input 1022 processing. These rules are summarised in the table above. 1024 4.4 Routing State and Messaging Association Maintenance 1026 The main responsibility of GIMPS is to manage the routing state and 1027 messaging associations which are used in the basic message processing 1028 described above. Routing state is installed and maintained by 1029 specific GIMPS messages. Messaging associations are dependent on the 1030 existence of routing state, but are actually set up by the normal 1031 procedures of the transport and security protocols that comprise 1032 them. Timers control routing state and messaging association refresh 1033 and expiration. 1035 There are two different cases for state installation and refresh: 1037 1. Where routing state is being discovered or a new association is 1038 to be established; and 1040 2. Where an existing association can be re-used, including the case 1041 where routing state for the flow is being refreshed. 1043 These cases are now considered in turn, along with the case of 1044 general management procedures. 1046 4.4.1 State Setup 1048 The complete sequence of possible messages for state setup between 1049 adjacent peers is shown in Figure 4 and described in detail in the 1050 following text. 1052 The initial message in any routing state maintenance operation is a 1053 GIMPS-Query message, sent from the querying node and intercepted at 1054 the responding node. This message has addressing and other 1055 identifiers appropriate for the flow and signaling application that 1056 state maintenance is being done for, addressing information about the 1057 node itself, and it is allowed to contain an NSLP payload. The 1058 querying node also includes additional payloads: a Query Cookie, and 1059 optionally a proposal for possible messaging association protocol 1060 stacks. The role of the cookies in this and subsequent messages is 1061 to protect against certain denial of service attacks and to correlate 1062 the various events in the message sequence. 1064 +----------+ +----------+ 1065 | Querying | |Responding| 1066 | Node | | Node | 1067 +----------+ +----------+ 1068 GIMPS-Query 1069 ----------------------> ............. 1070 Router Alert Option . Routing . 1071 MRI/SID/NSLPID . state . 1072 Q-Node Network Layer Info . installed . 1073 Query Cookie . at . 1074 [Q-Node Stack-Proposal . R-node(1) . 1075 Q-Node Stack-Config Data] ............. 1076 [NSLP Payload] 1078 ...................................... 1079 . The responder can use an existing . 1080 . messaging association if available . 1081 . from here onwards to short-circuit . 1082 . messaging association setup . 1083 ...................................... 1085 GIMPS-Response 1086 ............. <---------------------- 1087 . Routing . MRI/SID/NSLPID 1088 . state . R-Node Network Layer Info (D Mode only) 1089 . installed . Query cookie 1090 . at . [R-Node Stack-Proposal 1091 . Q-Node . R-Node Stack-Config Data] 1092 ............. [Responder Cookie] 1093 [NSLP Payload] 1095 .................................... 1096 . If a messaging association needs . 1097 . to be created, it is set up here . 1098 .................................... 1100 GIMPS-Confirm 1101 ----------------------> 1102 MRI/SID/NSLPID ............. 1103 Q-Node Network Layer Info . Routing . 1104 Responder Cookie . state . 1105 [R-Node Stack-Proposal] . installed . 1106 [NSLP Payload] . at . 1107 . R-node(2) . 1108 ............. 1110 Figure 4: Message Sequence at State Setup 1112 Reception of a GIMPS-Query triggers the generation of a GIMPS- 1113 Response message. This is a 'normally' encapsulated datagram mode 1114 message with additional payloads. It contains network layer 1115 information about the responding node, echoes the Query Cookie, and 1116 can contain an NSLP payload (possibly a response to the NSLP payload 1117 in the initial message). In case a messaging association was 1118 requested, it must also contain a Responder Cookie and counter- 1119 proposal for the messaging association protocol stacks. Otherwise, 1120 it may still include a Responder Cookie if the node's routing state 1121 setup policy requires it (see below). 1123 Setup of a new messaging association begins when peer addressing 1124 information is available and a new messaging association is actually 1125 needed. The setup has to be contemporaneous with a specific GIMPS- 1126 Query/Response exchange, because the addressing information used may 1127 have a limited lifetime (either because it depends on limited 1128 lifetime NAT bindings, or because it refers to agile destination 1129 ports for the transport protocols). The negotiation of what 1130 protocols to use for the messaging association is controlled by the 1131 Stack-Proposal and Stack-Configuration-Data information exchanged, 1132 and the processing of these objects is described in more detail in 1133 Section 5.6. With the protocol options currently defined, setup of 1134 the messaging association always starts from the Querying node, 1135 although more flexible configurations are possible within the overall 1136 GIMPS design. In any case, once set up the association itself can be 1137 used equally in both directions. 1139 The GIMPS-Confirm is the first message sent over the association and 1140 echoes the Responder Cookie and Stack Proposal from the GIMPS- 1141 Response. The former is used to allow the receiver to validate the 1142 contents of the message (see Section 8.5), and the latter is to 1143 prevent certain bidding-down attacks on messaging association 1144 security. The association can be used in the upstream direction for 1145 that flow and NSLPID after the Confirm has been received. 1147 The querying node installs the responder address as routing state 1148 information after verifying the Query Cookie in the GIMPS-Response. 1149 The responding node can install the querying address as peer state 1150 information at two points in time: 1152 1. after the receipt of the initial GIMPS-Query, or 1154 2. after a GIMPS-Confirm message containing the Responder Cookie. 1156 The precise constraints on when state information is installed are a 1157 matter of security policy considerations on prevention of denial-of- 1158 service attacks and state poisoning attacks, which are discussed 1159 further in Section 8. Because the responding node may choose to 1160 delay state installation as in case (2), the GIMPS-Confirm must 1161 contain sufficient information to allow it to be processed 1162 identically to the original Query. This places some special 1163 requirements on NAT traversal and cookie functionality, which are 1164 discussed in Section 7.3 and Section 8 respectively. 1166 4.4.2 Association Re-use 1168 It is a general design goal of GIMPS that, so far as possible, 1169 messaging associations should be re-used for multiple flows and 1170 sessions, rather than a new association set up for each. This is to 1171 ensure that the association cost scales only like the number of 1172 peers, and to avoid the latency of new association setup where 1173 possible. 1175 However, re-use requires the identification of an existing 1176 association which matches the same routing state and desired 1177 properties that would be the result of a full handshake in D-mode, 1178 and this identification must be done as reliably and securely as 1179 continuing with the full procedure. Note that this requirement is 1180 complicated by the fact that NATs may remap the node addresses in 1181 D-mode messages, and also interacts with the fact that some nodes may 1182 peer over multiple interfaces (and so with different addresses). 1184 Association re-use is controlled by the Network-Layer-Information 1185 (NLI) object, which is carried in GIMPS-Query/Confirm and optionally 1186 GIMPS-Response messages. The NLI object includes: 1188 Peer-Identity: For a given node, this is a stable quantity (interface 1189 independent) with opaque syntax. It should be chosen so as to 1190 have a high probability of uniqueness between peers. Note that 1191 there is no cryptographic protection of this identity (attempting 1192 to provide this would essentially duplicate the functionality in 1193 the messaging association security protocols). 1195 Interface-Address: This is an IP address associated with the 1196 interface through which the flow associated with the signaling is 1197 routed. This can be considered as a routable identifier through 1198 which the signaling node can be reached; further discussion is 1199 contained in Section 5.6. 1201 By default, a messaging association is associated with the NLI object 1202 that was provided by the peer in the Query/Response/Confirm at the 1203 time the association was set up. There may be more than one 1204 association for a given NLI object (e.g. with different properties). 1206 Association re-use is controlled by matching the NLI provided in a 1207 GIMPS message with those associated with existing associations. This 1208 can be done on receiving either a GIMPS-Query or GIMPS-Response (the 1209 former is more likely): 1211 o If there is a perfect match to the NLI of an existing association, 1212 that association can be re-used (provided it has the appropriate 1213 properties in other respects). This is indicated by sending the 1214 remaining messages in the handshake over that association. This 1215 will only fail (i.e. lead to re-use of an association to the 1216 'wrong' node) if signaling nodes have colliding Peer-Identities, 1217 and one is reachable at the same Interface-Address as another. 1218 (This could be done by an on-path attacker.) 1220 o In all other cases, the full handshake is executed in datagram 1221 mode as usual. There are in fact four possibilities: 1223 1. Nothing matches: this is clearly a new peer. 1225 2. Only the Peer-Identity matches: this may be either a new 1226 interface on an existing peer, or a changed address mapping 1227 behind a NAT, or an attacker attempting to hijack the Peer- 1228 Identity. These should be rare events, so the expense of a 1229 new association setup is acceptable. If the authenticated 1230 peer identities match after association setup, the two 1231 Interface-Addresses may be bound to the association. 1233 3. Only the Interface-Address matches: this is probably a new 1234 peer behind the same NAT as an existing one. A new 1235 association setup is required. 1237 4. The full NLI object matches: this is a degenerate case, where 1238 one node recognises an existing peer, but wishes to allow the 1239 option to set up a new association in any case (for example to 1240 create an association with different transport or security 1241 properties). 1243 4.4.3 State Maintenance Procedures 1245 Refresh and expiration of all types of state is controlled by timers. 1247 Each item of routing state expires after a validity lifetime which is 1248 negotiated during the Query/Response/Confirm handshake. The NLI 1249 object in the Query contains a proposal for the lifetime value, and 1250 the NLI in the Response contains the value the Responding node 1251 requires. It is the responsibility of the Querying node to generate 1252 a GIMPS-Query message before this timer expires, if it believes that 1253 the flow is still active; otherwise, the Responding node may delete 1254 the state. Receipt of the message at the Responding node will 1255 refresh peer addressing state for one direction, and receipt of a 1256 GIMPS-Response at the querying node will refresh it for the other. 1258 Unneeded messaging associations can be torn down by either end. 1259 Whether an association is needed is a combination of two factors: 1261 o local policy, which could take into account the cost of keeping 1262 the messaging association open, the level of past activity on the 1263 association, and the likelihood of future activity (e.g. if there 1264 is routing state still in place which might generate messages to 1265 use it). 1267 o whether the peer still wants the association in place. During 1268 messaging association setup, each node indicates its own MA-hold- 1269 time as part of the Stack-Configuration-Data; the node promises 1270 not to tear down the association if it has received traffic from 1271 its peer over that period. A peer which has generated no traffic 1272 but still wants the association retained can use a special 'null' 1273 message (GIMPS-MA-Hello) to indicate the fact. 1275 Messaging associations can always be set up on demand, and messaging 1276 association status is not made directly visible outside the GIMPS 1277 layer. Therefore, even if GIMPS tears down and later re-establishes 1278 a messaging association, signaling applications cannot distinguish 1279 this from the case where the association is kept permanently open. 1280 (To maintain the transport semantics described in Section 4.1, GIMPS 1281 must close transport connections carrying reliable messages 1282 gracefully or report an error condition, and must not open a new 1283 association for a given session and peer while messages on a previous 1284 association may still be outstanding.) 1286 5. Message Formats and Transport 1288 5.1 GIMPS Messages 1290 All GIMPS messages begin with a common header, which includes a 1291 version number, information about message type, signaling 1292 application, and additional control information. The remainder of 1293 the message is encoded in an RSVP-style format, i.e., as a sequence 1294 of type-length-value (TLV) objects. This subsection describes the 1295 possible GIMPS messages and their contents at a high level; a more 1296 detailed description of each information element is given in 1297 Section 5.2. 1299 The following gives the syntax of GIMPS messages in ABNF [3]. 1301 GIMPS-Message: The main messages are either one of the stages in the 1302 3-way handshake, or a simple message carrying NSLP data. Additional 1303 types are allocated for errors and messaging association keepalive. 1305 GIMPS-Message = GIMPS-Query / GIMPS-Response / 1306 GIMPS-Confirm / GIMPS-Data / 1307 GIMPS-Error / GIMPS-MA-Hello 1309 GIMPS-Query: A GIMPS-Query is always sent in datagram mode. As well 1310 as the common header, it contains certain mandatory control objects, 1311 and may contain a signaling application payload. A stack proposal 1312 and configuration data are mandatory if the message exchange relates 1313 to setup of a messaging association. 1315 GIMPS-Query = Common-Header 1316 Message-Routing-Information 1317 Session-Identification 1318 Network-Layer-Information 1319 Query-Cookie 1320 [ Stack-Proposal Stack-Configuration-Data ] 1321 [ NSLP-Data ] 1323 GIMPS-Response: A GIMPS-Response may be sent in datagram or 1324 connection mode (if a messaging association is being re-used). It 1325 echoes the MRI, SID and Query-Cookie of the Query, and in D-mode 1326 carries its own Network-Layer-Information; if the message exchange 1327 relates to setup of a messaging association (which can only take 1328 place in datagram mode), a Responder cookie is mandatory, as is its 1329 own stack proposal and configuration data. 1331 GIMPS-Response = Common-Header 1332 Message-Routing-Information 1333 Session-Identification 1334 [ Network-Layer-Information ] 1335 Query-Cookie 1336 [ Responder-Cookie 1337 [ Stack-Proposal Stack-Configuration-Data ] ] 1338 [ NSLP-Data ] 1340 GIMPS-Confirm: A GIMPS-Confirm may be sent in datagram or connection 1341 mode (if a messaging association has been re-used). It echoes the 1342 MRI, SID and Responder-Cookie of the Response; if the message 1343 exchange relates to setup of a new messaging association or reuse of 1344 an existing one (which can only take place in connection mode), the 1345 message must also echo the Stack-Proposal from the GIMPS-Response so 1346 it can be verified that this has not been tampered with. 1348 GIMPS-Confirm = Common-Header 1349 Message-Routing-Information 1350 Session-Identification 1351 Network-Layer-Information 1352 Responder-Cookie 1353 [ Stack-Proposal ] 1354 [ NSLP-Data ] 1356 GIMPS-Data: A plain data message contains no control objects, but 1357 only the MRI and SID associated with the NSLP data being transferred. 1358 Network-Layer-Information is only carried in the datagram mode case. 1360 GIMPS-Data = Common-Header 1361 Message-Routing-Information 1362 Session-Identification 1363 [ Network-Layer-Information ] 1364 NSLP-Data 1366 GIMPS-Error: A GIMPS-Error message reports a problem determined at 1367 the GIMPS level. (Errors generated by signalling applications are 1368 reported in NSLP-Data payloads and are not treated specially by 1369 GIMPS.) The message includes the MRI and SID of the message that 1370 caused the error (if these can be determined), and Network-Layer- 1371 Information if the GIMPS-Error is being sent in D-Mode. 1373 GIMPS-Error = Common-Header 1374 [ Message-Routing-Information ] 1375 [ Session-Identification ] 1376 [ Network-Layer-Information ] 1377 GIMPS-Error-Data 1379 GIMPS-MA-Hello: This message can be sent only in C-Mode to indicate 1380 that a node wishes to keep a messaging association open. It contains 1381 only the common header, with a null NSLPID. A flag can be set in the 1382 Common-Header to indicate that a reply is requested, thus allowing a 1383 node to test the liveness of the peer. 1385 GIMPS-MA-Hello = Common-Header 1387 5.2 Information Elements 1389 This section describes the content of the various information 1390 elements that can be present in each GIMPS message, both the common 1391 header, and the individual TLVs. The bit patterns are provided in 1392 Appendix C. 1394 5.2.1 The Common Header 1396 Each message begins with a fixed format common header, which contains 1397 the following information: 1399 Version: The version number of the GIMPS protocol. 1401 Length: The number of 32 bit words in the message following the 1402 common header. 1404 Signaling application identifier (NSLPID): This describes the 1405 specific signaling application, such as resource reservation or 1406 firewall control. 1408 GIMPS hop counter: A hop counter to prevent a message from looping 1409 indefinitely. 1411 Message type: The message type (Query, Response, etc.) 1413 Source addressing mode: A flag to indicate whether the IP source 1414 address of the message was set to be the signaling source address, 1415 or whether it was derived from the message routing information in 1416 the payload. 1418 Response requested: A flag to indicate that a message should be sent 1419 in response to this message. 1421 5.2.2 TLV Objects 1423 All data following the common header is encoded as a sequence of 1424 type-length-value objects. Currently, each object can occur at most 1425 once; the set of required and permitted objects is determined by the 1426 message type encapsulation. The ABNF given above fixes the order of 1427 objects within a message. 1429 Message-Routing-Information (MRI): Information sufficient to define 1430 how the signaling message should be routed through the network. 1432 Message-Routing-Information = message-routing-method 1433 method-specific-information 1435 The format of the method-specific-information depends on the 1436 message-routing-method requested by the signaling application. 1437 The MRI is essentially a read only object for GIMPS processing. 1438 It is set by the NSLP in the message sender and used by GIMPS to 1439 select the message addressing, but not otherwise modified. 1441 Session-Identification (SID): The GIMPS session identifier is a long, 1442 cryptographically random identifier chosen by the node which 1443 originates the signaling exchange. See Section 3.4. 1445 Network-Layer-Information: This object carries information about the 1446 network layer attributes of the node sending the message, 1447 including data related to the management of routing state. This 1448 includes a peer identity and IP address for the sending node. It 1449 also includes IP TTL information to allow the hop count between 1450 GIMPS peers to be measured and reported, and a validity time for 1451 the routing state. 1453 Network-Layer-Information = peer-identity 1454 interface-address 1455 RS-validity-time 1456 IP-TTL 1458 The peer-identity and interface-address are used for matching 1459 existing associations, as discussed in Section 4.4.2. Any 1460 technique may be used to generate the peer-identity, so long as it 1461 is stable. The interface-address should be a routable address 1462 where the sending node can be reached over UDP or messaging 1463 association protocols. Where this object is used in a GIMPS- 1464 Query, the interface-address should specifically be set to the 1465 address of the interface that will be used for the outbound flow, 1466 to allow its use in route change handling, see Section 7.1. The 1467 use of the RS-validity-time field is described in Section 4.4.3. 1469 The setting and interpretation of the IP-TTL field depends on the 1470 message direction (as determined from the MRI) and encapsulation. 1472 * If the message is downstream, the IP-TTL is set to the TTL that 1473 will be set in the IP header for the message (if this can be 1474 determined), or else 0. 1476 * On receiving a downstream message in datagram mode, the IP-TTL 1477 is compared to the TTL in the IP header, and the result is 1478 stored as the IP-hop-count-to-peer for the upstream peer in the 1479 routing state table for that flow. Otherwise, the field is 1480 ignored. 1482 * If the message is upstream, the IP-TTL is set to the value of 1483 the IP-hop-count-to-peer stored in the routing state table, or 1484 0 if there is no value yet stored. 1486 * On receiving an upstream message, the IP-TTL is stored as the 1487 IP-hop-count-to-peer for the downstream peer. 1489 In all cases, the TTL value reported to signaling applications is 1490 the one stored with the routing state for that flow, after it has 1491 been updated (if appropriate) from processing the message in 1492 question. 1494 Stack-Proposal: This field contains information about which 1495 combinations of transport and security protocols are proposed for 1496 use in messaging associations, and is also discussed further in 1497 Section 5.6. 1499 Stack-Proposal = *stack-profile 1501 stack-profile = *protocol-layer 1503 Each protocol-layer field identifies a protocol with a unique tag; 1504 any address-related (mutable) information associated with the 1505 protocol will be carried in a higher-layer-addressing field in the 1506 Stack-Configuration-Data TLV (see below). 1508 Stack-Configuration-Data: This object carries information about the 1509 overall configuration of a messaging association. 1511 Stack-Configuration-Data = MA-hold-time 1512 *higher-layer-addressing 1514 The MA-hold-time field indicates how long a node will hold open an 1515 inactive association; see Section 4.4.3 for more discussion. The 1516 higher-layer-addressing fields give the configuration of the 1517 protocols to be used for new messaging associations, and they are 1518 described in more detail in Section 5.6. 1520 Query-Cookie/Responder-Cookie: A Query-Cookie is contained in a 1521 GIMPS-Query message and must be echoed in a GIMPS-Response; a 1522 Response-Cookie is optional in a GIMPS-Response message, and if 1523 present must be echoed in the following GIMPS-Confirm message. 1524 Cookies are variable length (chosen by the cookie generator) and 1525 need to be designed so that a node can determine the validity of a 1526 cookie without keeping state. See Section 8.5 for further details 1527 on requirements and mechanisms for cookie generation. 1529 NSLP-Data: The NSLP payload to be delivered to the signaling 1530 application. GIMPS does not interpret the payload content. 1532 5.3 Datagram Mode Transport 1534 This section describes the various encapsulation options for datagram 1535 mode messages. Although there are several variant possibilities, 1536 depending on message type, message routing method, and local policy, 1537 the general design principle is that the sole purpose of the 1538 encapsulation is to ensure that the message is delivered to or 1539 intercepted at the correct peer. Beyond that, minimal significance 1540 is attached to the type of encapsulation or the values of addresses 1541 or ports used for it. This allows new options to be developed in the 1542 future to handle particular deployment requirements without modifying 1543 the overall protocol specification. 1545 5.3.1 Normal Encapsulation 1547 Normal encapsulation is used for all datagram mode messages where the 1548 signaling peer is already known from previous signaling. This 1549 includes Response and Confirm messages, and Data messages except if 1550 these are being sent without using local routing state. Normal 1551 encapsulation is simple: the complete set of GIMPS payloads is 1552 concatenated together with the common header, and placed in the data 1553 field of a UDP datagram. UDP checksums should be enabled. The 1554 message is IP addressed directly to the adjacent peer; the UDP port 1555 numbering should be compatible with that used on Query messages (see 1556 below), that is, the same for messages in the same direction and 1557 swapped otherwise. 1559 5.3.2 Query Encapsulation 1561 Query encapsulation is used for messages where no routing state is 1562 available or where the routing state is being refreshed, in 1563 particular for GIMPS-Query messages. Query encapsulation is similar 1564 to normal encapsulation, with changes in IP address selection, IP 1565 options, and a defined method for selecting UDP ports. 1567 In general, the IP addresses are derived from information in the MRI; 1568 the exact rules depend on the message routing method. In addition, 1569 the IP header is given a Router Alert Option to assist the peer in 1570 intercepting the message depending on the NSLPID. Router alert 1571 option value-field setting is discussed in Section 5.3.3. 1573 The source UDP port is selected by the message sender as the port at 1574 which it is prepared to receive UDP messages in reply, and a 1575 destination UDP port should be allocated by IANA. Note that GIMPS 1576 may send messages addressed as {flow sender, flow receiver} which 1577 could make their way to the flow receiver even if that receiver were 1578 GIMPS-unaware. This should be rejected (with an ICMP message) rather 1579 than delivered to the user application (which would be unable to use 1580 the source address to identify it as not being part of the normal 1581 data flow). Therefore, a "well-known" port is required. 1583 5.3.3 Intermediate Node Bypass and Router Alert Values 1585 We assume that the primary mechanism for intercepting messages is the 1586 use of the RAO. The RAO contains a 16 bit value field, within which 1587 35 values have currently been assigned by IANA. This section 1588 discusses the technical considerations to be taken into account when 1589 assigning values for use by GIMPS. 1591 The basic goal is to optimise protocol processing, i.e. to minimise 1592 the amount of slow-path processing that nodes have to carry out for 1593 messages they are not actually interested in. There are two basic 1594 reasons why a GIMPS node might wish to ignore a message: 1596 o because it is for a signaling application that the node does not 1597 process; 1599 o because even though the signaling application is present on the 1600 node, the interface on which the message arrives is only 1601 processing signaling messages at the aggregate level and not for 1602 individual flows (compare [15]). 1604 Conversely, note that a node might wish to process a number of 1605 different signaling applications. 1607 Some or all of this information can be encoded in the RAO value 1608 field, which then allows messages to be filtered on the fast path. 1609 There is a tradeoff between two approaches here, whose evaluation 1610 depends on whether the processing node is specialised or general 1611 purpose: 1613 Fine-Grained: The signaling application (including specific version) 1614 and aggregation level are directly identified in the RAO value. A 1615 specialised node which handles only a single NSLP can efficiently 1616 ignore all other messages; a general purpose node may have to 1617 match the RAO value in a message against a long list of possible 1618 values. 1620 Coarse-Grained: IANA allocates RAO values for 'popular' applications 1621 or groups of applications (such as 'All QoS Signaling 1622 Applications'). This speeds up the processing in a general 1623 purpose node, but a specialised node may have to carry out further 1624 processing on the GIMPS common header to identify the precise 1625 messages it needs to consider. 1627 These considerations imply that the RAO value should not be tied 1628 directly to the NSLPID, but should be selected for the application on 1629 broader considerations of likely deployment scenarios. Note that the 1630 exact NSLP is given in the GIMPS common header, and some 1631 implementations may still be able to process it on the fast path. 1632 The semantics of the node dropping out of the signaling path are the 1633 same however the filtering is done (see Section 4.3.4). 1635 There is a special consideration in the case of the aggregation 1636 level. In this case, whether a message should be processed depends 1637 on the network region it is in (specifically, the link it is on). 1638 There are then two basic possibilities: 1640 1. All routers have essentially the same algorithm for which 1641 messages they process, i.e. all messages at aggregation level 0. 1642 However, messages have their aggregation level incremented on 1643 entry to an aggregation region and decremented on exit. 1645 2. Router interfaces are configured to process messages only above a 1646 certain aggregation level and ignore all others. The aggregation 1647 level of a message is never changed; signaling messages for end 1648 to end flows have level 0, but signaling messages for aggregates 1649 are generated with a higher level. 1651 The first technique requires aggregating/deaggregating routers to be 1652 configured with which of their interfaces lie at which aggregation 1653 level, and also requires consistent message rewriting at these 1654 boundaries. The second technique eliminates the rewriting, but 1655 requires interior routers to be configured also. It is not clear 1656 what the right trade-off between these options is. 1658 5.3.4 Retransmission and Rate-Control 1660 Datagram mode uses UDP, and hence has no automatic reliability or 1661 congestion control capabilities. Signaling applications requiring 1662 reliability should be serviced using C-mode, which should also carry 1663 the bulk of signaling traffic. However, some form of messaging 1664 reliability is required for the GIMPS control messages themselves, as 1665 is rate control to handle retransmissions and also bursts of 1666 unreliable signaling or state setup requests from the signaling 1667 applications. 1669 GIMPS-Query messages which do not receive GIMPS-Responses should be 1670 retransmitted with a binary exponential backoff, with an initial 1671 timeout of T1 up to a maximum of T2 seconds. The values of T1 and T2 1672 may be implementation defined; default values are for further study. 1673 The value of T1 may be increased on long latency links. Note that 1674 GIMPS-Queries may go unanswered either because of message loss, or 1675 because there is no reachable GIMPS peer. Therefore, implementations 1676 must trade off reliability (large T2) against promptness of error 1677 feedback to applications (small T2). GIMPS-Responses should always 1678 be sent promptly to avoid spurious retransmissions. Retransmitted 1679 GIMPS-Queries should use different Query-Cookie values and will 1680 therefore elicit different GIMPS-Responses. If either message 1681 carries NSLP data, it may be delivered multiple times to the 1682 signaling application. 1684 Other datagram mode messages are not generally retransmitted. GIMPS- 1685 Responses do not need reliability; if they are lost, the initiating 1686 Query will eventually be resent. 1688 The case of a lost GIMPS-Confirm is more subtle. Notionally, we can 1689 distinguish between two cases: 1691 1. Where the Responding node is already prepared to store per-flow 1692 state after receiving a single (Query) message. This would 1693 include any cases where the node has NSLP data queued to send. 1694 Here, it is reasonable for the protocol to demand that the 1695 Responding node runs a retransmission timer to resend the 1696 Response message until a Confirm is received, since the node is 1697 already managing state for that flow. The problem of an 1698 amplification attack stimulated by a malicious Query should be 1699 handled by requiring the cookie mechanism to enable the node 1700 receiving the Response to discard it efficiently if it does not 1701 match a previously sent Query. 1703 2. where the responding node is not prepared to store per-flow state 1704 until receiving a properly formed Confirm message. 1706 In case (2), a retransmission timer should not be required. However, 1707 we can assume that the next signaling message will be in the 1708 direction Querying Node -> Responding Node (if there is no 'next 1709 signaling message' the fact that the Confirm has been lost is moot). 1710 In this case, the responding node will start to receive messages at 1711 the GIMPS level for a MRI/NSLP combination for which there is no 1712 stored routing state (since this state is only created on receipt of 1713 a Confirm). 1715 The consequence of this is that the error condition is detected at 1716 the Responding node when such a message arrives, without the need for 1717 a specific timer. Recovery requires a Confirm to be transmitted and 1718 successfully received. The mechanism to cause this is for the 1719 Responding node to reject the incoming message with an error "No 1720 Routing State Exists" back to the Querying node, which interprets 1721 this as caused by a lost Confirm; the Querying node needs to be able 1722 to regenerate the Confirm purely from local state (e.g. in particular 1723 it needs to remember a valid Responder Cookie). 1725 The basic rate-control requirements for datagram mode traffic are 1726 deliberately minimal. A single rate limiter applies to all traffic 1727 (for all interfaces and message types). It applies to 1728 retransmissions as well as new messages, although an implementation 1729 may choose to prioritise one over the other. When the rate limiter 1730 is imposed, datagram mode messages are queued until transmission is 1731 re-enabled, or an error condition may be indicated back to local 1732 signaling applications. The rate limiting mechanism is 1733 implementation defined, but it is recommended that a token bucket 1734 limiter as described in [8] should be used. 1736 5.4 Connection Mode Transport 1738 Encapsulation in connection mode is more complex, because of the 1739 variation in available transport functionality. This issue is 1740 treated in Section 5.4.1. The actual encapsulation is given in 1741 Section 5.4.2. 1743 5.4.1 Choice of Transport Protocol 1745 It is a general requirement of the NTLP defined in [20] that it 1746 should be able to support bundling (of small messages), fragmentation 1747 (of large messages), and message boundary delineation. Not all 1748 transport protocols natively support all these features. 1750 SCTP [6] satisfies all requirements. 1752 DCCP [7] is message based but does not provide bundling or 1753 fragmentation. Bundling can be carried out by the GIMPS layer 1754 sending multiple messages in a single datagram; because the common 1755 header includes length information (number of TLVs), the message 1756 boundaries within the datagram can be discovered during parsing. 1758 Fragmentation of GIMPS messages over multiple datagrams should be 1759 avoided, because of amplification of message loss rates that this 1760 would cause. 1762 TCP provides both bundling and fragmentation, but not message 1763 boundaries. However, the length information in the common header 1764 allows the message boundary to be discovered during parsing. 1766 The bundling together of small messages is either built into the 1767 transport protocol or can be carried out by the GIMPS layer during 1768 message construction. Either way, two approaches can be 1769 distinguished: 1771 1. As messages arrive for transmission they are gathered into a 1772 bundle until a size limit is reached or a timeout expires (cf. 1773 the Nagle algorithm of TCP or similar optional functionality in 1774 SCTP). This provides maximal efficiency at the cost of some 1775 latency. 1777 2. Messages awaiting transmission are gathered together while the 1778 node is not allowed to send them (e.g. because it is congestion 1779 controlled). 1781 The second type of bundling is always appropriate. For GIMPS, the 1782 first type is inappropriate for 'trigger' (i.e. state-changing) 1783 messages, but may be appropriate for refresh messages. These 1784 distinctions are known only to the signaling applications, but could 1785 be indicated (as an implementation issue) by setting the priority 1786 transfer attribute. 1788 It can be seen that all of these protocol options can be supported by 1789 the basic GIMPS message format already presented. GIMPS messages 1790 requiring fragmentation must be carried using a reliable transport 1791 protocol, TCP or SCTP. This specification defines only the use of 1792 TCP, but it can be seen that the other possibilities could be 1793 included without additional work on message formatting. 1795 5.4.2 Encapsulation Format 1797 The GIMPS message, consisting of common header and TLVs, is carried 1798 directly in the transport protocol (possibly incorporating transport 1799 layer security protection). Further messages can be carried in a 1800 continuous stream (for TCP), or up to the next transport layer 1801 message boundary (for SCTP/DCCP/UDP). This situation is shown in 1802 Figure 5. 1804 +---------------------------------------------+ 1805 | L2 Header | 1806 +---------------------------------------------+ 1807 | IP Header | ^ 1808 | Source address = signaling source | ^ 1809 | Destination address = signaling destination | . 1810 +---------------------------------------------+ . 1811 | L4 Header | . ^ 1812 | (Standard TCP/SCTP/DCCP/UDP header) | . ^ 1813 +---------------------------------------------+ . . 1814 | GIMPS Message | . . ^ 1815 | (Common header and TLVs as in section 5.1) | . . ^ Scope of 1816 +---------------------------------------------+ . . . security 1817 | Additional GIMPS messages, each with its | . . . protection 1818 | own common header, either as a continuous | . . . (depending 1819 | stream, or continuing to the next L4 | . . . on channel 1820 . message boundary . . . . security 1821 . . V V V mechanism 1822 . . V V V in use) 1824 Figure 5: Connection Mode Encapsulation 1826 5.5 Message Type/Encapsulation Relationships 1828 GIMPS has four message types (Query/Response/Confirm/Data) and three 1829 possible encapsulation methods (D-Mode Normal/D-Mode Query/C-Mode). 1830 For information, the allowed combinations of message type and 1831 encapsulation are given in the table below. However, it should be 1832 noted that the processing of the message at the receiver is not 1833 directly affected by the encapsulation method used, with the 1834 exception that the decapsulation process may provide additional 1835 information (e.g. translated addresses or IP hop count) which is used 1836 in the subsequent message processing. The selection of the 1837 encapsulation method is a matter for the message sender. 1839 +----------------+----------------+----------------+----------------+ 1840 | Message | D-Mode Normal | D-Mode Query | C-Mode | 1841 +----------------+----------------+----------------+----------------+ 1842 | GIMPS-Query | Never | Always | Never | 1843 | | | | | 1844 | GIMPS-Response | Unless a | Never | If a messaging | 1845 | | messaging | | association is | 1846 | | association is | | being re-used | 1847 | | being re-used | | | 1848 | | | | | 1849 | GIMPS-Confirm | Unless a | Never | If a messaging | 1850 | | messaging | | association | 1851 | | association | | has been set | 1852 | | has been set | | up or is being | 1853 | | up or is being | | re-used | 1854 | | re-used | | | 1855 | | | | | 1856 | GIMPS-Data | If routing | If no routing | If a messaging | 1857 | | state exists | state exists | association | 1858 | | for the flow | and the MRI | exists | 1859 | | but no | can be used to | | 1860 | | appropriate | derive the | | 1861 | | messaging | query | | 1862 | | association | encapsulation | | 1863 +----------------+----------------+----------------+----------------+ 1865 5.6 Messaging Association Negotiation 1867 5.6.1 Overview 1869 A key attribute of GIMPS is that it is flexible in its ability to use 1870 existing transport and security protocols. Different transport 1871 protocols may have performance attributes appropriate to different 1872 environments; different security protocols may fit appropriately with 1873 different authentication infrastructures. Even given an initial 1874 default mandatory protocol set for GIMPS, the need to support new 1875 protocols in the future cannot be ruled out, and secure feature 1876 negotation cannot be added to an existing protocol in a backwards- 1877 compatible way. Therefore, some sort of negotiation capability is 1878 required. 1880 Protocol negotiation is carried out in GIMPS-Query/Response messages, 1881 using Stack-Proposal and Stack-Configuration-Data objects. If a new 1882 messaging association is required it is then set up, followed by a 1883 GIMPS-Confirm. Messaging association re-use is achieved by short- 1884 circuiting this exchange by sending the GIMPS-Response or GIMPS- 1885 Confirm messages on an existing association (Section 4.4.2); whether 1886 to do this is a matter of local policy. If multiple associations 1887 exist, it is a matter of local policy how to distribute messages over 1888 them, subject to respecting the transfer attributes requested for 1889 each message. 1891 The end result of the negotiation is a messaging association which is 1892 a stack of protocols. Every possible protocol has the following 1893 attributes: 1895 o MA-Protocol-ID, a 1-byte IANA assigned value. 1897 o A specification of the (non-negotiable) policies about how the 1898 protocol should be used (for example, in which direction a 1899 connection should be opened). 1901 o Formats for carrying the protocol addressing and other 1902 configuration information in higher-layer-addressing information 1903 elements in the Stack-Configuration-Data object. There are 1904 different formats depending on whether the information is carried 1905 in the Query or Response (the object for a Confirm echoes the 1906 Response). 1908 A Stack-Proposal object is simply a list of profiles; each profile is 1909 a sequence of MA-Protocol-IDs. A Stack-Proposal is generally 1910 accompanied by a Stack-Configuration-Data object which carries a 1911 higher-layer-addressing information element for every protocol listed 1912 in the Stack-Proposal. A node generating a Stack-Configuration-Data 1913 object is committed to honouring the implied protocol configuration; 1914 in particular, it must be immediately prepared to accept incoming 1915 datagrams or connections at the protocol/port combinations 1916 advertised. However, the object contents should be retained only for 1917 the duration of the Query/Response exchange and any following 1918 association setup and afterwards discarded. (They may become invalid 1919 because of expired bindings at intermediate NATs, or because the 1920 advertising node is using agile ports.) 1922 A GIMPS-Query requesting association setup always contains a Stack- 1923 Proposal and Stack-Configuration-Data object, and unless re-use 1924 occurs, the GIMPS-Response does so also. For a GIMPS-Response, the 1925 Stack-Proposal must be invariant for the combination of outgoing 1926 interface and NSLPID (it must not depend on the GIMPS-Query). Once 1927 the messaging association is set up, the querying node repeats the 1928 responder's Stack-Proposal over it in the GIMPS-Confirm. The 1929 responding node can verify this to ensure that no bidding-down attack 1930 has occurred. 1932 5.6.2 Protocol Definition: Forwards-TCP 1934 This defines a basic configuration for the use of TCP between peers. 1935 Support for this protocol is mandatory; associations using it can 1936 carry messages with the transfer attribute Reliable=True. The 1937 connection is opened in the forwards direction, from the querying 1938 node, towards the responder at a previously advertised port. The 1939 higher-layer-addressing formats are: 1941 o downstream: no additional data (just the MA-Protocol-ID) 1942 o upstream: 2 byte port number at which the connection will be 1943 accepted. 1945 5.6.3 Additional Protocol Options 1947 It is expected that the base GIMPS specification will define a single 1948 mandatory protocol for channel security (one of IKE/IPsec or TLS). 1949 Further protocols or configurations could be defined in the future 1950 for additional performance or flexibility. Examples are: 1952 o SCTP or DCCP as alternatives to TCP, with essentially the same 1953 configuration. 1955 o SigComp [17] for message compression. 1957 o ssh [25] or HIP/IPsec [26] for channel security. 1959 o Alternative modes of TCP operation, for example where it is set up 1960 from the responder to the querying node. 1962 5.7 Specific Message Routing Methods 1964 Each message routing method (see Section 3.3) requires the definition 1965 of the format of the message routing information (MRI) and Query- 1966 encapsulation rules. These are given in the following subsections 1967 for the various possible message routing methods. 1969 5.7.1 The Path-Coupled MRM 1971 5.7.1.1 Message Routing Information 1973 For the path-coupled MRM, this is just the Flow Identifier as in 1974 [20]. Minimally, this could just be the flow destination address; 1975 however, to account for policy based forwarding and other issues a 1976 more complete set of header fields should be used (see Section 7.2 1977 and Section 7.3 for further discussion). 1979 Flow-Identifier = network-layer-version 1980 source-address prefix-length 1981 destination-address prefix-length 1982 IP-protocol 1983 traffic-class 1984 [ flow-label ] 1985 [ ipsec-SPI / L4-ports] 1987 Additional control information defines whether the flow-label, SPI 1988 and port information are present, the direction of the message 1989 relative to this flow, and whether the IP-protocol and traffic-class 1990 fields should be interpreted as significant. 1992 5.7.1.2 Query Encapsulation for the Path-Coupled Message Routing Method 1994 Where the signalling message is travelling in the same ('downstream') 1995 direction as the flow defined by the MRI, the IP addressing for Query 1996 messages is as follows: 1998 o The destination address MUST be the flow destination address as 1999 given in the MRI of the message payload. 2001 o By default, the source address is the flow source address, again 2002 from the MRI. This provides the best likelihood that the message 2003 will be correctly routed through any region which performs per- 2004 packet policy-based forwarding or load balancing which takes the 2005 source address into account. However, there may be circumstances 2006 where the use of the signaling source address is preferable, 2007 specifically: 2009 * In order to receive ICMP error messages about the Query message 2010 (such as unreachable port or address). If these are delivered 2011 to the flow source rather than the signaling source, it will be 2012 very difficult for the querying node to detect that it is the 2013 last GIMPS node on the path. 2015 * In order to attempt to run GIMPS through an unmodified NAT, 2016 which will only process and translate IP addresses in the IP 2017 header. 2019 Because of these considerations, use of the signaling source 2020 address is allowed as an option, with use based on local policy. 2021 A node SHOULD use the flow source address for initial Query 2022 messages, but MAY transition to the signaling source address for 2023 retransmissions or as a matter of static configuration (e.g. if a 2024 NAT is known to be in the path out of a certain interface). A 2025 flag in the common header tells the message receiver which option 2026 was used. 2028 It is vital that the Query message mimics the actual data flow as 2029 closely as possible, since this is the basis of how the signaling 2030 message is attached to the data path. To this end, GIMPS may set the 2031 traffic class and (for IPv6) flow label to match the values in the 2032 MRI if this would be needed to ensure correct routing. 2034 Any message sent in datagram mode should be below a conservative 2035 estimate of the path MTU (e.g. 512 bytes). It is possible that 2036 fragmented datagrams including an RAO will not be correctly handled 2037 in the network, so the sender may set the DF (do not fragment) bit in 2038 the IPv4 header in order to detect that a message has encountered a 2039 link with an unusually low MTU. In this case, it must use the 2040 signalling source address for the IP source address in order to 2041 receive the ICMP error. 2043 A GIMPS implementation may apply validation checks to the MRI, to 2044 reject Query messages that are being injected by nodes with no 2045 legitimate interest in the flow being signalled for. In general, if 2046 the GIMPS node can detect that no flow could arrive over the same 2047 interface as the Query message, it should be rejected. (Such checks 2048 apply only to messages with the query encapsulation, since only those 2049 messages are required to track the flow path.) The main checks are 2050 that the IP version should match the version(s) used on that 2051 interface, and that the full range of source addresses (the source- 2052 address masked with its prefix-length) would pass ingress filtering 2053 checks. In addition, the MRI destination-address can also be checked 2054 against the destination in the IP header. 2056 These encapsulation rules allow Query messages to be sent in the same 2057 direction as the flow, and hence allow routing state to be set up 2058 from the flow source towards the flow destination. In some 2059 deployment scenarios (see Section 10.1 for further discussion), it is 2060 desirable and logically possible to set up routing state in the 2061 reverse direction. Implementing this in the specification would 2062 require defining rules for encapsulating a Query message in the 2063 upstream direction. Details are for further study. 2065 6. Formal Protocol Specification 2067 This section provides a more formal specification of the operation of 2068 GIMPS processing, in terms of rules for transitions between states of 2069 a set of communicating state machines within a node. The content 2070 here is currently preliminary, and includes only the top-level 2071 outline and the state transition diagrams for the different state 2072 machiens. In the future it will include message processing rules 2073 that should be applied for each event/state combination. 2075 Conceptually, the operation of GIMPS processing at a node may be seen 2076 as the cooperation of 4 types of state machine: 2078 1. There is a top-level state machine which represents the node 2079 itself (Node-SM). This is responsible for the processing of 2080 events which cannot be directed towards a more specific state 2081 machine, for example, inbound messages for which no per-flow 2082 routing state currently exists. This machine exists permanently, 2083 and is responsible for creating 'per-flow' state machines to 2084 manage the operation of the GIMPS handshake and routing state 2085 maintenance procedures. 2087 2. For each flow and signalling direction where the node is 2088 responsible for initiating the creation of routing state, there 2089 is an instance of a Query-Node Routing state machine (Query-SM). 2090 This machine sends Query and Confirm messages and waits for 2091 Responses, according to the requirements from locally generated 2092 API commands or timer processing (e.g. message repetition or 2093 routing state refresh). 2095 3. For each flow and signalling direction where the node has 2096 accepted the creation of routing state by a peer, there is an 2097 instance of a Responding-Node Routing state machine 2098 (Response-SM). This machine is responsible for managing the 2099 status of the routing state for that flow. In some cases, it is 2100 also responsible for retransmission of Response messages; 2101 however, in many cases, the generation of Response messages is 2102 handled by the Node-SM, and a Response-SM is not even created for 2103 a flow until a properly formatted Confirm has been accepted. 2105 4. Messaging assocations have their own lifecycle, represented by 2106 MA-SM, from when they are first created (in an 'incomplete' 2107 state, listening for an inbound connection or waiting for 2108 outbound connections to complete), to when they are active and 2109 available for use. 2111 Note that, apart from the fact that the various machines can be 2112 created and destroyed by each other, there is almost no interaction 2113 between them. The machines for different flows do not interact; the 2114 Query-SM and Response-SM for a single flow and signalling direction 2115 do not interact. That is, the Response-SM which accepts the creation 2116 of routing state for a flow on one interface has no direct 2117 interaction with the Query-SM which sets up routing state on the next 2118 interface along the path. This interaction is mediated through the 2119 NSLP. 2121 The state transition diagrams use the following terminology for event 2122 naming: 2124 o rx_ = a message received event. The rest of the event name is the 2125 name of the message 2127 o tg_ = a trigger event, either from the API or from another 2128 internal state machine. 2130 o to_ = a timeout event. 2132 o er_ = an error indication event. This may be filtered back to the 2133 NSLP. 2135 6.1 Node Processing 2137 The Node level state machine is responsible for processing events for 2138 which no more appropriate messaging association state or routing 2139 state exists. Its structure is trivial: there is a single state 2140 ('Idle'); all events cause a transition back to Idle. Some events 2141 cause the creation of other state machines. 2143 6.2 Query Node Processing 2145 tg_Initialise_QNode +-----+ 2146 -------------------------|Birth| 2147 | +-----+ 2148 | 2149 | 2150 | 2151 | tg_Data_Rcvd 2152 | tg_NSLP_Data || tg_NSLP_Data 2153 | -------- -------- 2154 | | V | V 2155 | | V | V 2156 | +----------+ +-----------+ 2157 ---->>| Awaiting | tg_Response_Rcvd |Established| 2158 ------| Response |------------------------------>> | | 2159 | +----------+ +-----------+ 2160 | ^ | ^ | 2161 | ^ | ^ | 2162 | -------- | | 2163 | to_No_Resp | | 2164 | [!nResp_reached] tg_Data_Rcvd | | 2165 | || tg_NSLP_Data | | 2166 | -------- | | 2167 |to_No_Resp | V | | 2168 |[nResp_reached] | V | | 2169 V +-----------+ tg_Response_Rcvd| | 2170 V | Awaiting |----------------- | 2171 +-----+ | Refresh |<<------------------- 2172 |Death| +-----------+ to_Refresh_QNode 2173 +-----+ 2174 ^ 2175 ^ 2176 | 2177 |to_Expire_QNode 2178 |(from all states) 2180 Figure 6: Query Node State Machine 2182 6.3 Responder Node Processing 2184 tg_Query_Rcvd tg_Query_Rcvd 2185 [confirmRequired] +-----+ [!confirmRequired] 2186 -------------------------|Birth|--------------------------- 2187 | +-----+ | 2188 | | | 2189 | | tg_Confirm_Rcvd | 2190 | -------------------------- | 2191 | | | 2192 | | | 2193 | tg_Data_Rcvd | | 2194 | tg_NSLP_Data || tg_NSLP_Data | | 2195 | -------- ------------ | | 2196 | | V | V V V 2197 | | V | V V V 2198 | +----------+ | +-----------+ 2199 ---->>| Awaiting | tg_Confirm_Rcvd ---------|Established| 2200 ------| Confirm |------------------------------>> | | 2201 | +----------+ +-----------+ 2202 | ^ | 2203 | ^ | 2204 | -------- 2205 | to_No_Conf 2206 | [!nConf_reached] 2207 | 2208 | 2209 | +-----+ 2210 ----------------------->>|Death|<<----------------------- 2211 to_No_Resp +-----+ to_Expire_RNode 2212 [nConf_reached] (from all states) 2214 Figure 7: Responder Node State Machine 2216 6.4 Messaging Association Processing 2218 tg_Initialise_MA +-----+ 2219 ----------------------------|Birth| 2220 | +-----+ 2221 | 2222 | tg_Send_Message 2223 | tg_Send_Message || rx_Message 2224 | -------- -------- 2225 | | V | V 2226 | | V | V 2227 | +----------+ +-----------+ 2228 ---->>| Awaiting | tg_Connect | Connected | 2229 ------|Connection|------------------------------>> | | 2230 | +----------+ +-----------+ 2231 | | 2232 | | 2233 | | 2234 | | 2235 | to_Inactive_MA | 2236 | er_MA_Connect +-----+ || er_MA_Failure | 2237 -------------------------->>|Death|<<-------------------- 2238 +-----+ 2240 Figure 8: Messaging Association State Machine 2242 7. Advanced Protocol Features 2244 7.1 Route Changes and Local Repair 2246 7.1.1 Introduction 2248 When re-routing takes place in the network, GIMPS and signaling 2249 application state needs to be updated for all flows whose paths have 2250 changed. The updates to signaling application state are usually 2251 signaling application dependent: for example, if the path 2252 characteristics have actually changed, simply moving state from the 2253 old to the new path is not sufficient. Therefore, GIMPS cannot carry 2254 out the complete path update processing. Its responsibilities are to 2255 detect the route change, update its own routing state consistently, 2256 and inform interested signaling applications at affected nodes. 2258 Route change management is complicated by the distributed nature of 2259 the problem. Consider the re-routing event shown in Figure 9. An 2260 external observer can tell that the main responsibility for 2261 controlling the updates will probably lie with nodes A and E; 2262 however, D1 is best placed to detect the event quickly at the GIMPS 2263 level, and B1 and C1 could also attempt to initiate the repair. 2265 On the assumption that NSLPs are soft-state based and operate end to 2266 end, and because GIMPS also periodically updates its picture of 2267 routing state, route changes will eventually be repaired 2268 automatically. However, especially if NSLP refresh times are 2269 extended to reduce signaling load, the duration of inconsistent state 2270 may be very long indeed. Therefore, GIMPS includes logic to deliver 2271 prompt notifications to NSLPs, to allow NSLPs to carry out local 2272 repair if possible. 2274 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2275 x +--+ +--+ +--+ x Initial 2276 x .|B1|_.......|C1|_.......|D1| x Configuration 2277 x . +--+. .+--+. .+--+\. x 2278 x . . . . . . x 2279 >>xxxxxx . . . . . . xxxxxx>> 2280 +-+ . .. .. . +-+ 2281 .....|A|/ .. .. .|E|_.... 2282 +-+ . . . . . . +-+ 2283 . . . . . . 2284 . . . . . . 2285 . +--+ +--+ +--+ . 2286 .|B2|_.......|C2|_.......|D2|/ 2287 +--+ +--+ +--+ 2289 +--+ +--+ +--+ Configuration 2290 .|B1|........|C1|........|D1| after failure 2291 . +--+ .+--+ +--+ of D1-E link 2292 . \. . \. ./ 2293 . . . . . 2294 +-+ . .. .. +-+ 2295 .....|A|. .. .. .|E|_.... 2296 +-+\. . . . . . +-+ 2297 >>xxxxxx . . . . . . xxxxxx>> 2298 x . . . . . . x 2299 x . +--+ +--+ +--+ . x 2300 x .|B2|_.......|C2|_.......|D2|/ x 2301 x +--+ +--+ +--+ x 2302 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2304 ........... = physical link topology 2306 >>xxxxxxx>> = flow direction 2308 _.......... = indicates outgoing link 2309 for flow xxxxxx given 2310 by local forwarding table 2312 Figure 9: A Re-Routing Event 2314 7.1.2 Route Change Detection 2316 There are two aspects to detecting a route change at a single node: 2318 o Detecting that the path in the direction of the Query has (or may 2319 have) changed. 2321 o Detecting that the path in the direction of the Response has (or 2322 may have) changed (in which case the node may no longer be on the 2323 path at all). 2325 At a single node, these processes are largely independent, although 2326 clearly a change in the path in one direction at a node corresponds 2327 to a change in path in the opposite direction at its peer. Note that 2328 there are two possible aspects of route change: 2330 Interface: The interface through which a flow leaves or enters a node 2331 may change. 2333 Peer: The adjacent peer may change. 2335 In general, a route change could include one or the other or both. 2336 (In theory it could include neither, although such changes are hard 2337 to detect and even harder to do anything useful about.) 2339 There are five mechanisms for a GIMPS node to detect that a route 2340 change has occurred, which are listed below. They apply differently 2341 depending on whether the change is in the Query or Response 2342 direction, and these differences are summarised in the following 2343 table. 2345 Local Trigger: In trigger mode, a node finds out that the next hop 2346 has changed. This is the RSVP trigger mechanism where some form 2347 of notification mechanism from the routing table to the protocol 2348 handler is assumed. Clearly this only works if the routing change 2349 is local, not if the routing change happens somewhere a few 2350 routing hops away (including the case that the change happens at a 2351 GIMPS-unaware node). 2353 Extended Trigger: An extended trigger, where the node checks a link- 2354 state routing table to discover that the path has changed. This 2355 makes certain assumptions on consistency of route computation (but 2356 you probably need to make those to avoid routing loops) and only 2357 works within a single area for OSPF and similar link-state 2358 protocols. Where available, this offers the most accurate and 2359 expeditious indication of route changes, but requires more access 2360 to the routing internals than a typical OS may provide. 2362 GIMPS C-mode Monitoring: A node may find that C-mode packets are 2363 arriving (from either peer) with a different TTL or on a different 2364 interface. This provides no direct information about the new flow 2365 path, but indicates that routing has changed and that rediscovery 2366 may be required. 2368 Data Plane Monitoring: The signaling application on a node may detect 2369 a change in behaviour of the flow, such as TTL change, arrival on 2370 a different interface, or loss of the flow altogether. The 2371 signaling application on the node is allowed to notify this 2372 information locally to GIMPS. 2374 GIMPS Probing: In probing mode, each GIMPS node periodically repeats 2375 the discovery (GIMPS-Query/GIMPS-Response) operation. The 2376 querying node will discover the route change by a modification in 2377 the Network-Layer-Information in the GIMPS-Response. This is 2378 similar to RSVP behavior, except that there is an extra degree of 2379 freedom since not every message needs to repeat the discovery, 2380 depending on the likely stability of routes. All indications are 2381 that, leaving mobility aside, routes are stable for hours and 2382 days, so this may not be necessary on a 30-second interval, 2383 especially if the other techniques listed above are available. 2385 When these methods discover a route change in the Response direction, 2386 this cannot be handled directly by GIMPS at the detecting node, since 2387 route discovery proceeds only in the Query direction. Therefore, to 2388 exploit these mechanisms, it must be possible for GIMPS to send a 2389 notification message to initiate this. (This would be possible for 2390 example by setting an additional flag in the Common-Header of a 2391 message.) 2393 +----------------------+----------------------+---------------------+ 2394 | Method | Query direction | Response direction | 2395 +----------------------+----------------------+---------------------+ 2396 | Local Trigger | Discovers new | Not applicable | 2397 | | interface (and peer | | 2398 | | if local) | | 2399 | | | | 2400 | Extended Trigger | Discovers new | May determine that | 2401 | | interface and may | route from peer | 2402 | | determine new peer | will have changed | 2403 | | | | 2404 | C-Mode Monitoring | Provides hint that | Provides hint that | 2405 | | change has occurred | change has occurred | 2406 | | | | 2407 | Data Plane | Not applicable | NSLP informs GIMPS | 2408 | Monitoring | | that a change may | 2409 | | | have occurred | 2410 | | | | 2411 | Probing | Discovers changed | Discovers changed | 2412 | | Network-Layer-Inform | Network-Layer-Infor | 2413 | | ation in | mation in | 2414 | | GIMPS-Response | GIMPS-Query | 2415 +----------------------+----------------------+---------------------+ 2417 7.1.3 Local Repair 2419 Once a node has detected that a change may have occurred, there are 2420 three possible cases: 2422 1. Only a change in the Response direction is indicated. There is 2423 nothing that can be done locally; GIMPS must propagate a 2424 notification to its peer. 2426 2. A Query direction change has been detected and a Response 2427 direction change cannot be ruled out. Although some local repair 2428 may be appropriate, it is difficult to decide what, since the 2429 path change may actually have taken place remotely from the 2430 detecting node (so that this node is no longer on the path at 2431 all). 2433 3. A Query direction change has been detected, but there is no 2434 change in the Responding direction. In this case, the detecting 2435 node is the true crossover router, i.e. the point in the network 2436 where old and new paths diverge. It is the correct node to 2437 initiate the local repair process. 2439 In case (3), i.e. at the crossover node, the local repair process is 2440 initiated by the GIMPS level as follows: 2442 o GIMPS marks its routing state information for this flow as 2443 'invalid', unless the route change was actually detected by D-mode 2444 probing (in which case the new state has already been installed). 2446 o GIMPS notifies the local NSLP that local repair is necessary. 2448 It is assumed that the second step will typically trigger the NSLP to 2449 generate a message, and the attempt to send it will stimulate a 2450 GIMPS-Query/Response. This signaling application message will 2451 propagate, also discovering the new route, until it rejoins the old 2452 path; the node where this happens may also have to carry out local 2453 repair actions. 2455 A problem is that there is usually no robust technique to distinguish 2456 case (2) from case (3), because of the relative weakness of the 2457 techniques in determining that such changes have not occurred. (They 2458 can be effective in determining that a change has occurred; however, 2459 even where they can tell that the route from the peer has not 2460 changed, they cannot rule out a change beyond that peer.) There is 2461 therefore a danger that multiple nodes within the network would 2462 attempt to carry out local repair in parallel. 2464 One possible technique to address this problem is that a GIMPS node 2465 that detects case (3) locally, rather than initiating local repair 2466 immediately, still sends a route change notification, just in case 2467 (2) actually applies. If the peer locally detects no downstream 2468 route change, it can signal this in the Query direction (e.g. by 2469 setting another flag in the Common-Header of a GIMPS message). This 2470 acts to damp the possibility of a 'local repair storm', at the cost 2471 of an additional peer-peer round trip time. 2473 7.1.4 Local Signaling Application State Removal 2475 After a route change, a signaling application may wish to remove 2476 state at another node which is no longer on the path. However, since 2477 it is no longer on the path, in principle GIMPS can no longer send 2478 messages to it. (In general, provided this state is soft, it will 2479 time out anyway; however, the timeouts involved may have been set to 2480 be very long to reduce signaling load.) The requirement to remove 2481 state in a specific peer node is identified in [23]. 2483 This requirement can be met provided that GIMPS is able to 'remember' 2484 the old path to the signaling application peer for the period while 2485 the NSLP wishes to be able to use it. Since NSLP peers are a single 2486 GIMPS hop apart, the necessary information is just the old entry in 2487 the node's routing state table for that flow. Rather than requiring 2488 the GIMPS level to maintain multiple generations of this information, 2489 it can just be provided to the signaling application in the same node 2490 (in an opaque form), which can store it if necessary and provide it 2491 back to the GIMPS layer in case it needs to be used. This 2492 information is denoted as 'SII-Handle' in the abstract API of 2493 Appendix D; however, the details are an implementation issue which do 2494 not affect the rest of the protocol. 2496 7.1.5 Operation with Heterogeneous NSLPs 2498 A potential problem with route change detection is that the detecting 2499 GIMPS node may not implement all the signaling applications that need 2500 to be informed. Therefore, it would need to be able to send a 2501 notification back along the unchanged path to trigger the nearest 2502 signaling application aware node to take action. If multiple 2503 signaling applications are in use, it would be hard to define when to 2504 stop propagating this notification. However, given the rules on 2505 message interception and routing state maintenance in Section 4.3, 2506 Section 4.4 and Section 5.3.3, this situation cannot arise: all NSLP 2507 peers are exactly one GIMPS hop apart. 2509 The converse problem is that the ability of GIMPS to detect route 2510 changes by purely local monitoring of forwarding tables is more 2511 limited. (This is probably an appropriate limitation of GIMPS 2512 functionality. If we need a protocol for distributing notifications 2513 about local changes in forwarding table state, a flow signaling 2514 protocol is probably not the right starting point.) 2516 7.2 Policy-Based Forwarding and Flow Wildcarding 2518 Signaling messages almost by definition need to contain address and 2519 port information to identify the flow they are signaling for. We can 2520 divide this information into two categories: 2522 Message-Routing-Information: This is the information needed to 2523 determine how a message is routed within the network. It may 2524 include a number of flow N-tuple parameters, and is carried as an 2525 object in each GIMPS message (see Section 5.1). 2527 Additional Packet Classification Information: This is any further 2528 higher layer information needed to select a subset of packets for 2529 special treatment by the signaling application. The need for this 2530 is highly signaling application specific, and so this information 2531 is invisible to GIMPS (if indeed it exists); it will be carried 2532 only in the corresponding NSLP. 2534 The correct pinning of signaling messages to the data path depends on 2535 how well the downstream messages in datagram mode can be made to be 2536 routed correctly. Two strategies are used: 2538 The messages themselves match the flow in destination address and 2539 possibly other fields (see Section 5.3 and Section 5.3.2 for 2540 further discussion). In many cases, this will cause the messages 2541 to be routed correctly even by GIMPS-unaware nodes. 2543 A GIMPS-aware node carrying out policy based forwarding on higher 2544 layer identifiers (in particular, the protocol and port numbers 2545 for IPv4) should take into account the entire Message-Routing- 2546 Information object in selecting the outgoing interface rather than 2547 relying on the IP layer. 2549 Message-Routing-Information formats may allow a degree of 2550 'wildcarding', for example by applying a prefix length to the source 2551 or destination address, or by leaving certain fields unspecified. A 2552 GIMPS-aware node must verify that all flows matching the Message- 2553 Routing-Information would be routed identically in the downstream 2554 direction, or else reject the message with an error. 2556 7.3 NAT Traversal 2558 As already noted, GIMPS messages must carry packet addressing and 2559 higher layer information as payload data in order to define the flow 2560 signalled for. (This applies to all GIMPS messages, regardless of 2561 how they are encapsulated or which direction they are travelling in.) 2562 At an addressing boundary the data flow packets will have their 2563 headers translated; if the signaling payloads are not likewise 2564 translated, the signaling messages will refer to incorrect (and 2565 probably meaningless) flows after passing through the boundary. In 2566 addition, some GIMPS messages (those used in the discovery process) 2567 carry addressing information about the GIMPS nodes themselves, and 2568 this must also be processed appropriately when traversing a NAT. 2570 The simplest solution to this problem is to require that a NAT is 2571 GIMPS-aware, and to allow it to modify datagram mode messages based 2572 on the contents of the Message-Routing-Information payload. (This is 2573 making the implicit assumption that NATs only rewrite the header 2574 fields included in this payload, and not higher layer identifiers.) 2575 Provided this is done consistently with the data flow header 2576 translation, signaling messages will be valid each side of the 2577 boundary, without requiring the NAT to be signaling application 2578 aware. An outline of the set of operations necessary on a downstream 2579 datagram mode message is as follows: 2581 1. Verify that bindings for the data flow are actually in place. 2583 2. Create bindings for subsequent C-mode signaling (based on the 2584 information in the Network-Layer-Information and Stack- 2585 Configuration-Data objects). 2587 3. Create a new Message-Routing-Information object with fields 2588 modified according to the data flow bindings. 2590 4. Create new Network-Layer-Information and Stack-Configuration-Data 2591 objects with fields to force upstream D-mode messages through the 2592 NAT, and to allow C-mode exchanges using the C-mode signaling 2593 bindings. 2595 5. Add a new NAT-Traversal payload, listing the objects which have 2596 been modified and including the unmodified Message-Routing- 2597 Information. 2599 6. Forward the message with these new payloads. 2601 The original Message-Routing-Information payload is retained in the 2602 message, but encapsulated in the new TLV type. Further information 2603 can be added corresponding to the Network-Layer-Information payload, 2604 either the original payload itself or, in the case of a GIMPS node 2605 that wished to do topology hiding, opaque tokens (or it could be 2606 omitted altogether). In the case of a sequence of NATs, this part of 2607 the NAT-Traversal object would become a list. Note that a 2608 consequence of this approach is that the routing state tables at the 2609 actual signaling application peers (either side of the NAT) are no 2610 longer directly compatible. In particular, the values of Message- 2611 Routing-Information are different, which is why the unmodified MRI is 2612 propagated in the NAT-Traversal payload to allow subsequent C-mode 2613 messages to be interpreted correctly.. 2615 The case of traversing a GIMPS-unaware NAT is for further study. 2616 There is a dual problem of whether the GIMPS peers either side of the 2617 boundary can work out how to address each other, and whether they can 2618 work out what translation to apply to the Message-Routing-Information 2619 from what is done to the signaling packet headers. The fundamental 2620 problem is that GIMPS messages contain 3 or 4 interdependent 2621 addresses which all have to be consistently translated, and existing 2622 generic NAT traversal techniques such as STUN [19] can process only 2623 two. 2625 7.4 Interaction with IP Tunnelling 2627 The interaction between GIMPS and IP tunnelling is very simple. An 2628 IP packet carrying a GIMPS message is treated exactly the same as any 2629 other packet with the same source and destination addresses: in other 2630 words, it is given the tunnel encapsulation and forwarded with the 2631 other data packets. 2633 Tunnelled packets will not be identifiable as GIMPS messages until 2634 they leave the tunnel, since any router alert option and the standard 2635 GIMPS protocol encapsulation (e.g. port numbers) will be hidden 2636 behind the standard tunnel header. If signaling is needed for the 2637 tunnel itself, this has to be initiated as a separate signaling 2638 session by one of the tunnel endpoints - that is, the tunnel counts 2639 as a new flow. Because the relationship between signaling for the 2640 'microflow' and signaling for the tunnel as a whole will depend on 2641 the signaling application in question, we are assuming that it is a 2642 signaling application responsibility to be aware of the fact that 2643 tunnelling is taking place and to carry out additional signaling if 2644 necessary; in other words, one tunnel endpoint must be signaling 2645 application aware. 2647 In some cases, it is the tunnel exit point (i.e. the node where 2648 tunnelled data and downstream signaling packets leave the tunnel) 2649 that will wish to carry out the tunnel signaling, but this node will 2650 not have knowledge or control of how the tunnel entry point is 2651 carrying out the data flow encapsulation. This information could be 2652 carried as additional data (an additional GIMPS payload) in the 2653 tunnelled signaling packets if the tunnel entry point was at least 2654 GIMPS-aware. This payload would be the GIMPS equivalent of the RSVP 2655 SESSION_ASSOC object of [11]. Whether this functionality should 2656 really be part of GIMPS and if so how the payload should be handled 2657 will be considered in a later version. 2659 7.5 IPv4-IPv6 Transition and Interworking 2661 GIMPS itself is essentially IP version neutral (version dependencies 2662 are isolated in the formats of the Message-Routing-Information, 2663 Network-Layer-Information and Stack-Configuration-Data objects, and 2664 GIMPS also depends on the version independence of the protocols that 2665 support messaging associations). In mixed environments, GIMPS 2666 operation will be influenced by the IP transition mechanisms in use. 2667 This section provides a high level overview of how GIMPS is affected, 2668 considering only the currently predominant mechanisms. 2670 Dual Stack: (This applies both to the basic approach described in 2671 [24] as well as the dual-stack aspects of more complete 2672 architectures such as [28].) In mixed environments, GIMPS should 2673 use the same IP version as the flow it is signaling for; hosts 2674 which are dual stack for applications and routers which are dual 2675 stack for forwarding should have GIMPS implementations which can 2676 support both IP versions. 2678 In theory, for some connection mode encapsulation options, a 2679 single messaging association could carry signaling messages for 2680 flows of both IP versions, but the saving seems of limited value. 2681 The IP version used in datagram mode is closely tied to the IP 2682 version used by the data flow, so it is intrinsically impossible 2683 for a IPv4-only or IPv6-only GIMPS node to support signaling for 2684 flows using the other IP version. 2686 Applications with a choice of IP versions might select a version 2687 based on which could be supported in the network by GIMPS, which 2688 could be established by running parallel discovery procedures. In 2689 theory, a GIMPS message related to a flow of one IP version could 2690 flag support for the other; however, given that IPv4 and IPv6 2691 could easily be separately routed, the correct GIMPS peer for a 2692 given flow might well depend on IP version anyway, making this 2693 flagged information irrelevant. 2695 Packet Translation: (Applicable to SIIT [5] and NAT-PT [12].) Some 2696 transition mechanisms allow IPv4 and IPv6 nodes to communicate by 2697 placing packet translators between them. From the GIMPS 2698 perspective, this should be treated essentially the same way as 2699 any other NAT operation (e.g. between 'public' and 'private' 2700 addresses) as described in Section 7.3. In other words, the 2701 translating node needs to be GIMPS-aware; it will run GIMPS with 2702 IPv4 on some interfaces and with IPv6 on others, and will have to 2703 translate the Message-Routing-Information payload between IPv4 and 2704 IPv6 formats for flows which cross between the two. The 2705 translation rules for the fields in the payload (including e.g. 2706 traffic class and flow label) are as defined in [5]. 2708 Tunnelling: (Applicable to 6to4 [13] and a whole host of other 2709 tunnelling schemes.) Many transition mechanisms handle the 2710 problem of how an end to end IPv6 (or IPv4) flow can be carried 2711 over intermediate IPv4 (or IPv6) regions by tunnelling; the 2712 methods tend to focus on minimising the tunnel administration 2713 overhead. 2715 From the GIMPS perspective, the treatment should be as similar as 2716 possible to any other IP tunnelling mechanism, as described in 2717 Section 7.4. In particular, the end to end flow signaling will 2718 pass transparently through the tunnel, and signaling for the 2719 tunnel itself will have to be managed by the tunnel endpoints. 2720 However, additional considerations may arise because of special 2721 features of the tunnel management procedures. For example, [14] 2722 is based on using an anycast address as the destination tunnel 2723 endpoint. It might be unwise to carry out signaling for the 2724 tunnel to such an address, and the GIMPS implementation there 2725 would not be able to use it as a source address for its own 2726 signaling messages (e.g. GIMPS-responses). Further analysis will 2727 be contained in a future version of this specification. 2729 8. Security Considerations 2731 The security requirement for the GIMPS layer is to protect the 2732 signaling plane against identified security threats. For the 2733 signaling problem as a whole, these threats have been outlined in 2734 [21]; the NSIS framework [20] assigns a subset of the responsibility 2735 to the NTLP. The main issues to be handled can be summarised as: 2737 Message Protection: Signaling message content should be protected 2738 against eavesdropping, modification, injection and replay while in 2739 transit. This applies both to GIMPS payloads, and GIMPS should 2740 also provide such protection as a service to signaling 2741 applications between adjacent peers. 2743 State Integrity Protection: It is important that signaling messages 2744 are delivered to the correct nodes, and nowhere else. Here, 2745 'correct' is defined as 'the appropriate nodes for the signaling 2746 given the Message-Routing-Information'. In the case where the MRI 2747 is the Flow Identification for path-coupled signaling, 2748 'appropriate' means 'the same nodes that the infrastructure will 2749 route data flow packets through'. (GIMPS has no role in deciding 2750 whether the data flow itself is being routed correctly; all it can 2751 do is ensure the signaling is routed consistently with it.) GIMPS 2752 uses internal state to decide how to route signaling messages, and 2753 this state needs to be protected against corruption. 2755 Prevention of Denial of Service Attacks: GIMPS nodes and the network 2756 have finite resources (state storage, processing power, 2757 bandwidth). The protocol should try to minimise exhaustion 2758 attacks against these resources and not allow GIMPS nodes to be 2759 used to launch attacks on other network elements. 2761 The main missing issue is handling authorisation for executing 2762 signaling operations (e.g. allocating resources). This is assumed to 2763 be done in each signaling application. 2765 In many cases, GIMPS relies on the security mechanisms available in 2766 messaging associations to handle these issues, rather than 2767 introducing new security measures. Obviously, this requires the 2768 interaction of these mechanisms with the rest of the GIMPS protocol 2769 to be understood and verified, and some aspects of this are discussed 2770 in Section 5.6. 2772 8.1 Message Confidentiality and Integrity 2774 GIMPS can use messaging association functionality, such as TLS or 2775 IPsec, to ensure message confidentiality and integrity. In many 2776 cases, confidentiality of GIMPS information itself is not likely to 2777 be a prime concern, in particular since messages are often sent to 2778 parties which are unknown ahead of time, although the content visible 2779 even at the GIMPS level gives significant opportunities for traffic 2780 analysis. Signaling applications may have their own mechanism for 2781 securing content as necessary; however, they may find it convenient 2782 to rely on protection provided by messaging associations, since it 2783 runs unbroked between signaling application peers. 2785 8.2 Peer Node Authentication 2787 Cryptographic protection (of confidentiality or integrity) requires a 2788 security association with session keys, which can be established 2789 during an authentication and key exchange protocol run based on 2790 shared secrets, public key techniques or a combination of both. 2791 Authentication and key agreement is possible using the protocols 2792 associated with the messaging association being secured (TLS 2793 incorporates this functionality directly; IKE, IKEv2 or KINK can 2794 provide it for IPsec). GIMPS nodes rely on these protocols to 2795 authenticate the identity of the next hop, and GIMPS has no 2796 authentication capability of its own. 2798 However, with discovery, there are few effective ways to know what is 2799 the legitimate next or previous hop as opposed to an impostor. In 2800 other words, cryptographic authentication here only provides 2801 assurance that a node is 'who' it is (i.e. the legitimate owner of 2802 identity in some namespace), not 'what' it is (i.e. a node which is 2803 genuinely on the flow path and therefore can carry out signaling for 2804 a particular flow). Authentication provides only limited protection, 2805 in that a known peer is unlikely to lie about its role. Additional 2806 methods of protection against this type of attack are considered in 2807 Section 8.3 below. 2809 It is an implementation issue whether peer node authentication should 2810 be made signaling application dependent; for example, whether 2811 successful authentication could be made dependent on presenting 2812 authorisation to act in a particular signaling role (e.g. signaling 2813 for QoS). The abstract API of Appendix D does not specify such 2814 policy and authentication interactions between GIMPS and the NSLP it 2815 is serving. 2817 8.3 Routing State Integrity 2819 The internal state in a node (see Section 4.2), specifically the peer 2820 identification, is used to route messages. If this state is 2821 corrupted, signaling messages may be misdirected. 2823 In the case where the message routing method is path-coupled 2824 signaling, the messages need to be routed identically to the data 2825 flow described by the Flow Identifier, and the routing state table is 2826 the GIMPS view of how these flows are being routed through the 2827 network in the immediate neighbourhood of the node. Routes are only 2828 weakly secured (e.g. there is usually no cryptographic binding of a 2829 flow to a route), and there is no other authoritative information 2830 about flow routes than the current state of the network itself. 2831 Therefore, consistency between GIMPS and network routing state has to 2832 be ensured by directly interacting with the routing mechanisms to 2833 ensure that the signaling peers are the appropriate ones for any 2834 given flow. A good overview of security issues and techniques in 2835 this sort of context is provided in [27]. 2837 In one direction, peer identification is installed and refreshed only 2838 on receiving a GIMPS-Reponse message (compare Figure 4). This must 2839 echo the cookie from a previous GIMPS-Query message, which will have 2840 been sent along the flow path (in datagram mode, i.e. end-to-end 2841 addressed). Hence, only the true next peer or an on-path attacker 2842 will be able to generate such a message, provided freshness of the 2843 cookie can be checked at the querying node. 2845 In the other direction, peer identification can be installed directly 2846 on receiving a GIMPS-Query message containing addressing information 2847 for the signaling source. However, any node in the network could 2848 generate such a message (indeed, almost any node in the network could 2849 be the genuine upstream peer for a given flow). To protect against 2850 this, three strategies are possible: 2852 Filtering: the receiving node may be able to reject signaling 2853 messages which claim to be for flows with flow source addresses 2854 which would be ruled out by ingress filtering. An extension of 2855 this technique would be for the receiving node to monitor the data 2856 plane and to check explicitly that the flow packets are arriving 2857 over the same interface and if possible from the same link layer 2858 neighbour as the datagram mode signaling packets. (If they are 2859 not, it is likely that at least one of the signaling or flow 2860 packets is being spoofed.) Signaling applications should only 2861 install state on the route taken by the signaling itself. 2863 Authentication (weak or strong): the receiving node may refuse to 2864 install upstream state until it has completed a GIMPS-Confirm 2865 handshaked with the peer. This echoes the response cookie of the 2866 GIMPS-Response, and discourages nodes from using forged source 2867 addresses. A stronger approach is to require full peer 2868 authentication within the messaging association, the reasoning 2869 being that an authenticated peer can be trusted not to pretend 2870 that it is on path when it is not. 2872 SID segregation: The routing state lookup for a given MRI and NSLPID 2873 also takes the SID into account. A malicious node can only 2874 overwrite existing routing state if it can guess the corresponding 2875 SID; it can insert state with random SID values, but generally 2876 this will not be used to route messages for which state has 2877 already been legitimately established. 2879 The second technique also plays a role in denial of service 2880 prevention, see below. In practice, a combination of all techniques 2881 may be appropriate. 2883 8.4 Denial of Service Prevention 2885 GIMPS is designed so that in general each Query message only 2886 generates at most one Response, so that a GIMPS node cannot become 2887 the source of a denial of service amplification attack. (There is a 2888 special case of retransmitted Response messages, see Section 5.3.4.) 2890 However, GIMPS can still be subjected to denial-of-service attacks 2891 where an attacker using forged source addresses forces a node to 2892 establish state without return routability, causing a problem similar 2893 to TCP SYN flood attacks. Furthermore, an adversary might use 2894 modified or replayed unprotected signaling messages as part of such 2895 an attack. There are two types of state attacks and one 2896 computational resource attack. In the first state attack, an 2897 attacker floods a node with messages that the node has to store until 2898 it can determine the next hop. If the destination address is chosen 2899 so that there is no GIMPS-capable next hop, the node would accumulate 2900 messages for several seconds until the discovery retransmission 2901 attempt times out. The second type of state-based attack causes 2902 GIMPS state to be established by bogus messages. A related 2903 computational/network-resource attack uses unverified messages to 2904 cause a node to make AAA queries or attempt to cryptographically 2905 verify a digital signature. (RSVP is vulnerable to this type of 2906 attack.) Relying only on upper layer security, for example based on 2907 CMS, might open a larger door for denial of service attacks since the 2908 messages are often only one-shot-messages without utilizing multiple 2909 roundtrips and DoS protection mechanisms. 2911 We use a combination of two defences against these attacks: 2913 1. The responding node does not establish a session or discover its 2914 next hop on receiving the GIMPS-Query message, but can wait for a 2915 GIMPS-Confirm message on a secure channel. If the channel 2916 exists, the additional delay is a one one-way delay and the total 2917 is no more than the minimal theoretically possible delay of a 2918 three-way handshake, i.e., 1.5 node-to-node round-trip times. 2919 The delay gets significantly larger if a new connection needs to 2920 be established first. 2922 2. The Response to the Query message contains a cookie, which is 2923 repeated in the Confirm. State is only established for messages 2924 that contain a valid cookie. The setup delay is also 1.5 round- 2925 trip times. (This mechanism is similar to that in SCTP [6] and 2926 other modern protocols.) 2928 Once a node has decided to establish routing state, there may still 2929 be transport and security state to be established between peers. 2930 This state setup is also vulnerable to additional denial of service 2931 attacks. GIMPS relies on the lower layer protocols that make up 2932 messaging associations to mitigate such attacks. The current 2933 description assumes that the querying node is always the one wishing 2934 to establish a messaging association, so it is typically the 2935 responding node that needs to be protected. 2937 8.5 Summary of Requirements on Cookie Mechanisms 2939 The requirements on the Query cookie can be summarised as follows: 2941 Liveness: The cookie must be live (must change from one handshake to 2942 the next). To prevent replay attacks. 2944 Unpredictability: The cookie must not be guessable (e.g. not from a 2945 sequence or timestamp). To prevent direct forgery based on seeing 2946 a history of captured messages. 2948 Easily validated: It must be efficient for the Q-Node to validate 2949 that a particular cookie matches an in-progress handshake, for a 2950 routing state machine which already exists. To discard responses 2951 to spoofed queries. 2953 Uniqueness: The cookie must be unique to a given handshake (since it 2954 is actually used to match the Response to a handshake anyway, e.g. 2955 during messaging association re-use). 2957 Likewise, the requirements on the Responder cookie can be summarised 2958 as follows: 2960 Liveness: The cookie must be live (must change from one handshake to 2961 the next). To prevent replay attacks. 2963 Creation simplicity: The cookie must be lightweight to generate. To 2964 avoid resource exhaustion at the responding node. 2966 Validation simplicity: It must be simple for the R-node to validate 2967 that an R-cookie was generated by itself (and no-one else), 2968 without storing state about the handshake it was generated for. 2970 Binding: The cookie must be bound to the routing state that will be 2971 installed. To prevent use with different routing state e.g. in a 2972 modified Confirm. The routing state here includes: 2974 The NLI of the Query 2976 The MRI/NSLPID for the messaging 2978 The interface on which the Query was received (probably) 2980 A suitable implementation for the Q-Cookie is a cryptographically 2981 random number which is unique for this routing state machine 2982 handshake. 2984 A suitable implementation for the R-Cookie is as follows: 2986 R-Cookie = liveness data + hash (locally known secret, 2987 Q-Node NLI, MRI, NSLPID, 2988 reception interface, 2989 liveness data) 2991 There are a couple of alternatives for the liveness data. One is to 2992 use a timestamp like SCTP. Another is to use a local secret with 2993 (rapid) rollover, and the liveness data is the generation number of 2994 the secret, like IKEv2. In both cases, the liveness data has to be 2995 carried outside the hash, to allow the hash to be verified at the 2996 Responder. Another approach is to replace the hash with encryption 2997 under a locally known secret, in which case the liveness data does 2998 not need to be carried in the clear. Any symmetric cipher immune to 2999 known plaintext attacks can be used. 3001 8.6 Residual Threats 3003 Taking the above security mechanisms into account, the main residual 3004 threats against NSIS are three types of on-path attack. 3006 An on-path attacker who can intercept the initial Query can do most 3007 things it wants to the subsequent signalling. It is very hard to 3008 protect against this at the GIMPS level; the only defence is to use 3009 strong messaging association security to see whether the Responding 3010 node is authorised to take part in NSLP signalling exchanges. To 3011 some extent, this behaviour is logically indistinguishable from 3012 correct operation, so it is easy to see why defence is difficult. 3013 Note than an on-path attacker of this sort can do anything to the 3014 traffic as well as the signalling. Therefore, the additional threat 3015 induced by the signalling weakness seems tolerable. 3017 At the NSLP level, there is a concern about transitivity of trust of 3018 correctness of routing along the signalling chain. The NSLP at the 3019 querying node can have good assurance that it is communicating with 3020 an on-path peer (or a node delegated by the on-path node). However, 3021 it has no assurance that the node beyond the responder is also on- 3022 path, or that the MRI (in particular) is not being modified by the 3023 responder to refer to a different flow. Therefore, if it sends 3024 signalling messages with payloads (e.g. authorisation tokens) which 3025 are "valuable" to nodes beyond the first hop, it is up to the NSLP to 3026 ensure that the appropriate chain of trust exists, which must in 3027 general use messaging association (strong) security. 3029 There is a further residual attack by a node which is not on the path 3030 of the flow, but is on the path of the Response, or is able to use a 3031 Response from one handshake to interfere with another. The attacker 3032 modifies the Response to cause the Querying node to form an adjacency 3033 with it rather than the true downstream node. In principle, this 3034 attack can be prevented by including an additional cryptographic 3035 object in the Response message which ties the Response to the initial 3036 Query and the routing state and can be verified by the Querying node. 3038 9. IANA Considerations 3040 This section outlines the content of a future IANA considerations 3041 section. 3043 The GIMPS specification requires the creation of registries, as 3044 follows: 3046 GIMPS Message Type: The GIMPS common header (Appendix C.2) contains a 3047 1 byte message type field (initially distinguishing Query/ 3048 Response/Confirm/Data/Error and MA-Hello messages). 3050 NSLP Identifiers: Each signaling application requires one of more 3051 NSLPIDs (different NSLPIDs may be used to distinguish different 3052 classes of signaling node, for example to handle different 3053 aggregation levels or different processing subsets). An NSLPID 3054 must be associated with a unique RAO value; further considerations 3055 are discussed in Section 5.3.3. 3057 Object Types: There is an TBD-bit field in the object header 3058 (Appendix C.3.1). Distinguish different ranges for different 3059 allocation styles (standards action, expert review etc.) and 3060 different applicability scopes (experimental/private). When a new 3061 object type is defined, the extensibility bits (A/B, see 3062 Appendix C.3.2) must also be defined. 3064 Extensibility Flags: There are TBD reserved flag bits in the generic 3065 object header (Appendix C.3.1). These are reserved for the 3066 definition of more complex extensibility encoding schemes. 3068 Message Routing Methods: GIMPS allows the idea of multiple message 3069 routing methods (see Section 3.3). The message routing method is 3070 indicated in the leading 2 bytes of the MRI object 3071 (Appendix C.4.1). 3073 MA-Protocol-IDs: The GIMPS design allows the set of possible 3074 protocols to be used in a messaging association to be extended, as 3075 discussed in Section 5.6. Every new mode of using a protocol is 3076 given a single byte MA-Protcol-ID, which is used as a tag in the 3077 Stack-Proposal and Stack-Configuration-Data objects 3078 (Appendix C.4.4 and Appendix C.4.5). Allocating a new MA- 3079 Protocol-ID requires defining the higher layer addressing 3080 information (if any) in the Stack-Configuration-Data object that 3081 is needed to define its configuration. Note that the 3082 MA-Protocol-ID is not an IP Protocol number (indeed, some of the 3083 possible messaging association protocols - such as TLS - do not 3084 have an IP Protocol number). 3086 Error Classes: There is a 1 byte field at the start of the Value 3087 field of the Error object (Appendix C.4.10). Five values for this 3088 field have already been defined. Further general classes of error 3089 could be defined. Note that the value here is primarily to aid 3090 human or management interpretation of otherwise unknown error 3091 codes. 3093 Error Codes: There is a 3 byte error code in the Value field of the 3094 Error object (Appendix C.4.10). When a new error code is 3095 allocated, the Error Class and the format of any associated error- 3096 specific information must also be defined. 3098 10. Open Issues 3100 Note that this section is now partially historic; the authoritative 3101 list of open issues is contained in an online issue tracker at 3102 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index. 3103 The subsections remaining here are preserved to keep cross-reference 3104 integrity with the rest of the specification until the issues are 3105 resolved. 3107 10.1 Additional Discovery Mechanisms 3109 The routing state maintenance procedures described in Section 4.4 are 3110 strongly focussed on the problem of discovering, implicitly or 3111 explicitly, the neighbouring peers on the flow path - which is the 3112 necessary functionality for path-coupled signaling. 3114 As well as the GIMPS-Query/Response discovery mechanism for 3115 determining the downstream peer for the path-coupled message routing 3116 method, other techniques may sometimes also be possible. For 3117 example, in many environments, a host has a single access router, 3118 i.e. the downstream peer (for outgoing flows) and the upstream peer 3119 (for incoming ones) are known a priori. More generally, a link state 3120 routing protocol database can be analysed to determine downstream 3121 peers in more complex topologies, and maybe upstream ones if strict 3122 ingress filtering is in effect. More radically, much of the GIMPS 3123 protocol is unchanged if we consider off-path signaling nodes, 3124 although there are significant differences in some of the security 3125 analysis (Section 8.3). None of these possibilities are currently 3126 considered further in this specification. However, the basic 3127 protocol description is unchanged if an encapsulation mechanism is 3128 defined for sending Query messages upstream or directed to particular 3129 nodes, if this information is available from other sources. 3131 11. Change History 3133 11.1 Changes In Version -06 3135 Version -06 does not introduce any major structural changes to the 3136 protocol definition, although it does clarify a number of details and 3137 resolve some outstanding open issues. The primary changes are as 3138 follows: 3140 1. Added a new high level Section 3.3 which gathers together the 3141 various aspects of the message routing method concept. 3143 2. Added a new high level Section 3.4 which explains the concept 3144 and significance of the session identifier. Also clarified that 3145 the routing state always depends on the session identifier. 3147 3. Added notes about the level of address validation performed by 3148 GIMPS in Section 4.1.2 and extensions to the API in Appendix D. 3150 4. Split the old Node-Addressing object into a Network-Layer- 3151 Information object and Stack-Configuration-Data object. The 3152 former refers to basic information about a node, and the latter 3153 carries information about messaging association configuration. 3154 Redefined the content of the various handshake messages 3155 accordingly in Section 4.4.1 and Section 5.1. 3157 5. Re-wrote Section 4.4.3 to clarify the rules on refresh and purge 3158 of routing state and messaging associations. Also, moved the 3159 routing state lifetime into the Network-Layer-Information object 3160 and added a messaging association lifetime to the Stack- 3161 Configuration-Data object (Section 5.2). 3163 6. Added specific message types for errors and MA-Refresh in 3164 Section 5.1. The error object is now GIMPS-specific 3165 (Appendix C.4.10). 3167 7. Moved the Flow-Identifier information about the message routing 3168 method from the general description of the object to the path- 3169 coupled MRM section (Section 5.7.1.1), and made a number of 3170 clarifications to the bit format (Appendix C.4.1.1). 3172 8. Removed text about assumptions on the version numbering of 3173 NSLPs, and restricted the scope of the description of TLV objct 3174 formats and extensibility flags to GIMPS rather than the whole 3175 of NSIS (Appendix C). 3177 9. Added a new Section 5.5 explaining the possible relationships 3178 between message types and encapsulation formats. 3180 10. Added a new Section 6 in outline form, to capture the formal 3181 specification of the protocol operation. 3183 11. Added new security sections on cookie requirements (Section 8.5) 3184 and residual threats (Section 8.6). 3186 11.2 Changes In Version -05 3188 Version -05 reformulates the specification, to describe routing state 3189 maintenance in terms of exchanging explicitly identified Query/ 3190 Response/Confirm messages, leaving the upstream/downstream 3191 distinction as a specific detail of how Query messages are 3192 encapsulated. This necessitated widespread changes in the 3193 specification text, especially Section 4.2.1, Section 4.4, 3194 Section 5.1 and Section 5.3 (although the actual message sequences 3195 are unchanged). A number of other issues, especially in the area of 3196 message encapsulation, have also been closed. The main changes are 3197 the following: 3199 1. Added a reference to [29] as a concrete example of an 3200 alternative message routing method. 3202 2. Added further text (particularly in Section 2) on what GIMPS 3203 means by the concept of 'session'. 3205 3. Firmed up the selection of UDP as the encapsulation choice for 3206 datagram mode, removing the open issue on this topic. 3208 4. Defined the interaction between GIMPS and signaling applications 3209 for communicating about the cryptographic security properties of 3210 how a message will be sent or has been received (see 3211 Section 4.1.2 and Appendix D). 3213 5. Closed the issue on whether Query messages should use the 3214 signaling or flow source address in the IP header; both options 3215 are allowed by local policy and a flag in the common header 3216 indicates which was used. (See Section 5.7.1.2.) 3218 6. Added the necessary information elements to allow the IP hop 3219 count between adjacent GIMPS peers to be measures and reported. 3220 (See Section 5.2.2 and Appendix C.4.3.) 3222 7. The old open-issue text on selection of IP router alert option 3223 values has been moved into the main specification to capture the 3224 technical considerations that should be used in assigning such 3225 values (in section Section 5.3.3). 3227 8. Resolved the open issue on lost Confirm messages by allowing a 3228 choice of timer-based retransmission of the Response, or an 3229 error message from the responding node which causes the 3230 retransmission of the Confirm (see Section 5.3.4). 3232 9. Closed the open issue on support for message scoping (this is 3233 now assumed to be a NSLP function). 3235 10. Moved the authoritative text for most of the remaining open 3236 issues in Section 10 to an online issue tracker. 3238 11.3 Changes In Version -04 3240 Version -04 includes mainly clarifications of detail and extensions 3241 in particular technical areas, in part to support ongoing 3242 implementation work. The main details are as follows: 3244 1. Substantially updated Section 4, in particular clarifying the 3245 rules on what messages are sent when and with what payloads 3246 during routing and messaging association setup, and also adding 3247 some further text on message transfer attributes. 3249 2. The description of messaging association protocol negotiation 3250 including the related object formats has been centralised in a 3251 new Section 5.6, removing the old Section 6.6 and also closing 3252 old open issues 8.5 and 8.6. 3254 3. Made a number of detailed changes in the message format 3255 definitions (Appendix C), as well as incorporating initial rules 3256 for encoding message extensibility information. Also included 3257 explicit formats for a general purpose Error object, and the 3258 objects used to negotiate messaging association protocols. 3259 Updated the corresponding open issues section (old section 9.3) 3260 with a new item on NSLP versioning. 3262 4. Updated the GIMPS API (Appendix D), including more precision on 3263 message transfer attributes, making the NSLP hint about storing 3264 reverse path state a return value rather than a separate 3265 primitive, and adding a new primitive to allow signaling 3266 applications to invalidate GIMPS routing state. Also, added a 3267 new parameter to SendMessage to allow signaling applications to 3268 'bypass' a message statelessly, preserving the source of an 3269 input message. 3271 5. Added an outline for the future content of an IANA 3272 considerations section (Section 9). Currently, this is 3273 restricted to identifying the registries and allocations 3274 required, without defining the allocation policies and other 3275 considerations involved. 3277 6. Shortened the background design discussion in Section 3. 3279 7. Made some clarifications in the terminology section relating to 3280 how the use of C-mode does and does not mandate the use of 3281 transport or security protection. 3283 8. The ABNF for message formats in Section 5.1 has been re-written 3284 with a grammar structured around message purpose rather than 3285 message direction, and additional explanation added to the 3286 information element descriptions in Section 5.2. 3288 9. The description of the datagram mode transport in Section 5.3 3289 has been updated. The encapsulation rules (covering IP 3290 addressing and UDP port allocation) have been corrected, and a 3291 new subsection on message retransmission and rate limiting has 3292 been added, superceding the old open issue on the same subject 3293 (section 8.10). 3295 10. A new open issue on IP TTL measurement to detect non-GIMPS 3296 capable hops has been added (old section 9.5). 3298 11.4 Changes In Version -03 3300 Version -03 includes a number of minor clarifications and extensions 3301 compared to version -02, including more details of the GIMPS API and 3302 messaging association setup and the node addressing object. The full 3303 list of changes is as follows: 3305 1. Added a new section pinning down more formally the interaction 3306 between GIMPS and signaling applications (Section 4.1), in 3307 particular the message transfer attributes that signaling 3308 applications can use to control GIMPS (Section 4.1.2). 3310 2. Added a new open issue identifying where the interaction between 3311 the security properties of GIMPS and the security requirements of 3312 signaling applications should be identified (old section 9.10). 3314 3. Added some more text in Section 4.2.1 to clarify that GIMPS has 3315 the (sole) responsibility for generating the messages that 3316 refresh message routing state. 3318 4. Added more clarifying text and table to GHC and IP TTL handling 3319 discussion of Section 4.3.4. 3321 5. Split Section 4.4 into subsections for different scenarios, and 3322 added more detail on Node-Addressing object content and use to 3323 handle the case where association re-use is possible in 3324 Section 4.4.2. 3326 6. Added strawman object formats for Node-Addressing and Stack- 3327 Proposal objects in Section 5.1 and Appendix C. 3329 7. Added more detail on the bundling possibilities and appropriate 3330 configurations for various transport protocols in Section 5.4.1. 3332 8. Included some more details on NAT traversal in Section 7.3, 3333 including a new object to carry the untranslated address-bearing 3334 payloads, the NAT-Traversal object. 3336 9. Expanded the open issue discussion in old section 9.3 to include 3337 an outline set of extensibility flags. 3339 11.5 Changes In Version -02 3341 Version -02 does not represent any radical change in design or 3342 structure from version -01; the emphasis has been on adding details 3343 in some specific areas and incorporation of comments, including early 3344 review comments. The full list of changes is as follows: 3346 1. Added a new Section 1.1 which summarises restrictions on scope 3347 and applicability; some corresponding changes in terminology in 3348 Section 2. 3350 2. Closed the open issue on including explicit GIMPS state teardown 3351 functionality. On balance, it seems that the difficulty of 3352 specifying this correctly (especially taking account of the 3353 security issues in all scenarios) is not matched by the saving 3354 of state enabled. 3356 3. Removed the option of a special class of message transfer for 3357 reliable delivery of a single message. This can be implemented 3358 (inefficiently) as a degenerate case of C-mode if required. 3360 4. Extended Appendix C with a general discussion of rules for 3361 message and object formats across GIMPS and other NSLPs. Some 3362 remaining open issues are noted in old section 9.3 (since 3363 removed). 3365 5. Updated the discussion of Section 5.3.3 to take into account the 3366 proposed message formats and rules for allocation of NSLP id, 3367 and propose considerations for allocation of RAO values. 3369 6. Modified the description of the information used to route 3370 messages (first given in Section 4.2.1 but also throughout the 3371 document). Previously this was related directly to the flow 3372 identification and described as the Flow-Routing-Information. 3373 Now, this has been renamed Message-Routing-Information, and 3374 identifies a message routing method and any associated 3375 addressing. 3377 7. Modified the text in Section 4.3 and elsewhere to impose sanity 3378 checks on the Message-Routing-Information carried in C-mode 3379 messages, including the case where these messages are part of a 3380 GIMPS-Query/Response exchange. 3382 8. Added rules for message forwarding to prevent message looping in 3383 a new Section 4.3.4, including rules on IP TTL and GIMPS hop 3384 count processing. These take into account the new RAO 3385 considerations of Section 5.3.3. 3387 9. Added an outline mechanism for messaging association protocol 3388 stack negotiation, with the details in a new Section 6.6 and 3389 other changes in Section 4.4 and the various sections on message 3390 formats. 3392 10. Removed the open issue on whether storing reverse routing state 3393 is mandatory or optional. This is now explicit in the API 3394 (under the control of the local NSLP). 3396 11. Added an informative annex describing an abstract API between 3397 GIMPS and NSLPs in Appendix D. 3399 11.6 Changes In Version -01 3401 The major change in version -01 is the elimination of 3402 'intermediaries', i.e. imposing the constraint that signaling 3403 application peers are also GIMPS peers. This has the consequence 3404 that if a signaling application wishes to use two classes of 3405 signaling transport for a given flow, maybe reaching different 3406 subsets of nodes, it must do so by running different signaling 3407 sessions; and it also means that signaling adaptations for passing 3408 through NATs which are not signaling application aware must be 3409 carried out in datagram mode. On the other hand, it allows the 3410 elimination of significant complexity in the connection mode handling 3411 and also various other protocol features (such as general route 3412 recording). 3414 The full set of changes is as follows: 3416 1. Added a worked example in Section 3.5. 3418 2. Stated that nodes which do not implement the signaling 3419 application should bypass the message (Section 4.3). 3421 3. Decoupled the state handling logic for routing state and 3422 messaging association state in Section 4.4. Also, allow 3423 messaging associations to be used immediately in both directions 3424 once they are opened. 3426 4. Added simple ABNF for the various GIMPS message types in a new 3427 Section 5.1, and more details of the common header and each 3428 object in Section 5.2, including bit formats in Appendix C. The 3429 common header format means that the encapsulation is now the 3430 same for all transport types (Section 5.4.1). 3432 5. Added some further details on datagram mode encapsulation in 3433 Section 5.3, including more explanation of why a well known port 3434 is needed. 3436 6. Removed the possibility for fragmentation over DCCP 3437 (Section 5.4.1), mainly in the interests of simplicity and loss 3438 amplification. 3440 7. Removed all the tunnel mode encapsulations (old sections 5.3.3 3441 and 5.3.4). 3443 8. Fully re-wrote the route change handling description 3444 (Section 7.1), including some additional detection mechanisms 3445 and more clearly distinguishing between upstream and downstream 3446 route changes. Included further details on GIMPS/NSLP 3447 interactions, including where notifications are delivered and 3448 how local repair storms could be avoided. Removed old 3449 discussion of propagating notifications through signaling 3450 application unaware nodes (since these are now bypassed 3451 automatically). Added discussion on how to route messages for 3452 local state removal on the old path. 3454 9. Revised discussion of policy-based forwarding (Section 7.2) to 3455 account for actual FLow-Routing-Information definition, and also 3456 how wildcarding should be allowed and handled. 3458 10. Removed old route recording section (old Section 6.3). 3460 11. Extended the discussion of NAT handling (Section 7.3) with an 3461 extended outline on processing rules at a GIMPS-aware NAT and a 3462 pointer to implications for C-mode processing and state 3463 management. 3465 12. Clarified the definition of 'correct routing' of signaling 3466 messages in Section 8 and GIMPS role in enforcing this. Also, 3467 opened the possibility that peer node authentication could be 3468 signaling application dependent. 3470 13. Removed old open issues on Connection Mode Encapsulation 3471 (section 8.7); added new open issues on Message Routing (old 3472 Section 9.3 of version -05, later moved to Section 3.3) and 3473 Datagram Mode congestion control. 3475 14. Added this change history. 3477 12. References 3479 12.1 Normative References 3481 [1] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 3483 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3484 Levels", BCP 14, RFC 2119, March 1997. 3486 [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3487 Specifications: ABNF", RFC 2234, November 1997. 3489 [4] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 3490 RFC 2711, October 1999. 3492 [5] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 3493 RFC 2765, February 2000. 3495 [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 3496 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, 3497 "Stream Control Transmission Protocol", RFC 2960, October 2000. 3499 [7] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 3500 draft-ietf-dccp-spec-11 (work in progress), March 2005. 3502 [8] Conta, A., "Internet Control Message Protocol (ICMPv6)for the 3503 Internet Protocol Version 6 (IPv6) Specification", 3504 draft-ietf-ipngwg-icmp-v3-06 (work in progress), November 2004. 3506 12.2 Informative References 3508 [9] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 3509 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 3510 Specification", RFC 2205, September 1997. 3512 [10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 3513 RFC 2409, November 1998. 3515 [11] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP 3516 Operation Over IP Tunnels", RFC 2746, January 2000. 3518 [12] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 3519 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 3521 [13] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 3522 IPv4 Clouds", RFC 3056, February 2001. 3524 [14] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 3525 RFC 3068, June 2001. 3527 [15] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 3528 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 3529 September 2001. 3531 [16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 3532 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 3533 Session Initiation Protocol", RFC 3261, June 2002. 3535 [17] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 3536 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 3537 RFC 3320, January 2003. 3539 [18] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 3540 Haukka, "Security Mechanism Agreement for the Session 3541 Initiation Protocol (SIP)", RFC 3329, January 2003. 3543 [19] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 3544 - Simple Traversal of User Datagram Protocol (UDP) Through 3545 Network Address Translators (NATs)", RFC 3489, March 2003. 3547 [20] Hancock, R., "Next Steps in Signaling: Framework", 3548 draft-ietf-nsis-fw-07 (work in progress), December 2004. 3550 [21] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 3551 draft-ietf-nsis-threats-06 (work in progress), October 2004. 3553 [22] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 3554 (NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in progress), 3555 May 2005. 3557 [23] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality- 3558 of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in 3559 progress), February 2005. 3561 [24] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 3562 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 (work in 3563 progress), March 2005. 3565 [25] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 3566 draft-ietf-secsh-architecture-22 (work in progress), 3567 March 2005. 3569 [26] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-02 3570 (work in progress), February 2005. 3572 [27] Nikander, P., "Mobile IP version 6 Route Optimization Security 3573 Design Background", draft-ietf-mip6-ro-sec-02 (work in 3574 progress), October 2004. 3576 [28] Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism 3577 (DSTM)", draft-bound-dstm-exp-02 (work in progress), 3578 January 2005. 3580 [29] Stiemerling, M., "Loose End Message Routing Method for NATFW 3581 NSLP", draft-stiemerling-nsis-natfw-mrm-01 (work in progress), 3582 February 2005. 3584 Authors' Addresses 3586 Henning Schulzrinne 3587 Columbia University 3588 Department of Computer Science 3589 450 Computer Science Building 3590 New York, NY 10027 3591 US 3593 Phone: +1 212 939 7042 3594 Email: hgs+nsis@cs.columbia.edu 3595 URI: http://www.cs.columbia.edu 3597 Robert Hancock 3598 Siemens/Roke Manor Research 3599 Old Salisbury Lane 3600 Romsey, Hampshire SO51 0ZN 3601 UK 3603 Email: robert.hancock@roke.co.uk 3604 URI: http://www.roke.co.uk 3606 Appendix A. Acknowledgements 3608 This document is based on the discussions within the IETF NSIS 3609 working group. It has been informed by prior work and formal and 3610 informal inputs from: Cedric Aoun, Attila Bader, Bob Braden, Marcus 3611 Brunner, Pasi Eronen, Xiaoming Fu, Ruediger Geib, Eleanor Hepworth, 3612 Cheng Hong, Georgios Karagiannis, Chris Lang, John Loughney, Allison 3613 Mankin, Jukka Manner, Pete McCann, Andrew McDonald, Glenn Morrow, 3614 Dave Oran, Tom Phelan, Takako Sanda, Charles Shen, Melinda Shore, 3615 Martin Stiemerling, Mike Thomas, Hannes Tschofenig, Sven van den 3616 Bosch, Michael Welzl, and Lars Westberg. In particular, Hannes 3617 Tschofenig provided a detailed set of review comments on the security 3618 section, and Andrew McDonald provided the formal description for the 3619 initial packet formats. Chris Lang's implementation work provided 3620 objective feedback on the clarity and feasibility of the 3621 specification. We look forward to inputs and comments from many more 3622 in the future. 3624 Appendix B. Example Message Routing State Table 3626 Figure 10 shows a signaling scenario for a single flow being managed 3627 by two signaling applications using the path-coupled message routing 3628 method. The flow sender and receiver and one router support both, 3629 two other routers support one each. 3631 A B C D E 3632 +------+ +-----+ +-----+ +-----+ +--------+ 3633 | Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow | 3634 |Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver| 3635 | | +-+ +-+ |GIMPS| |GIMPS| |GIMPS| | | 3636 +------+ +-----+ +-----+ +-----+ +--------+ 3638 ------------------------------>> 3639 Flow Direction 3641 Figure 10: A Signaling Scenario 3643 The routing state table at node B is as follows: 3645 +--------------------+----------+----------+----------+-------------+ 3646 | Message Routing | Session | NSLP ID | Response | Query | 3647 | Information | ID | | Directio | Direction | 3648 | | | | n | | 3649 +--------------------+----------+----------+----------+-------------+ 3650 | Method = Path | 0xABCD | NSLP1 | IP-#A | (null) | 3651 | Coupled; Flow ID = | | | | | 3652 | {IP-#A, IP-#E, | | | | | 3653 | protocol, ports} | | | | | 3654 | | | | | | 3655 | Method = Path | 0x1234 | NSLP2 | IP-#A | Pointer to | 3656 | Coupled; Flow ID = | | | | B-D | 3657 | {IP-#A, IP-#E, | | | | messaging | 3658 | protocol, ports} | | | | association | 3659 +--------------------+----------+----------+----------+-------------+ 3661 The Response direction state is just the same address for each 3662 application. For the Query direction, NSLP1 only requires datagram 3663 mode messages and so no explicit routing state towards C is needed. 3664 NSLP2 requires a messaging association for its messages towards node 3665 D, and node C does not process NSLP2 at all, so the peer state for 3666 NSLP2 is a pointer to a messaging association that runs directly from 3667 B to D. Note that E is not visible in the state table (except 3668 implicitly in the address in the message routing information); 3669 routing state is stored only for adjacent peers. (In addition to the 3670 peer identification, IP hop counts are stored for each peer where the 3671 state itself if not null; this is not shown in the table.) 3673 Appendix C. Bit-Level Formats 3675 This appendix provides initial formats for the various component 3676 parts of the GIMPS messages defined abstractly in Section 5.2. It 3677 should be noted that these formats are extremely preliminary and 3678 should be expected to change completely several times during the 3679 further development of this specification. 3681 C.1 General GIMPS Formatting Guidelines 3683 Each GIMPS message consists of a header and a sequence of objects. 3684 The GIMPS header has a specific format, described in more detail in 3685 Appendix C.2 below. An NSLP message is one object within a GIMPS 3686 message. Note that GIMPS provides the message length information and 3687 signaling application identification. 3689 Every object has the following general format: 3691 o The overall format is Type-Length-Value (in that order). 3693 o Some parts of the type field are set aside for control flags which 3694 define how unknown types should be handled; this is discussed in 3695 Appendix C.3.2. 3697 o Length has the units of 32 bit words, and measures the length of 3698 Value. If there is no Value, Length=0. 3700 o Value is (therefore) a whole number of 32 bit words. If there is 3701 any padding required, the length and location must be defined by 3702 the object-specific format information; objects which contain 3703 variable length (e.g. string) types may need to include additional 3704 length subfields to do so. 3706 o Any part of the object used for padding or defined as reserved 3707 must be set to 0 on transmission and must be ignored on reception. 3709 C.2 The GIMPS Common Header 3711 This header precedes all GIMPS messages. It has a fixed format, as 3712 shown below. 3714 0 1 2 3 3715 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 3716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3717 | Version | GIMPS hops | Message length | 3718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3719 | Signaling Application ID | Type |S|R| Reserved | 3720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3722 Message length = the total number of words in the message after 3723 the common header itself 3724 Type = the GIMPS message type (Query, Response, etc.) 3725 S flag = set if the IP source address is the signaling 3726 source address, clear if it was derived from the 3727 MRI 3728 R flag = set if a response to this message is explicitly 3729 requested 3731 C.3 General Object Characteristics 3733 C.3.1 TLV Header 3735 Each object begins with a fixed header giving the object type and 3736 object length. The bits marked 'A' and 'B' are extensibility flags 3737 which are defined below; the remaining bits marked 'r' are reserved. 3739 0 1 2 3 3740 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 3741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3742 |A|B|r|r| Type |r|r|r|r| Length | 3743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3745 C.3.2 Object Extensibility 3747 The leading two bits of the common TLV header are used to signal the 3748 desired treatment for objects whose treatment has not been defined in 3749 the protocol specification in question (i.e. whose Type field is 3750 unknown at the receiver). The following four categories of object 3751 have been identified, and are loosely described here. 3753 AB=00 ("Mandatory"): If the object is not understood, the entire 3754 message containing it must be rejected with an error indication. 3756 AB=01 ("Ignore"): If the object is not understood, it should be 3757 deleted and then the rest of the message processed as usual. 3759 AB=10 ("Forward"): If the object is not understood, it should be 3760 retained unchanged in any message forwarded as a result of message 3761 processing, but not stored locally. 3763 The combination AB=11 is reserved. Note that the concept of 3764 retaining an unknown object and including it in refresh messages 3765 further up or down the signalling path does not apply to GIMPS, since 3766 refresh operations only take place between adjacent peers. 3768 C.4 GIMPS TLV Objects 3770 In the following object diagrams, '//' is used to indicate a variable 3771 sized field and ':' is used to indicate a field that is optionally 3772 present. 3774 C.4.1 Message-Routing-Information 3776 Type: Message-Routing-Information 3778 Length: Variable (depends on message routing method) 3780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3781 | Message-Routing-Method | | 3782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 3783 // Method-specific addressing information (variable) // 3784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3786 C.4.1.1 Path-Coupled MRM 3788 In the case of basic path-coupled routing, the addressing information 3789 takes the following format: 3791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3792 |IP-Ver |P|T|F|S|A|B|D|Reserved | 3793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3794 // Source Address // 3795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3796 // Destination Address // 3797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3798 | Source Prefix | Dest Prefix | Protocol | Traffic Class | 3799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3800 : Reserved | Flow Label : 3801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3802 : SPI : 3803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3804 : Source Port : Destination Port : 3805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3807 The flags are: 3808 P - IP Protocol 3809 T - Traffic Class 3810 F - Flow Label 3811 S - SPI 3812 A - Source Port 3813 B - Destination Port 3814 D - Direction of message relative to MRI 3816 The contents of the Protocol field is only interpreted if P is set. 3817 The contents of the Traffic Class field is only interpreted if T is 3818 set. The S/A/B flags can only be set if P is set. 3820 F may only be set if IP-Ver is 6. If F is not set, the entire 32 bit 3821 word for the FLow Label is absent. 3823 If either of A, B is set, the word containing the port numbers is 3824 included in the object. However, the contents of each field is only 3825 significant if the corresponding flag is set; otherwise, the contents 3826 of the field is regarded as padding, and the MRI refers to all ports 3827 (i.e. acts as a wildcard). If the flag is set and Port=0x0000, the 3828 MRI will apply to a specific port, whose value is not yet known. If 3829 neither of A or B is set, the word is absent. 3831 Likewise, the SPI field is only present if the S flag is set. 3833 The Direction flag has the following meaning: the value 0 means 'in 3834 the same direction as the flow' (or "downstream"), and the value 1 3835 means 'in the opposite direction to the flow' (or "upstream"). 3837 C.4.2 Session Identification 3839 Type: Session-Identification 3841 Length: Fixed (4 32-bit words) 3843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3844 | | 3845 + + 3846 | | 3847 + Session ID + 3848 | | 3849 + + 3850 | | 3851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3853 C.4.3 Network-Layer-Information 3855 Type: Network-Layer-Information 3857 Length: Variable (depends on length of Peer-Identity and IP version) 3859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3860 | PI-Length | IP-TTL |IP-Ver | Reserved | 3861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3862 | Routing State Validity Time | 3863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3864 // Peer Identity // 3865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3866 // Interface Address // 3867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3869 PI-Length = the byte length of the Peer-Identity field 3870 (note that the Peer-Identity field itself is padded 3871 to a whole number of words) 3872 IP-TTL = initial or reported IP-TTL 3873 IP-Ver = the IP version for the Interface-Address field 3875 C.4.4 Stack Proposal 3877 Type: Stack-Proposal 3878 Length: Variable (depends on number of profiles and size of each 3879 profile) 3881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3882 | Prof-Count | Reserved | 3883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3884 // Profile 1 // 3885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3886 : : 3887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3888 // Profile 2 // 3889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3891 Prof-Count = The number of profiles in the proposal 3893 Each profile is itself a sequence of protocol layers, and the profile 3894 is formatted as a list as follows: 3896 o The first byte is a count of the number of layers in the profile. 3898 o This is followed by a sequence of 1-byte MA-Protocol-IDs as 3899 described in Section 5.6. 3901 o The profile is padded to a word boundary with 0, 1, 2 or 3 zero 3902 bytes. 3904 C.4.5 Stack-Configuration-Data 3906 Type: Stack-Configuration-Data 3908 Length: Variable (depends on number of protocols and size of each 3909 protocol configuration data) 3911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3912 | HL-Count | Reserved | 3913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3914 // Higher-Layer-Information 1 // 3915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3916 : : 3917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3918 // Higher-Layer-Information N // 3919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3920 HL-Count = the number of higher-layer-information fields 3921 (these contain their own length information) 3923 The higher layer information fields are formatted as follows: 3925 o There is a 1-byte MA-Protocol-ID, as described in Section 5.6. 3927 o There is a 1-byte length field defining the amount of 3928 configuration data that follows after the length field. 3930 o There is a variable length of configuration data. 3932 o There are 0, 1, 2, or 3 bytes of zero padding to the next word 3933 boundary. 3935 Note that the contents of the configuration data may differ depending 3936 on whether the object is in a GIMPS-Query or GIMPS-Response. 3938 C.4.6 Query Cookie 3940 Type: Query-Cookie 3942 Length: Variable (selected by querying node) 3944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3945 | | 3946 // Query Cookie // 3947 | | 3948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3950 The contents are implementation defined. See Section 8.5 for further 3951 discussion. 3953 C.4.7 Responder Cookie 3955 Type: Responder-Cookie 3957 Length: Variable (selected by responding node) 3959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3960 | | 3961 // Responder Cookie // 3962 | | 3963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3965 The contents are implementation defined. See Section 8.5 for further 3966 discussion. 3968 C.4.8 NAT Traversal 3970 Type: NAT-Traversal 3972 Length: Variable (depends on length of contained fields) 3974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3975 | MRI-Length | Type-Count | NAT-Count | Reserved | 3976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3977 // Original Message-Routing-Information // 3978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3979 // List of translated objects // 3980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3981 | Length of opaque NLI info. | | 3982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 3983 // NLI information replaced by NAT #1 | 3984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3985 : : 3986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3987 | Length of opaque NLI info. | | 3988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 3989 // NLI information replaced by NAT #N | 3990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3992 MRI-Length = the word length of the included MRI payload 3993 Type-Count = the number of GIMPS payloads translated by the 3994 NAT; the Type numbers are included as a list 3995 (padded with 2 null bytes if necessary) 3996 NAT-Count = the number of NATs traversed by the message, and the 3997 number of opaque NLI-related payloads at the end 3998 of the object 4000 C.4.9 NSLP Data 4002 Type: NSLP-Data 4004 Length: Variable (depends on NSLP) 4006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4007 | | 4008 // NSLP Data // 4009 | | 4010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4012 C.4.10 Error Object 4014 Type: Error 4016 Length: Variable (depends on error) 4018 Value: Contains a 1 byte error class and 3 byte error code, and 4019 optionally variable length error-specific information. 4021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4022 | Error Class | Error Code | 4023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4024 // Optional error-specific information // 4025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4027 The first byte "Error Class" indicates the severity level. The 4028 currently defined severity levels are: 4030 Informational: response data which should not be thought of as 4031 changing the condition of the protocol state machine. 4033 Success: response data which indicates that the message being 4034 responded to has been processed successfully in some sense. 4036 Protocol-Error: the message has been rejected because of a protocol 4037 error (e.g. an error in message format). 4039 Transient-Failure: the message has been rejected because of a 4040 particular local node status which may be transient (i.e. it may 4041 be worthwhile to retry after some delay). 4043 Permanent-Failure: the message has been rejected because of local 4044 node status which will not change without additional out of band 4045 (e.g. management) operations. 4047 Additional error class values are reserved. 4049 The allocation of error classes to particular errors is not precise; 4050 the above descriptions are deliberately informal. Actually error 4051 processing should take into account the specific error in question; 4052 the error class may be useful supporting information (e.g. in network 4053 debugging). 4055 Appendix D. API between GIMPS and NSLP 4057 D.1 API Concepts 4059 This appendix provides an initial abstract API between GIMPS and 4060 NSLPs. 4062 This does not constrain implementors, but rather helps clarify the 4063 interface between the different layers of the NSIS protocol suite. 4064 In addition, although some of the data types carry the information 4065 from GIMPS Information Elements, this does not imply that the format 4066 of that data as sent over the API has to be the same. 4068 Conceptually the API has similarities to the UDP sockets API, 4069 particularly that for unconnected UDP sockets. An extension for an 4070 API like that for UDP connected sockets could be considered. In this 4071 case, for example, the only information needed in a SendMessage 4072 primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle 4073 (which can be null). Other information which was persistent for a 4074 group of messages could be configured once for the socket. Such 4075 extensions may make a concrete implementation more scalable and 4076 efficient but do not change the API semantics, and so are not 4077 considered further here. 4079 D.2 SendMessage 4081 This primitive is passed from an NSLP to GIMPS. It is used whenever 4082 the NSLP wants to send a message. 4084 SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, 4085 NSLP-Id, Session-ID, MRI, 4086 Source-SII-Handle, Peer-SII-Handle, 4087 Transfer-Attributes, Timeout, IP-TTL ) 4089 The following arguments are mandatory. 4091 NSLP-Data: The NSLP message itself. 4093 NSLP-Data-Size: The length of NSLP-Data. 4095 NSLP-Message-Handle: A handle for this message, that can be used 4096 later by GIMPS to reference it in status reports (in particular, 4097 notification about what security attributes will be used for the 4098 message, or error notifications). A NULL handle may be supplied 4099 if the NSLP is not interested in receiving MessageStatus 4100 notifications for this message. 4102 NSLP-Id: An identifier indicating which NSLP this is. 4104 Session-ID: The NSIS session identifier. Note that it is assumed 4105 that the signaling application provides this to GIMPS rather than 4106 GIMPS providing a value itself. 4108 MRI: Message routing information for use by GIMPS in determining the 4109 correct next GIMPS hop for this message. It contains, for 4110 example, the flow source/destination addresses and the type of 4111 routing to use for the signaling message. The message routing 4112 information implies the message routing method to be used and also 4113 includes the direction of the message. 4115 The following arguments are optional. 4117 Source-SII-Handle: A handle, previously supplied by GIMPS in 4118 RecvMessage, which indicates that the NSLP wishes to originate the 4119 message as though it came from the identified source (e.g. so 4120 responses will be returned to that source). Will cause an error 4121 if set with a large payload or non-trivial Transfer-Attributes. 4123 Peer-SII-Handle: A handle, previously supplied by GIMPS, to a data 4124 structure (identifying peer addresses and interfaces) that should 4125 be used to explicitly route the message to a particular GIMPS next 4126 hop. If supplied, GIMPS should validate that it is consistent 4127 with the MRI. 4129 Transfer-Attributes: Attributes defining how the message should be 4130 handled (see Section 4.1.2). The following attributes can be 4131 considered: 4133 Reliability: Values 'unreliable' (default) or 'reliable'. 4135 Security: This attribute allows the NSLP to specify what level of 4136 security protection is requested for the message (selected from 4137 'integrity' and 'confidentiality'), and can also be used to 4138 specify what authenticated signaling source and destination 4139 identities should be used to send the message. The 4140 possibilities can be learned by the NSLP from prior 4141 MessageStatus or RecvMessage notifications. If an NSLP- 4142 Message-Handle is provided, GIMPS will inform the NSLP of what 4143 values it has actually chosen for this attribute via a 4144 MessageStatus callback. This might take place either 4145 synchronously (where GIMPS is just selecting from available 4146 messaging associations), or asynchronously (when a new 4147 messaging association needs to be created). 4149 Local Processing: This attribute contains hints from the NSLP 4150 about what local policy should be applied to the message; in 4151 particular, its transmission priority relative to other 4152 messages, or whether GIMPS should attempt to set up or maintain 4153 forward routing state. 4155 Timeout: Length of time GIMPS should attempt to send this message 4156 before indicating an error. 4158 IP-TTL: The value of the IP TTL that should be used when sending this 4159 message. 4161 D.3 RecvMessage 4163 This primitive is passed from GIMPS to an NSLP. It is used whenever 4164 GIMPS receives a message from the network. This primitive can return 4165 a value from the NSLP which indicates whether the NSLP wishes GIMPS 4166 to retain message routing state. 4168 RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Id, Session-ID, MRI, 4169 SII-Handle, Transfer-Attributes, IP-TTL, IP-Distance ) 4171 NSLP-Data: The NSLP message itself (may be empty). 4173 NSLP-Data-Size: The length of NSLP-Data (may be zero). 4175 NSLP-Id: An identifier indicating which NSLP this is message is for. 4177 Session-ID: The NSIS session identifier. 4179 MRI: Message routing information that was used by GIMPS in forwarding 4180 this message. It contains, for example, the flow source/ 4181 destination addresses, the type of routing used for the signaling 4182 message, and the direction of the message relative to the MRI. 4183 Implicitly defines the message routing method that was used. 4185 SII-Handle: A handle to a data structure, identifying peer addresses 4186 and interfaces. Can be used to identify route changes and for 4187 explicit routing to a particular GIMPS next hop. 4189 Transfer-Attributes: The reliability and security attributes that 4190 were associated with the reception of this particular message. As 4191 well as the attributes associated with SendMessage, GIMPS may 4192 indicate the level of verification of the addresses in the MRI. 4193 Two flags can be indicated: 4195 * Whether the signalling source address is one of the flow 4196 endpoints (i.e. whether this is the first or last GIMPS hop); 4198 * Whether the signalling source address has been validated by a 4199 return routability check. 4201 IP-TTL: The value of the IP TTL (or Hop Limit) this message was 4202 received with (if available). 4204 IP-Distance: The number of IP hops from the peer signaling node which 4205 sent this message along the path, or 0 if this information is not 4206 available. 4208 D.4 MessageStatus 4210 This primitive is passed from GIMPS to an NSLP. It is used to notify 4211 the NSLP that a message that it requested to be sent has failed to be 4212 dispatched, or to inform the NSLP about the transfer attributes that 4213 have been selected for the message (specifically, security 4214 attributes). The NSLP can respond to this message with a return code 4215 to abort the sending of the message if the attributes are not 4216 acceptable. 4218 MessageStatus ( NSLP-Message-Handle, Transfer-Attributes, Error-Type ) 4220 NSLP-Message-Handle: A handle for the message provided by the NSLP at 4221 the time of sending. 4223 Transfer-Attributes: The reliability and security attributes that 4224 will be used to transmit this particular message. 4226 Error-Type: Indicates the type of error that occurred. For example, 4227 'no next node found'. 4229 D.5 NetworkNotification 4231 This primitive is passed from GIMPS to an NSLP. It indicates that a 4232 network event of possible interest to the NSLP occurred. 4234 NetworkNotification ( MRI, Network-Notification-Type ) 4236 MRI: Provides the message routing information to which the network 4237 notification applies. 4239 Network-Notification-Type: Indicates the type of event that caused 4240 the notification, e.g. downstream route change, upstream route 4241 change, detection that this is the last node. 4243 D.6 SetStateLifetime 4245 This primitive is passed from an NSLP to GIMPS. It indicates the 4246 lifetime for which GIMPS should retain its state. It can also give a 4247 hint that the NSLP is no longer interested in the state. 4249 SetStateLifetime ( MRI, Direction, State-Lifetime ) 4251 MRI: Provides the message routing information to which the network 4252 notification applies. 4254 Direction: A flag indicating whether this relates to state for the 4255 upstream or downstream direction (in relation to the MRI). 4257 State-Lifetime: Indicates the lifetime for which the NSLP wishes 4258 GIMPS to retain its state (may be zero, indicating that the NSLP 4259 has no further interest in the GIMPS state). 4261 D.7 InvalidateRoutingState 4263 This primitive is passed from an NSLP to GIMPS. It indicates that 4264 the NSLP has knowledge that the next signaling hop known to GIMPS may 4265 no longer be valid, either because of changes in the network routing 4266 or the processing capabilities of NSLP nodes. It is an indication to 4267 GIMPS to restart the discovery process. 4269 InvalidateRoutingState ( NSLP-Id, MRI, Direction, Urgency ) 4271 NSLP-Id: The NSLP originating the message. May be null (in which 4272 case the invalidation applies to all signaling applications). 4274 MRI: The flow for which routing state should be invalidated. 4276 Direction: A flag indicating whether this relates to state for the 4277 upstream or downstream direction (in relation to the MRI). 4279 Urgency: A hint as to whether rediscovery should take place 4280 immediately, or only when the next signaling message is to be 4281 sent. 4283 Intellectual Property Statement 4285 The IETF takes no position regarding the validity or scope of any 4286 Intellectual Property Rights or other rights that might be claimed to 4287 pertain to the implementation or use of the technology described in 4288 this document or the extent to which any license under such rights 4289 might or might not be available; nor does it represent that it has 4290 made any independent effort to identify any such rights. Information 4291 on the procedures with respect to rights in RFC documents can be 4292 found in BCP 78 and BCP 79. 4294 Copies of IPR disclosures made to the IETF Secretariat and any 4295 assurances of licenses to be made available, or the result of an 4296 attempt made to obtain a general license or permission for the use of 4297 such proprietary rights by implementers or users of this 4298 specification can be obtained from the IETF on-line IPR repository at 4299 http://www.ietf.org/ipr. 4301 The IETF invites any interested party to bring to its attention any 4302 copyrights, patents or patent applications, or other proprietary 4303 rights that may cover technology that may be required to implement 4304 this standard. Please address the information to the IETF at 4305 ietf-ipr@ietf.org. 4307 Disclaimer of Validity 4309 This document and the information contained herein are provided on an 4310 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4311 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4312 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4313 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4314 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4315 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4317 Copyright Statement 4319 Copyright (C) The Internet Society (2005). This document is subject 4320 to the rights, licenses and restrictions contained in BCP 78, and 4321 except as set forth therein, the authors retain all their rights. 4323 Acknowledgment 4325 Funding for the RFC Editor function is currently provided by the 4326 Internet Society.