idnits 2.17.1 draft-ietf-nsis-ntlp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 == Line 639 has weird spacing: '... uuuuuu d>>...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 16, 2004) is 7347 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 184 -- Looks like a reference, but probably isn't: 'Flow' on line 198 == Unused Reference: '8' is defined on line 2373, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 2410, 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-05 -- Obsolete informational reference (is this intentional?): RFC 2463 (ref. '10') (Obsoleted by RFC 4443) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '12') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. '15') (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '19') (Obsoleted by RFC 5389) == Outdated reference: A later version (-07) exists of draft-ietf-nsis-fw-05 == Outdated reference: A later version (-06) exists of draft-ietf-nsis-threats-03 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-00 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-01 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-02 == Outdated reference: A later version (-04) exists of draft-bound-dstm-exp-00 Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Next Steps in Signaling H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: August 16, 2004 R. Hancock 5 Siemens/RMR 6 February 16, 2004 8 GIMPS: General Internet Messaging Protocol for Signaling 9 draft-ietf-nsis-ntlp-01 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document specifies protocol stacks for the routing and transport 38 of per-flow signaling messages along the path taken by that flow 39 through the network. The design uses existing transport and security 40 protocols under a common messaging layer, the General Internet 41 Messaging Protocol for Signaling (GIMPS), which provides a universal 42 service for diverse signaling applications. GIMPS does not handle 43 signaling application state itself, but manages its own internal 44 state and the configuration of the underlying transport and security 45 protocols to enable the transfer of messages in both directions along 46 the flow path. The combination of GIMPS and the lower layer protocols 47 provides a solution for the base protocol component of the "Next 48 Steps in Signaling" framework. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Requirements Notation and Terminology . . . . . . . . . . . 5 54 3. Design Methodology . . . . . . . . . . . . . . . . . . . . . 7 55 3.1 Overall Approach . . . . . . . . . . . . . . . . . . . . . . 7 56 3.2 Design Attributes . . . . . . . . . . . . . . . . . . . . . 9 57 3.3 Example of Operation . . . . . . . . . . . . . . . . . . . . 11 58 4. GIMPS Processing Overview . . . . . . . . . . . . . . . . . 13 59 4.1 GIMPS State . . . . . . . . . . . . . . . . . . . . . . . . 13 60 4.2 Basic Message Processing . . . . . . . . . . . . . . . . . . 14 61 4.3 Routing State and Messaging Association Maintainance . . . . 18 62 5. Message Formats and Encapsulations . . . . . . . . . . . . . 21 63 5.1 GIMPS Messages . . . . . . . . . . . . . . . . . . . . . . . 21 64 5.2 Information Elements . . . . . . . . . . . . . . . . . . . . 22 65 5.3 Encapsulation in Datagram Mode . . . . . . . . . . . . . . . 24 66 5.4 Encapsulation in Connection Mode . . . . . . . . . . . . . . 25 67 6. Advanced Protocol Features . . . . . . . . . . . . . . . . . 27 68 6.1 Route Changes and Local Repair . . . . . . . . . . . . . . . 27 69 6.2 Policy-Based Forwarding and Flow Wildcarding . . . . . . . . 33 70 6.3 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . 33 71 6.4 Interaction with IP Tunnelling . . . . . . . . . . . . . . . 35 72 6.5 IPv4-IPv6 Transition and Interworking . . . . . . . . . . . 35 73 7. Security Considerations . . . . . . . . . . . . . . . . . . 38 74 7.1 Message Confidentiality and Integrity . . . . . . . . . . . 38 75 7.2 Peer Node Authentication . . . . . . . . . . . . . . . . . . 39 76 7.3 Routing State Integrity . . . . . . . . . . . . . . . . . . 39 77 7.4 Denial of Service Prevention . . . . . . . . . . . . . . . . 41 78 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 43 79 8.1 Protocol Naming . . . . . . . . . . . . . . . . . . . . . . 43 80 8.2 General IP Layer Issues . . . . . . . . . . . . . . . . . . 43 81 8.3 Encapsulation and Addressing for Datagram Mode . . . . . . . 43 82 8.4 Intermediate Node Bypass and Router Alert Values . . . . . . 45 83 8.5 Messaging Association Flexibility . . . . . . . . . . . . . 46 84 8.6 Messaging Association Setup Message Sequences . . . . . . . 47 85 8.7 GIMPS State Teardown . . . . . . . . . . . . . . . . . . . . 48 86 8.8 Datagram Mode Retries and Single Shot Message Support . . . 48 87 8.9 GIMPS Support for Message Scoping . . . . . . . . . . . . . 49 88 8.10 Mandatory or Optional Reverse Routing State . . . . . . . . 49 89 8.11 Additional Discovery Mechanisms . . . . . . . . . . . . . . 49 90 8.12 Alternative Message Routing Requirements . . . . . . . . . . 50 91 8.13 Congestion Control in Datagram Mode . . . . . . . . . . . . 50 92 8.14 Protocol Design Details . . . . . . . . . . . . . . . . . . 51 93 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 52 94 9.1 Changes In Version -01 . . . . . . . . . . . . . . . . . . . 52 95 Normative References . . . . . . . . . . . . . . . . . . . . 54 96 Informative References . . . . . . . . . . . . . . . . . . . 55 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 56 99 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 100 B. Example Routing State Table . . . . . . . . . . . . . . . . 58 101 C. Information Element Formats . . . . . . . . . . . . . . . . 59 102 C.1 The Common Header . . . . . . . . . . . . . . . . . . . . . 59 103 C.2 TLV Objects . . . . . . . . . . . . . . . . . . . . . . . . 59 104 Intellectual Property and Copyright Statements . . . . . . . 63 106 1. Introduction 108 Signaling involves the manipulation of state held in network 109 elements. 'Manipulation' could mean setting up, modifying and tearing 110 down state; or it could simply mean the monitoring of state which is 111 managed by other mechanisms. 113 This specification concentrates specifically on the case of 114 "path-coupled" signaling, which involves network elements which are 115 located on the path taken by a particular data flow, possibly 116 including but not limited to the flow endpoints. Indeed, there are 117 almost always more than two participants in a path-coupled-signaling 118 session, although there is no need for every router on the path to 119 participate. Path-coupled signaling thus excludes end-to-end 120 higher-layer application signaling (except as a degenerate case) such 121 as ISUP (telephony signaling for Signaling System #7) messages being 122 transported by SCTP between two nodes. 124 In the context of path-coupled signaling, examples of state 125 management include network resource allocation (for "resource 126 reservation"), firewall configuration, and state used in active 127 networking; examples of state monitoring are the discovery of 128 instantaneous path properties (such as available bandwidth, or 129 cumulative queuing delay). Each of these different uses of 130 path-coupled signaling is referred to as a signaling application. 132 Every signaling application requires a set of state management rules, 133 as well as protocol support to exchange messages along the data path. 134 Several aspects of this support are common to all or a large number 135 of applications, and hence should be developed as a common protocol. 136 The framework given in [20] provides a rationale for a function split 137 between the common and application specific protocols, and gives 138 outline requirements for the former, the 'NSIS Transport Layer 139 Protocol' (NTLP). 141 This specification provides a concrete solution for the NTLP. It is 142 based on the use of existing transport and security protocols under a 143 common messaging layer, the General Internet Messaging Protocol for 144 Signaling (GIMPS). Different signaling applications may make use of 145 different services provided by GIMPS, but GIMPS does not handle 146 signaling application state itself; in that crucial respect, it 147 differs from application signaling protocols such as the control 148 component of FTP, SIP and RTSP. Instead, GIMPS manages its own 149 internal state and the configuration of the underlying transport and 150 security protocols to ensure the transfer of signaling messages on 151 behalf of signaling applications in both directions along the flow 152 path. 154 2. Requirements Notation and Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [2]. 160 The terminology used in this specification is fully defined in this 161 section. The basic entities relevant at the GIMPS level are shown in 162 Figure 1. 164 GIMPS (adjacent) peer nodes 165 IP addresses = Signaling 166 IP address Source/Destination Addresses IP address 167 = Flow (depending on signaling direction) = Flow 168 Source | | Destination 169 Address | | Address 170 V V 171 +--------+ Data +------+ +------+ +--------+ 172 | Flow |-----------|------|-------------|------|-------->| Flow | 173 | Sender | Flow | | | | |Receiver| 174 +--------+ |GIMPS |============>|GIMPS | +--------+ 175 | Node |<============| Node | 176 +------+ Signaling +------+ 177 GN1 Flow GN2 179 >>>>>>>>>>>>>>>>> = Downstream direction 180 <<<<<<<<<<<<<<<<< = Upstream direction 182 Figure 1: Basic Terminology 184 [Data] Flow: A set of packets following a unique path through the 185 network, identified by some fixed combination of header fields. 186 Only unicast, unidirectional flows are considered. 188 Session: A single application layer flow of information for which 189 some network control state information is to be manipulated or 190 monitored. IP mobility may cause the mapping between sessions and 191 flows to change, and IP multihoming may mean there is more than 192 one flow for a given session. 194 [Flow] Sender: The node in the network which is the source of the 195 packets in a flow. Could be a host or a router (if the flow is 196 actually an aggregate). 198 [Flow] Receiver: The node in the network which is the sink for the 199 packets in a flow. 201 Downstream: In the same direction as the data flow. 203 Upstream: In the opposite direction to the data flow. 205 GIMPS Node: Any node along the data path supporting GIMPS (regardless 206 of what signaling applications it supports). 208 Adjacent peer: The next GIMPS node along the data path, in the 209 upstream or downstream direction. Whether two nodes are adjacent 210 is determined implicitly by the GIMPS peer discovery mechanisms; 211 it is possible for adjacencies to 'skip over' intermediate nodes 212 if they have no interest in the signaling messages being 213 exchanged. 215 Datagram mode: A mode of sending GIMPS messages between nodes without 216 using any transport layer state or security protection. Upstream 217 messages are sent UDP encapsulated directly to the signaling 218 destination; downstream messages are sent towards the flow 219 receiver with a router alert option. 221 Connection mode: A mode of sending GIMPS messages directly between 222 nodes using point to point "messaging associations" (see below), 223 i.e. transport protocols and security associations. 225 Messaging association: A single connection between two explicitly 226 identified GIMPS adjacent peers, i.e. between a given signaling 227 source and destination address. A messaging association uses a 228 specific transport protocol and known ports, and may be run over 229 specific network layer security associations, or use a transport 230 layer security association internally. A messaging association is 231 bidirectional. 233 3. Design Methodology 235 3.1 Overall Approach 237 The generic requirements identified in [20] for transport of 238 path-coupled signaling messages are essentially two-fold: 240 "Routing": Determine how to reach the adjacent signaling node along 241 the data path (the GIMPS peer); 243 "Transport": Deliver the signaling information to that peer. 245 To meet the routing requirement, for downstream signaling the node 246 can either use local state information (e.g. gathered during previous 247 signaling exchanges) to determine the identity of the GIMPS peer 248 explicitly, or it can just send the signaling towards the flow 249 destination address and rely on the peer to intercept it. For 250 upstream signaling, only the first technique is possible. 252 Once the routing decision has been made, the node has to select a 253 mechanism for transport of the message to the peer. GIMPS divides the 254 transport problems into two categories, the easy and the difficult 255 ones. It handles the easy cases within GIMPS itself, avoiding 256 complexity and latency, while drawing on the services of 257 well-understood reliable transport protocols for the harder cases. 258 Here, with details discussed later, "easy" messages are those that 259 are sized well below the lowest MTU along a path, are infrequent 260 enough not to cause concerns about congestion and flow control, and 261 do not need transport or network-layer security protection. 263 However, in many cases, signaling information needs to be delivered 264 between GIMPS peers with additional transport or security properties. 265 For example, some applications could implement their own reliability 266 mechanism, but experience with RSVP has shown [13] that relying 267 solely on soft-state refreshes itself may yield unsatisfactory 268 performance if signaling messages are lost even occasionally. The 269 provision of this type of reliability would therefore also be the 270 responsibility of the underlying transport protocols. 272 In [20] all of these routing and transport requirements are assigned 273 to a single notional protocol, the 'NSIS Transport Layer Protocol' 274 (NTLP). The strategy of splitting the transport problem leads to a 275 layered structure for the NTLP, as a specialised GIMPS 'messaging' 276 layer running over standard transport and security protocols, as 277 shown in Figure 2. 279 For efficiency, GIMPS offers two modes of transport operation: 281 Datagram mode: for small, infrequent messages with modest delay 282 constraints; 284 Connection mode: for larger data objects or where fast setup in the 285 face of packet loss is desirable, or where channel security is 286 required. 288 ^^ +-------------+ 289 || | Signaling | 290 || +------------|Application 2| 291 || | Signaling +-------------+ 292 NSIS |Application 1| | 293 Signaling +-------------+ | 294 Application | +-------------+ | 295 Level | | Signaling | | 296 || | |Application 3| | 297 || | +-------------+ | 298 VV | | | 299 =======================|==========|========|======================= 300 ^^ +------------------------------------------------+ 301 || |+-----------------------+ +--------------+ | 302 || || GIMPS | | GIMPS | | 303 || || Encapsulation | |Internal State| | 304 || || |<<<>>>| Maintenance | | 305 || |+-----------------------+ +--------------+ | 306 || |GIMPS: Messaging Layer | 307 || +------------------------------------------------+ 308 NSIS | | | | 309 Transport ............................. 310 Level . Transport Layer Security . 311 ("NTLP") ............................. 312 || | | | | 313 || +----+ +----+ +----+ +----+ 314 || |UDP | |TCP | |SCTP| |DCCP|.... 315 || +----+ +----+ +----+ +----+ 316 || | | | | 317 || ............................. 318 || . IP Layer Security . 319 || ............................. 320 VV | | | | 321 =========================|=======|=======|=======|=============== 322 | | | | 323 +----------------------------------------------+ 324 | IP | 325 +----------------------------------------------+ 327 Figure 2: Protocol Stacks for Signaling Transport 329 The datagram mode uses a lower-layer unreliable unsecured datagram 330 transport mechanism, with UDP as the initial choice. The connection 331 mode can use any stream or message-oriented transport protocol. It 332 may employ specific network layer security associations (e.g. IPsec), 333 or an internal transport layer security association (e.g. TLS). 335 It is possible to mix these two modes along a chain of nodes, without 336 coordination or manual configuration. This allows, for example, the 337 use of datagram mode at the edges of the network and connection mode 338 in the core of the network. Such combinations may make operation 339 more efficient for mobile endpoints, while allowing multiplexing of 340 signaling messages across shared security associations and transport 341 connections between core routers. 343 It must be understood that the routing and transport decisions made 344 by GIMPS are not totally independent. If the message transfer has 345 requirements that enforce the use of connection mode (e.g. because 346 fragmentation is required), this can only be used between explicitly 347 identified nodes. In such cases, the GIMPS node must carry out 348 signaling in datagram mode to identify the peer and then set up the 349 necessary transport connection. The datagram mode option of sending 350 the message in the direction of the flow receiver and relying on 351 interception is not available, even for downstream signaling. 353 In general, the state associated with connection mode messaging to a 354 particular peer (signaling destination address, protocol and port 355 numbers, internal protocol configuration and state information) is 356 referred to as a "messaging association". There may be any number of 357 messaging associations between two GIMPS peers (although the usual 358 case is 0 or 1), and they are set up and torn down by managment 359 actions within GIMPS itself. 361 3.2 Design Attributes 363 Soft state: All parts of GIMPS state are subject to time-out 364 ("soft-state"). Explicit removal is also logically possible (see 365 Section 8.7). 'State' here includes the messaging associations 366 managed by GIMPS. 368 Application-neutral: GIMPS is designed to support the largest range 369 of signaling applications. While a number of such applications 370 have been identified, it appears likely that new ones will emerge. 372 Mobility support: End systems can change their network attachment 373 point and network address during a session. GIMPS minimises the 374 use of IP addresses as identifiers for non-topological information 375 (e.g. authentication state). 377 Efficient: Signaling often occurs before an application such as an IP 378 telephone conversation can commence, so that any signaling delay 379 becomes noticeable to the application. Signaling delays are 380 incurred by the delay in finding signaling nodes along the path 381 (peer discovery), in retransmitting lost signaling messages and in 382 setting up security associations between nodes, among other 383 factors. GIMPS attempts to minimise these delays by several 384 mechanisms, such as the use of high performance transport 385 protocols to circumvent message loss, and the re-use of messaging 386 associations to avoid setup latency. If discovery is needed it is 387 a lightweight process which only probes local topology, and GIMPS 388 also allows it to be bypassed completely for downstream datagram 389 mode messages. 391 IP version neutral: GIMPS supports both IPv4 and IPv6: it can use 392 either for transport, largely as a result of their support in the 393 underlying transport protocols, and can signal for either type of 394 flow. In addition, GIMPS is able to operate on dual-stack nodes 395 (to bridge between v4 and v6 regions) and also to operate across 396 v4/v6 boundaries and other addressing boundaries. Specific 397 transition issues are considered in Section 6.5. 399 Transport neutral: GIMPS can operate over any message or 400 stream-oriented transport layer, including UDP, DCCP, TCP and 401 SCTP. Messages sent over protocols that do not offer a native 402 fragmentation service, such as UDP or DCCP, are strictly limited 403 in size to avoid loss-amplification; in the case of UDP, they must 404 also be limited in rate to avoid network congestion. 406 Proxy support: The end systems in a session may not be capable of 407 handling either the signaling transport or the application and may 408 instead rely on proxies to initiate and terminate signaling 409 sessions. GIMPS decouples the operation of the messaging functions 410 from the flow source and destination addresses, treating these 411 primarily as data. 413 Scaleable: As will be discussed in Section 4.3, up to one messaging 414 association is generally kept for each adjacent GIMPS peer and 415 thus association state scales better than the number of sessions. 416 (Many peers may not have association state at all, if there are no 417 messages on sessions visiting those nodes that warrant such 418 treatment.) Messaging associations are managed based on policy at 419 each node, depending on trade-offs between fast peer-to-peer 420 communication and state overhead. Messaging association state can 421 be removed immediately after the last signaling session to a 422 particular next-hop is removed, after some delay to wait for new 423 sessions or only if resource demands warrant it. 425 3.3 Example of Operation 427 This section presents an example of GIMPS usage in a relatively 428 simple signaling scenario, to illustrate its main features. 430 Consider the case of an RSVP-like signaling application which 431 allocates resources for a flow from sender to receiver; we will 432 consider how GIMPS transfers messages between two adjacent peers 433 along the path, GN1 and GN2 (see Figure 1). In this example, the 434 end-to-end exchange is initiated by the signaling application 435 instance in the sender; we take up the story at the point where the 436 first message has been received by the signaling application in GN1. 438 1. The signaling application in GN1 determines that this message is 439 a simple description of resources that would be appropriate for 440 the flow. It determines that it has no special security or 441 transport requirements for the message, but simply that it should 442 be transferred to the next downstream signaling application peer 443 on the path that the flow will take. 445 2. The message payload is passed to the GIMPS layer in GN1, along 446 with a definition of the flow and description of the transfer 447 requirements {downstream, unsecured, unreliable}. GIMPS 448 determines that this particular message does not require 449 fragmentation and that it has no knowledge of the next peer for 450 this flow and signaling application; however, it also determines 451 (e.g. from local policy for that signaling application 452 identifier) that this application is likely to require secured 453 upstream and downstream transport of large messages in the 454 future. 456 3. GN1 therefore constructs a UDP datagram with the signaling 457 application payload, and additional payloads at the GIMPS level 458 to be used to initiate the possible setup of a messaging 459 association. This datagram is injected into the network, 460 addressed towards the flow destination and with a Router Alert 461 Option included. 463 4. This D-mode message passes through the network towards the flow 464 receiver, and is seen by each router in turn. GIMPS-unaware 465 routers will not recognise the RAO value and will forward the 466 message unchanged; GIMPS-aware routers which do not support the 467 signaling application in question will also forward the message 468 unchanged, although they may need to process more of the message 469 to decide this. 471 5. The message is finally intercepted at GN2. The GIMPS layer 472 identifies that the message is relevant to a local signaling 473 application, and passes the signaling application payload and 474 flow description to upwards to it. From there, the signaling 475 application in GN2 can continue to process this message as in GN1 476 (compare step 1), and this will eventually result in the message 477 reaching the flow receiver. 479 6. In parallel, GIMPS internally recognises that GN1 is attempting 480 to discover GN2 in order to set up a messaging association for 481 future signaling for the flow. There are two possible cases: 483 A. GN1 and GN2 already have an appropriate association. GN2 484 simply records the identity of GN1 as its upstream peer for 485 that flow and signaling application, and sends a GIMPS 486 message back to GN1 over the association identifying itself. 488 B. No messaging association exists. Again, GN2 records the 489 identity of GN1 as before, but sends an upstream D-mode 490 message to GN1, identifying itself and agreeing to the 491 association setup. The protocol exchanges needed to complete 492 this will proceed in the background, controlled by GN1. 494 7. Eventually, another signaling application message works its way 495 upstream from the receiver to GN2. This message contains a 496 description of the actual resources requested, along with 497 authorisation and other security information. The signaling 498 application in GN2 passes this payload to the GIMPS level, along 499 with the flow definition and transfer requirements {upstream, 500 secured, reliable}. 502 8. The GIMPS layer in GN2 identifies the upstream peer for this flow 503 and signaling application as GN1, and determines that it has a 504 messaging association with the appropriate properties. The 505 message is queued on the association for transmission (this may 506 mean some delay if the negotiations begun in step 6.B have not 507 yet completed). 509 Further messages can be passed in each direction in the same way. The 510 GIMPS layer in each node can in parallel carry out maintenance 511 operations such as route change detection (this can be done by 512 sending additional GIMPS-only datagram mode messages, see Section 6.1 513 for more details). 515 It should be understood that many of these details of GIMPS 516 operations can be varied, either by local policy or according to 517 signaling application requirements, and they are also subject to 518 development and refinement as the protocol design proceeds. The 519 authoritative details are contained in the remainder of this 520 document. 522 4. GIMPS Processing Overview 524 This section defines the basic structure and operation of GIMPS. It 525 is divided into three parts. Section 4.1 gives an overview of the 526 per-flow and per-peer state that GIMPS maintains for the purpose of 527 transferring messages. Section 4.2 describes how messages are 528 processed in the case where any necessary messaging associations and 529 associated routing state already exist; this includes the simple 530 scenario of pure datagram mode operation, where no messaging 531 associations are necessary in the first place (equivalent to the 532 transport functionality of base RSVP as defined in [9]). Section 4.3 533 describes how routing state is maintained and how messaging 534 associations are initiated and terminated. 536 4.1 GIMPS State 538 For each flow, the GIMPS layer can maintain message routing state to 539 manage the processing of outgoing messages. This state is 540 conceptually organised into a table with the following structure. 542 The primary key (index) for the table is the combination of {flow 543 routing info, session id, signaling application id}: 545 Flow: the header N-tuple that determines the route taken by the flow 546 through the network; in particular, including the flow destination 547 address. 549 Session: a cryptographically random and (probabilistically) globally 550 unique identifier of the application layer session that is using 551 the flow. For a given flow, different signaling applications may 552 or may not use the same session identifier. Often there will only 553 be one flow for a given session, but in mobility/multihoming 554 scenarios there may be more than one and they may be differently 555 routed. 557 Signaling application: an IANA assigned identifier of the signaling 558 application which is generating messages for this flow. The 559 inclusion of this identifier allows the routing state to be 560 different for different signaling applications (e.g. because of 561 different adjacencies). 563 The state information for a given key is as follows: 565 Upstream peer: the adjacent GIMPS peer closer to the flow source. 566 This could be an IP address (learned from previous signaling) or a 567 pointer to a messaging association. It could also be null, if this 568 node is the flow sender or this node is not storing reverse 569 routing state, or a special value to indicate that this node is 570 the last upstream node (but not the sender). 572 Downstream peer: the adjacent GIMPS peer closer to the flow 573 destination. This could be a pointer to a messaging association, 574 or it could be null, if this node is the flow receiver or this 575 node is only sending downstream datagram mode messages for this 576 flow and signaling application, or a special value to indicate 577 that this node is the last downstream node (but not the receiver). 579 Note that both the upstream and downstream peer state may be null, 580 and that the session identifier information is not actually required 581 for message processing; in that case, no state information at all 582 needs to be stored in the table. Both items of peer identification 583 state have associated timers for how long the identification can be 584 considered accurate; when these timers expire, the peer 585 identification (IP address or messaging association pointer) is 586 purged if it has not been refreshed. An example of a routing state 587 table for a simple scenario is given in Appendix B. 589 Note also that the information is described as a table of flows, but 590 that there is no implied constraint on how the information is stored. 591 For example, in a network using pure destination address routing 592 (without load sharing or any form of policy-based forwarding), the 593 downstream peer information might be possible to store in an 594 aggregated form in the same manner as the IP forwarding table. In 595 addition, many of the per-flow entries may point to the same per-peer 596 state (e.g. the same messaging association) if the flows go through 597 the same adjacent peer. 599 The per-flow message routing state is not the only state stored by 600 GIMPS. There is also the state implied in the messaging associations. 601 Since we assume that these associations are typically per-peer rather 602 than per-flow, they are stored in a separate table. As well as the 603 messaging association state itself, this table also stores 604 per-association information including: 606 o messages pending transmission while an association is being 607 established; 609 o an inactivity timer for how long the association has been idle. 611 4.2 Basic Message Processing 613 This section describes how signaling application messages are 614 processed in the simple case where any necessary messaging 615 associations and routing state are already in place. The description 616 is divided into several parts: message reception, local processing 617 and delivery to signaling applications, and message transmission. An 618 overview is given in Figure 3. 620 +---------------------------------------------------------+ 621 | >> Signaling Application Processing >> | 622 | | 623 +--------^---------------------------------------V--------+ 624 ^ V 625 ^ NSLP Payloads V 626 ^ V 627 +--------^---------------------------------------V--------+ 628 | >> GIMPS >> | 629 | ^ ^ ^ Processing V V V | 630 +--x-----------u--d---------------------d--u-----------x--+ 631 x u d d u x 632 x u d>>>>>>>>>>>>>>>>>>>>>d u x 633 x u d Bypass at d u x 634 +--x-----+ +--u--d--+ GIMPS level +--d--u--+ +-----x--+ 635 | C-mode | | D-mode | | D-mode | | C-mode | 636 |Handling| |Handling| |Handling| |Handling| 637 +--x-----+ +--u--d--+ +--d--u--+ +-----x--+ 638 x u d d u x 639 x uuuuuu d>>>>>>>>>>>>>>>>>>>>>d uuuuuu x 640 x u d Bypass at d u x 641 +--x--u--+ +-----d--+ router +--d-----+ +--u--x--+ 642 |IP Host | | RAO | alert level | RAO | |IP Host | 643 |Handling| |Handling| |Handling| |Handling| 644 +--x--u--+ +-----d--+ +--d-----+ +--u--x--+ 645 x u d d u x 646 +--x--u-----------d--+ +--d-----------u--x--+ 647 | IP Layer | | IP Layer | 648 | (Receive Side) | | (Transmit Side) | 649 +--x--u-----------d--+ +--d-----------u--x--+ 650 x u d d u x 651 x u d d u x 652 x u d d u x 654 uuuuuuuuuuuuuu = upstream datagram mode messages 655 dddddddddddddd = downstream datagram mode messages 656 xxxxxxxxxxxxxx = connection mode messages 657 RAO = Router Alert Option 659 Figure 3: Message Paths through a GIMPS Node 661 Note that the same messages are used for maintaining internal GIMPS 662 state and carrying signaling application payloads. The state 663 maintenance takes place as a result of processing specific GIMPS 664 payloads in these messages. The processing of these payloads is the 665 subject of Section 4.3. 667 Message Reception: Messages can be received in connection or datagram 668 mode, and from upstream or downstream peers. 670 Reception in connection mode is simple: incoming packets undergo 671 the security and transport treatment associated with the messaging 672 association, and the messaging association provides complete 673 messages to the GIMPS layer for further processing. 675 Reception in datagram mode depends on the message direction. 676 Upstream messages (from a downstream peer) will arrive UDP 677 encapsulated and addressed directly to the receiving signaling 678 node. Each datagram contains a single complete message which is 679 passed to the GIMPS layer for further processing, just as in the 680 connection mode case. 682 Downstream datagram mode messages are UDP encapsulated and 683 addressed to the flow receiver with an IP router alert option to 684 cause interception. The signaling node will therefore 'see' all 685 such messages, including those in which it is not interested. 686 There are then two cases. If the node categorises the message as 687 'not interesting' (which includes the case that the node does not 688 implement the signaling application which the message is about), 689 it is passed on to the IP layer for message transmission without 690 further processing (further criteria and mechanisms for 691 categorisation are discussed in Section 8.4). If the message is 692 determined to be interesting, it is passed up to the GIMPS layer 693 for further processing as in the other cases. 695 Local Processing: Once a message has been received, by any method, it 696 is processed locally within the GIMPS layer. The GIMPS processing 697 to be done depends on the payloads carried; most of the 698 GIMPS-internal payloads are associated with state maintenance and 699 are covered in the next subsection. 701 One GIMPS-internal payload which can be carried in any message and 702 requires processing is the GIMPS hop count. This is decremented on 703 input processing, and checked to be greater than zero on output 704 processing. The primary purpose of the GIMPS hop count is to 705 prevent message looping. 707 The remainder of the GIMPS message consists of an NSLP payload. 708 This is delivered locally to the signaling application identified 709 at the GIMPS level; the format of the NSLP payload is not 710 constrained by GIMPS, and the content is not interpreted. 712 Signaling applications can generate their messages for 713 transmission, either asynchronously, or in response to an input 714 message. Messages may also be forwarded in the GIMPS layer if 715 there is no appropriate local signaling application to process 716 them. Regardless of the source, outgoing messages are passed 717 downwards for message transmission. 719 Message Transmission: When a message is available for transmission, 720 GIMPS uses internal policy and the stored routing state to 721 determine how to handle it. The following processing applies 722 equally to locally generated messages and messages forwarded from 723 within the GIMPS or signaling application levels. 725 The main decision is whether the message must be sent in 726 connection mode or datagram mode. Reasons for using the former 727 could be: 729 * NSLP requirements: for example, the signaling application has 730 requested channel secured delivery, or reliable delivery; 732 * protocol specification: for example, this document could 733 specify that a message that requires fragmentation MUST be sent 734 over a messaging association; 736 * local GIMPS policy: for example, a node may prefer to send 737 messages over a messaging association to benefit from 738 congestion control. 740 In principle, as well as determining that some messaging 741 association must be used, GIMPS could select between a set of 742 alternatives, e.g. for load sharing or because different messaging 743 associations provide different transport or security attributes 744 (see Section 8.5 for further discussion). 746 If the use of a messaging association is selected, the message is 747 queued on the association (found from the upstream or downstream 748 peer state table), and further output processing is carried out 749 according to the details of the protocol stack used for the 750 association. If no appropriate association exists, the message is 751 queued while one is created (see next subsection). If no 752 association can be created, this is again an error condition. 754 If a messaging association is not required, the message is sent in 755 datagram mode. The processing in this case depends on whether the 756 message is directed upstream or downstream. 758 * If the upstream peer IP address is available from the per-flow 759 routing table, the message is UDP encapsulated and sent 760 directly to that address. Otherwise, the message cannot be 761 forwarded (i.e. this is an error condition). 763 * In the downstream direction, messages can always be sent. They 764 are simply UDP encapsulated and IP addressed to the flow 765 receiver, with the appropriate router alert option. 767 4.3 Routing State and Messaging Association Maintainance 769 The main responsibility of the GIMPS layer is to manage the routing 770 state and messaging associations which are used in the basic message 771 processing described above. Routing state is installed and maintained 772 by datagram mode messages containing specific GIMPS payloads. 773 Messaging associations are dependent on the existence of routing 774 state, but are actually set up by the normal procedures of the 775 transport and security protocols that comprise the messaging 776 association. Timers control routing state and messaging association 777 refresh and expiration. 779 The complete sequence of possible messages for state setup between 780 adjacent peers is shown in Figure 4 and described in detail in the 781 following text. 783 The initial message in any routing state maintenance operation is a 784 downstream datagram mode message, sent from the querying node and 785 intercepted at the responding node. This is encapsulated and 786 addressed just as in the normal case; in particular, it has 787 addressing and other identifiers appropriate for the flow and 788 signaling application that state maintenance is being done for, and 789 it is allowed to contain an NSLP payload. Processing at the querying 790 and responding nodes is also essentially the same. However, the 791 querying node includes additional payloads: its own address 792 information, and optionally 'Discover-Query' information, including a 793 Response Request flag and a Query Cookie. This message is informally 794 referred to as a 'GIMPS-query'. The role of the cookies in this and 795 subsequent messages is to protect against certain denial of service 796 attacks. 798 +----------+ +----------+ 799 | Querying | |Responding| 800 | Node | | Node | 801 +----------+ +----------+ 803 GIMPS-query 804 ----------------------> 805 Router Alert Option ........... 806 Flow/Session/Sig App ID . Routing . 807 Q-Node Addressing . state . ^ 808 [Query Cookie] .installed. | Existing 809 [Response Request] . at . | messaging 810 [NSLP Payload] . R-node . | associations 811 ........... | can be used 812 GIMPS-response | from here 813 ........... <---------------------- | onwards 814 . Routing . Flow/Session/Sig App ID | 815 . state . Query cookie | 816 .installed. R-Node Addressing | ^ 817 . at . (D Mode only) | | 818 . Q-node . [Responder Cookie] | | 819 ........... [Response Request] | | New 820 [NSLP Payload] | | messaging 821 | | associations 822 Final handshake | | can be set 823 ----------------------> | | up from here 824 Flow/Session/Sig App ID ........... | | onwards 825 Responder Cookie . Routing . | | 826 Q-Node Addressing . state . | | 827 (D Mode only) .installed. | | 828 [NSLP Payload] . at . | | 829 . R-node . | | 830 ........... | | 832 Figure 4: Message Sequence at State Setup 834 In the responding node, the GIMPS level processing of the 835 Discover-Query information triggers the generation of a 836 'GIMPS-response' message. This is also a normally encapsulated and 837 addressed message with particular payloads, this time in the upstream 838 direction. Again, it can contain an NSLP payload (possibly a response 839 to the NSLP payload in the initial message). It includes its own 840 addressing information and the Query Cookie, and optionally 841 'Discover-Response' information, including another Response Request 842 flag and a Responder Cookie. Note that if a messaging association 843 already exists towards the querying node, this can be used to deliver 844 the GIMPS-response message; otherwise, datagram mode is used. 846 The querying node installs the responder address as downstream peer 847 state information after verifying the Query Cookie in the 848 GIMPS-response. The responding node can install the querying address 849 as upstream peer state information after the receipt of the initial 850 GIMPS-query, or after a third message in the downstream direction 851 containing the Responder Cookie. The detailed constraints on 852 precisely when state information is installed are driven by security 853 considerations on prevention of denial-of-service attacks and state 854 poisoning attacks, which are discussed further in Section 7. 856 Setup of messaging associations begins when both downstream peer 857 addressing information is available and a new messaging association 858 is actually needed. (In many cases, the GIMPS-response message above 859 will identify a downstream peer for whom an appropriate messaging 860 association already exists, in which case no further action is 861 needed.) Setup of the messaging association always starts from the 862 upstream node, but it can be used equally in both directions. 864 Refresh and expiration of all types of state is controlled by timers. 865 State in the routing table has a per-flow, per-direction timer, which 866 expires after a routing state lifetime. It is the responsibility of 867 the querying node to generate a GIMPS-query message, optionally with 868 a discover-query payload, before this timer expires, if it believes 869 that the flow is still active. Receipt of the message at the 870 responding node will refresh upstream peer addressing state, and 871 receipt of a GIMPS-response at the querying node will refresh any 872 downstream peer addressing state if it exists. Note that nodes do not 873 control the refresh of upstream peer state themselves, they are 874 dependent on the upstream peer for this. 876 Messaging associations can be managed by either end. Management 877 consists of tearing down unneeded associations. Whether an 878 association is needed is a local policy decision, which could take 879 into account the cost of keeping the messaging association open, the 880 level of past activity on the association, and the likelihood of 881 future activity (e.g. if there are flows still in place which might 882 generate messages that would use it). Messaging associations can 883 always be set up on demand, and messaging association status is not 884 made directly visible outside the GIMPS layer. Therefore, even if 885 GIMPS tears down and later re-establishes a messaging association, 886 signaling applications cannot distinguish this from the case where 887 the association is kept permanently open. 889 5. Message Formats and Encapsulations 891 5.1 GIMPS Messages 893 All GIMPS messages begin with a common header, which includes a 894 version number, information about message type, signaling 895 application, and additional control information. The remainder of the 896 message is encoded in an RSVP-style format, i.e., as a sequence of 897 type-length-value (TLV) objects. This subsection describes the 898 possible GIMPS messages and their contents at a high level; a more 899 detailed description of each information element is given in Section 900 5.2. 902 The following gives the syntax of GIMPS messages in ABNF [3]. 904 GIMPS-message: A message is either a datagram mode message or a 905 connection mode message. GIMPS can detect which by the encapsulation 906 the message arrives over. 908 GIMPS-message = D-message / C-message 910 D-message: A datagram mode message is either upstream or downstream 911 (slightly different contents are allowed); the common header contains 912 a flag to say which. 914 D-message = D-upstream-message / D-downstream-message 916 C-message: A connection mode message is either upstream or downstream 917 (again, slightly different contents are allowed); the common header 918 contains a flag to say which. Note that upstream and downstream 919 messages can be mixed on a single messaging association. 921 C-message = C-upstream-message / C-downstream-message 923 D-downstream-message: A downstream datagram mode message is used for 924 the GIMPS-query and final handshake in the discovery procedure, and 925 can also be used simply for carrying NSLP data. 927 D-downstream-message = Common-Header 928 Flow-Routing-Information 929 Node-Addressing 930 Session-Identification 931 [ Query-Cookie / Responder-Cookie ] 932 [ Routing-State-Lifetime ] 933 [ NSLP-Data ] 935 D-upstream-message: An upstream datagram mode message is used for the 936 GIMPS-response in the discovery procedure, and can also be used 937 simply for carrying NSLP data. 939 D-upstream-message = Common-Header 940 Flow-Routing-Information 941 Node-Addressing 942 Session-Identification 943 [ Query-Cookie [ Responder-Cookie ] ] 944 [ Routing-State-Lifetime ] 945 [ NSLP-Data ] 947 C-downstream-message: A downstream connection mode message is used 948 primarily for carrying NSLP data, but can also be used for the final 949 handshake during discovery. Connection mode messages do not carry 950 node addressing, since this can be inferred from the messaging 951 association. 953 C-downstream-message = Common-Header 954 Flow-Routing-Information 955 Session-Identification 956 [ Responder-Cookie ] 957 [ Routing-State-Lifetime ] 958 [ NSLP-Data ] 960 C-upstream-message: An upstream connection mode message is used 961 primarily for carrying NSLP data, but can also be used for the 962 GIMPS-response during discovery. 964 C-upstream-message = Common-Header 965 Flow-Routing-Information 966 Session-Identification 967 [ Query-Cookie [ Responder-Cookie ] ] 968 [ Routing-State-Lifetime ] 969 [ NSLP-Data ] 971 5.2 Information Elements 973 This section describes the content of the various information 974 elements that can be present in each GIMPS message, both the common 975 header, and the individual TLVs. The format description in terms of 976 bit patterns is provided (in an extremely preliminary form) in 977 Appendix C. 979 5.2.1 The Common Header 981 Each message begins with a fixed format common header, which contains 982 the following information: 984 Version: The version number of the GIMPS protocol. 986 Length: The number of TLVs following in this message. 988 Signaling application identifier: This describes the signaling 989 application, such as resource reservation or firewall control. 991 GIMPS hop counter: A hop counter prevents a message from looping 992 indefinitely. (Since messages may get translated between different 993 lower-layer transport protocols, the IP hop count may be reset and 994 cannot be relied upon.) 996 U/D flag: A bit to indicate if this message is to propagate upstream 997 or downstream relative to the flow. 999 Response requested flag: A bit to indicate that this message contains 1000 a cookie which must be echoed in the response. 1002 5.2.2 TLV Objects 1004 All data following the common header is encoded as a sequence of 1005 type-length-value objects. Currently, each object can occur at most 1006 once; the set of required and permitted objects is determined by the 1007 message type and further information in the common header. 1009 These items are contained in each GIMPS message: 1011 Flow-Routing-Information: Information sufficient to define the route 1012 that the flow will take through the network. Minimally, this could 1013 just be the flow destination address; however, to account for 1014 policy based forwarding and other issues a more complete set of 1015 header fields should be used (see Section 6.2 and Section 6.3 for 1016 further discussion). 1018 Flow-Routing-Information = network-layer-version 1019 source-address prefix-length 1020 destination-address prefix-length 1021 IP-protocol 1022 traffic-class 1023 [ flow-label ] 1024 [ ipsec-SPI / L4-ports] 1026 Additional control information defines whether the flow-label, SPI 1027 and port information are present, and whether the IP-protocol and 1028 traffic-class fields should be interpreted as significant. 1030 Session-Identification: The GIMPS session identifier is a long, 1031 cryptographically random identifier chosen by the node which 1032 begins the signaling exchange (the signaling application at the 1033 node may specify it explicitly, or leave it up to GIMPS to select 1034 a value). The length is open, but 128 bits should be more than 1035 sufficient to make the probability of collisions orders of 1036 magnitude lower than other failure reasons. The session identifier 1037 should be considered immutable end-to-end along the flow path 1038 (GIMPS never changes it, and signaling applications should 1039 propagate it unchanged on messages for the same flow). 1041 The following items are optional: 1043 Node addressing: Minimally, this is the IP address at which the GIMPS 1044 node originating the message can be reached; this will be used to 1045 fill in peer routing state. A logical interface identifier is also 1046 included to assist in route change handling, see Section 6.1. 1047 Additional information can be provided on node capabilities and 1048 policy on messaging association management, as well as currently 1049 available associations. The level of flexibility required in this 1050 field is discussed in Section 8.5. 1052 Query-Cookie/Responder-Cookie: A query-cookie is optional in a 1053 GIMPS-query message and if present must be echoed in a 1054 GIMPS-response; a response-cookie is optional in a GIMPS-response 1055 message, and if present must be echoed in the following downstream 1056 message. Cookies are variable length (chosen by the cookie 1057 generator) and need to be designed so that a node can determine 1058 the validity of a cookie without keeping state. 1060 Routing-State-Lifetime: The lifetime of GIMPS routing state in the 1061 absence of refreshes, measured in seconds. Defaults to 30 seconds. 1063 NSLP-Data: The NSLP payload to be delivered to the signaling 1064 application. GIMPS does not interpret the payload content. 1066 5.3 Encapsulation in Datagram Mode 1068 Encapsulation in datagram mode is simple. The complete set of GIMPS 1069 payloads for a single message is concatenated together with the 1070 common header, and placed in the data field of a UDP datagram. UDP 1071 checksums should be enabled. Upstream messages are directly addressed 1072 to the adjacent peer. Downstream messages are addressed to the flow 1073 receiver and encapsulated with a Router Alert Option; GIMPS may set 1074 the traffic class and (for IPv6) flow label to match the values in 1075 the Flow-Routing-Information if this would be needed to ensure 1076 correct routing. Open issues about alternative encapsulations, 1077 addressing possibilities, and router alert option value-field setting 1078 are discussed in Section 8.2, Section 8.3 and Section 8.4 1079 respectively. 1081 The source UDP port is selected by the message sender. A destination 1082 UDP port should be allocated by IANA. Note that GIMPS may send 1083 messages addressed as {flow sender, flow receiver} which could make 1084 their way to the flow receiver even if that receiver were 1085 GIMPS-unaware. This should be rejected (with an ICMP message) rather 1086 than delivered to the user application (which would be unable to use 1087 the source address to identify it as not being part of the normal 1088 data flow). Therefore, a "well-known" port would seem to be required. 1090 5.4 Encapsulation in Connection Mode 1092 Encapsulation in connection mode is more complex, because of the 1093 variation in available transport functionality. This issue is treated 1094 in Section 5.4.1. The actual encapsulation is given in Section 5.4.2. 1096 5.4.1 Choice of Transport Protocol 1098 It is a general requirement of the NTLP defined in [20] that it 1099 should be able to support bundling (of small messages), fragmentation 1100 (of large messages), and message boundary delineation. Not all 1101 transport protocols natively support all these features. 1103 SCTP [6] satisfies all requirements. (The bundling requirement is met 1104 implicitly by the use of Nagle-like algorithms inside the SCTP 1105 stack.) 1107 DCCP [7] is message based but does not provide bundling or 1108 fragmentation. Bundling can be carried out by the GIMPS layer 1109 sending multiple messages in a single datagram; because the common 1110 header includes length information (number of TLVs), the message 1111 boundaries within the datagram can be discovered during parsing. 1112 Fragmentation of GIMPS messages over multiple datagrams should be 1113 avoided, because of amplification of message loss rates that this 1114 would cause. 1116 TCP provides both bundling and fragmentation, but not message 1117 boundaries. However, the length information in the common header 1118 allows the message boundary to be discovered during parsing. 1120 UDP can be augmented as in the DCCP case. (An additional reason for 1121 avoiding fragmentation is the lack of congestion control 1122 functionality in UDP.) 1124 It can be seen that all of these protocol options can be supported by 1125 the basic GIMPS message format already presented. GIMPS messages 1126 requiring fragmentation must be carried using a reliable transport 1127 protocol, TCP or SCTP. 1129 5.4.2 Encapsulation Format 1131 The GIMPS message, consisting of common header and TLVs, is carried 1132 directly in the transport protocol (possibly incorporating transport 1133 layer security protection). Further GIMPS messages can be carried in 1134 a continuous stream (for TCP), or up to the next transport layer 1135 message boundary (for SCTP/DCCP/UDP). This situation is shown in 1136 Figure 5; it applies to both upstream and downstream messages. 1138 +---------------------------------------------+ 1139 | L2 Header | 1140 +---------------------------------------------+ 1141 | IP Header | ^ 1142 | Source address = signaling source | ^ 1143 | Destination address = signaling destination | . 1144 +---------------------------------------------+ . 1145 | L4 Header | . ^ 1146 | (Standard TCP/SCTP/DCCP/UDP header) | . ^ 1147 +---------------------------------------------+ . . 1148 | GIMPS Message | . . ^ 1149 | (Common header and TLVs as in section 5.1) | . . ^ Scope of 1150 +---------------------------------------------+ . . . security 1151 | Additional GIMPS messages, each with its | . . . protection 1152 | own common header, either as a continuous | . . . (depending 1153 | stream, or continuing to the next L4 | . . . on channel 1154 . message boundary . . . . security 1155 . . V V V mechanism 1156 . . V V V in use) 1158 Figure 5: Connection Mode Encapsulation 1160 Note that when GIMPS messages are carried in connection mode in this 1161 way, between the GIMPS peers they are treated just like any other 1162 traffic by intermediate routers. Indeed, it would be impossible for 1163 intermediate routers to carry out any processing on the messages 1164 without terminating the transport and security protocols used. 1166 Signaling messages are only ever delivered between peers established 1167 in GIMPS-query/response exchanges. Any route change is not detected 1168 until another GIMPS-query/response procedure takes place; in the 1169 meantime, signaling messages are misdelivered. GIMPS is responsible 1170 for prompt detection of route changes to minimise the period during 1171 which this can take place. 1173 6. Advanced Protocol Features 1175 6.1 Route Changes and Local Repair 1177 6.1.1 Introduction 1179 When re-routing takes place in the network, GIMPS and signaling 1180 application state needs to be updated for all flows whose paths have 1181 changed. The updates to signaling application state are usually 1182 signaling application dependent: for example, if the path 1183 characteristics have actually changed, simply moving state from the 1184 old to the new path is not sufficient. Therefore, GIMPS cannot carry 1185 out the complete path update processing. Its responsibilities are to 1186 detect the route change, update its own routing state consistently, 1187 and inform interested signaling applications at affected nodes. 1189 Route change management is complicated by the distributed nature of 1190 the problem. Consider the re-routing event shown in Figure 6. An 1191 external observer can tell that the main responsibility for 1192 controlling the updates will probably lie with nodes A and E; 1193 however, D1 is best placed to detect the event quickly at the GIMPS 1194 level, and B1 and C1 could also attempt to initiate the repair. 1196 On the assumption that NSLPs are soft-state based and operate end to 1197 end, and because GIMPS also periodically updates its picture of 1198 routing state, route changes will eventually be repaired 1199 automatically. However, especially if NSLP refresh times are extended 1200 to reduce signaling load, the duration of inconsistent state may be 1201 very long indeed. Therefore, GIMPS includes logic to deliver prompt 1202 notifications to NSLPs, to allow NSLPs to carry out local repair if 1203 possible. 1205 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1206 x +--+ +--+ +--+ x Initial 1207 x .|B1|_.......|C1|_.......|D1| x Configuration 1208 x . +--+. .+--+. .+--+\. x 1209 x . . . . . . x 1210 >>xxxxxx . . . . . . xxxxxx>> 1211 +-+ . .. .. . +-+ 1212 .....|A|/ .. .. .|E|_.... 1213 +-+ . . . . . . +-+ 1214 . . . . . . 1215 . . . . . . 1216 . +--+ +--+ +--+ . 1217 .|B2|_.......|C2|_.......|D2|/ 1218 +--+ +--+ +--+ 1220 +--+ +--+ +--+ Configuration 1221 .|B1|........|C1|........|D1| after failure 1222 . +--+ .+--+ +--+ of D1-E link 1223 . \. . \. ./ 1224 . . . . . 1225 +-+ . .. .. +-+ 1226 .....|A|. .. .. .|E|_.... 1227 +-+\. . . . . . +-+ 1228 >>xxxxxx . . . . . . xxxxxx>> 1229 x . . . . . . x 1230 x . +--+ +--+ +--+ . x 1231 x .|B2|_.......|C2|_.......|D2|/ x 1232 x +--+ +--+ +--+ x 1233 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1235 ........... = physical link topology 1237 >>xxxxxxx>> = flow direction 1239 _.......... = indicates outgoing link 1240 for flow xxxxxx given 1241 by local forwarding table 1243 Figure 6: A Re-Routing Event 1245 6.1.2 Route Change Detection 1247 There are two aspects to detecting a route change at a single node: 1249 Detecting that the downstream path has (or may have) changed. 1251 Detecting that the upstream path has (or may have) changed (in 1252 which case the node may no longer be on the path at all). 1254 At a single node, these processes are largely independent, although 1255 clearly a change in downstream path at a node corresponds to a change 1256 in upstream path at the downstream peer. Note that there are two 1257 primary elements to route change: 1259 Interface: The interface through which a flow leaves or enters a node 1260 may change. 1262 Peer: The adjacent upstream peer or downstream peer may change. 1264 In general, a route change could include one or the other or both. 1265 (In theory it could include neither, although such changes are hard 1266 to detect and even harder to do anything useful about.) 1268 There are five mechanisms for a GIMPS node to detect that a route 1269 change has occurred, which are listed below. They apply differently 1270 depending on whether the change is in the upstream or downstream 1271 path, and these differences are given in the following table. 1273 Local Trigger: In trigger mode, a node finds out that the next hop 1274 has changed. This is the RSVP trigger mechanism where some form of 1275 notification mechanism from the routing table to the protocol 1276 handler is assumed. Clearly this only works if the routing change 1277 is local, not if the routing change happens somewhere a few 1278 routing hops away (including the case that the change happens at a 1279 GIMPS-unaware node). 1281 Extended Trigger: An extended trigger, where the node checks a 1282 link-state routing table to discover that the path has changed. 1283 This makes certain assumptions on consistency of route computation 1284 (but you probably need to make those to avoid routing loops) and 1285 only works intra-domain for OSPF and similar link-state protocols. 1286 Where available, this offers the most accurate and expeditious 1287 indication of route changes, but requires more access to the 1288 routing internals than a typical OS may provide. 1290 GIMPS C-mode Monitoring: A node may find that C-mode packets are 1291 arriving (from upstream or downstream peer) with a different TTL 1292 or on a different interface. This provides no direct information 1293 about the new flow path, but indicates that routing has changed 1294 and that rediscovery may be required. 1296 Data Plane Monitoring: The signaling application on a node may detect 1297 a change in behaviour of the flow, such as TTL change, arrival on 1298 a different interface, or loss of the flow altogether. The 1299 signaling application on the node is allowed to notify this 1300 information locally to GIMPS. 1302 GIMPS D-mode Probing: In probing mode, each GIMPS node periodically 1303 repeats the discovery (GIMPS-query/GIMPS-response) operation. The 1304 querying node will discover the route change by a modification in 1305 the Node-Addressing information in the GIMPS-response. This is 1306 similar to RSVP behavior, except that there is an extra degree of 1307 freedom since not every message needs to repeat the discovery, 1308 depending on the likely stability of routes. All indications are 1309 that, leaving mobility aside, routes are stable for hours and 1310 days, so this may not be necessary on a 30-second interval, 1311 especially if the other techniques listed above are available. 1313 When these methods discover a route change in the upstream direction, 1314 this cannot be handled directly by GIMPS at the detecting node, since 1315 route discovery proceeds only in the downstream direction. Therefore, 1316 to exploit these mechanisms, it must be possible for GIMPS to send a 1317 notification message in the upstream direction to initiate this. 1318 (This would be possible for example by setting an additional flag in 1319 the Common-Header of an upstream message.) 1321 +----------------------+----------------------+---------------------+ 1322 | Method | Downstream | Upstream | 1323 +----------------------+----------------------+---------------------+ 1324 | Local Trigger | Discovers new | Not applicable | 1325 | | downstream interface | | 1326 | | (and peer if local) | | 1327 | | | | 1328 | Extended Trigger | Discovers new | May determine that | 1329 | | downstream interface | route from upstream | 1330 | | and may determine | peer will have | 1331 | | new downstream peer | changed | 1332 | | | | 1333 | C-Mode Monitoring | Provides hint that | Provides hint that | 1334 | | change has occurred | change has occurred | 1335 | | | | 1336 | Data Plane | Not applicable | NSLP informs GIMPS | 1337 | Monitoring | | that a change may | 1338 | | | have occurred | 1339 | | | | 1340 | D-Mode Probing | Discovers changed | Discovers changed | 1341 | | Node-Addressing in | Node-Addressing in | 1342 | | GIMPS-response | GIMPS-query | 1343 +----------------------+----------------------+---------------------+ 1345 6.1.3 Local Repair 1347 Once a node has detected that a change may have occurred, there are 1348 three possible cases: 1350 1. Only an upstream change is indicated. There is nothing that can 1351 be done locally; GIMPS must propagate a notification to its 1352 upstream peer. 1354 2. A downstream change has been detected and an upstream change is 1355 indicated. Although some local repair may be appropriate, it is 1356 difficult to decide what, since the path change may actually have 1357 taken place upstream of the detecting node (so that this node is 1358 no longer on the path at all). 1360 3. A downstream change has been detected, but there is no upstream 1361 change. In this case, the detecting node is the true crossover 1362 router, i.e. the point in the network where old and new paths 1363 diverge. It is the correct node to initiate the local repair 1364 process. 1366 In case (3), i.e. at the upstream crossover node, the local repair 1367 process is initiated by the GIMPS level as follows: 1369 o GIMPS marks its downstream routing state information for this flow 1370 as 'invalid', unless the route change was actually detected by 1371 D-mode probing (in which case the new state has already been 1372 installed). 1374 o GIMPS notifies the local NSLP that local repair is necessary. 1376 It is assumed that the second step will typically trigger the NSLP to 1377 generate a downstream message, and the attempt to send it will 1378 stimulate a GIMPS-query/response. This signaling application message 1379 will propagate downstream, also discovering the new route, until it 1380 rejoins the old path; the node where this happens may also have to 1381 carry out local repair actions. 1383 A problem is that there is usually no robust technique to distinguish 1384 case (2) from case (3), because of the relative weakness of the 1385 techniques in determining that upstream change has not occurred. 1386 (They can be effective in determining that a change has occurred; 1387 however, even where they can tell that the route from the upstream 1388 peer has not changed, they cannot rule out a change beyond that 1389 peer.) There is therefore a danger that multiple nodes within the 1390 network would attempt to carry out local repair in parallel. 1392 One possible technique to address this problem is that a GIMPS node 1393 that detects case (3) locally, rather than initiating local repair 1394 immediately, still sends a route change notification upstream, just 1395 in case (2) actually applies. If the upstream peer locally detects no 1396 downstream route change, it can signal this to the downstream node 1397 (e.g. by setting another flag in the Common-Header of a GIMPS 1398 message). This acts to damp the possibility of a 'local repair 1399 storm', at the cost of an additional peer-peer round trip time. 1401 6.1.4 Local Signaling Application State Removal 1403 After a route change, a signaling application may wish to remove 1404 state at another node which is no longer on the path. However, since 1405 it is no longer on the path, in principle GIMPS can no longer send 1406 messages to it. (In general, provided this state is soft, it will 1407 time out anyway; however, the timeouts involved may have been set to 1408 be very long to reduce signaling load.) The requirement to remove 1409 state in a specific peer node is identified in [23]. 1411 This requirement can be met provided that GIMPS is able to 'remember' 1412 the old path to the signaling application peer for the period while 1413 the NSLP wishes to be able to use it. Since NSLP peers are a single 1414 GIMPS hop apart, the necessary information is just the old entry in 1415 the node's routing state table for that flow. Rather than requiring 1416 the GIMPS level to maintain multiple generations of this information, 1417 it can just be provided to the signaling application in the same node 1418 (in an opaque form), which can store it if necessary and provide it 1419 back to the GIMPS layer in case it needs to be used. 1421 6.1.5 Operation with Heterogeneous NSLPs 1423 A potential problem with route change detection is that the detecting 1424 GIMPS node may not implement all the signaling applications that need 1425 to be informed. Therefore, it would need to be able to send a 1426 notification back along the unchanged path to trigger the nearest 1427 signaling application aware node to take action. If multiple 1428 signaling applications are in use, it would be hard to define when to 1429 stop propagating this notification. However, given the rules on 1430 message interception and routing state maintenance in Section 4.2, 1431 Section 4.3 and Section 8.4, this situation cannot arise: all NSLP 1432 peers are exactly one GIMPS hop apart. 1434 The converse problem is that the ability of GIMPS to detect route 1435 changes by purely local monitoring of forwarding tables is more 1436 limited. (This is probably an appropriate limitation of GIMPS 1437 functionality. If we need a protocol for distributing notifications 1438 about local changes in forwarding table state, a flow signaling 1439 protocol is probably not the right starting point.) 1441 6.2 Policy-Based Forwarding and Flow Wildcarding 1443 Signaling messages almost by definition need to contain address and 1444 port information to identify the flow they are signaling for. We can 1445 divide this information into two categories: 1447 Flow-Routing-Information: This is the information needed to determine 1448 how a flow is routed within the network. Minimally it is the flow 1449 destination address, but to handle load sharing, QoS routing, and 1450 other forms of policy based forwarding, additional information may 1451 be required. It is carried as an object in each GIMPS message (see 1452 Section 5.1). 1454 Additional Packet Classification Information: This is any further 1455 higher layer information needed to select a subset of packets for 1456 special treatment by the signaling application. The need for this 1457 is highly signaling application specific, and so this information 1458 is invisible to GIMPS (if indeed it exists); it will be carried 1459 only in the corresponding NSLP. 1461 The correct pinning of signaling messages to the data path depends on 1462 how well the downstream messages in datagram mode can be made to be 1463 routed correctly. Two strategies are used: 1465 The messages themselves have the flow destination address, and 1466 possibly source address and traffic class (see Section 8.3 for 1467 further discussion). In many cases, this will cause the messages 1468 to be routed correctly even by GIMPS-unaware nodes. 1470 A GIMPS-aware node carrying out policy based forwarding on higher 1471 layer identifiers (in particular, the protocol and port numbers 1472 for IPv4) should take into account the entire 1473 Flow-Routing-Information object in selecting the outgoing 1474 interface rather than relying on the IP layer. 1476 The current Flow-Routing-Information format allows a limited degree 1477 of 'wildcarding', for example by applying a prefix length to the 1478 source or destination address, or by leaving certain fields 1479 unspecified. A GIMPS-aware node must verify that all flows matching 1480 the Flow-Routing-Information would be routed identically in the 1481 downstream direction, or else reject the message with an error. 1483 6.3 NAT Traversal 1485 A already noted, GIMPS messages must carry packet addressing and 1486 higher layer information as payload data in order to define the flow 1487 signalled for. (This applies to all GIMPS messages, regardless of how 1488 they are encapsulated or which direction they are travelling in.) At 1489 an addressing boundary the data flow packets will have their headers 1490 translated; if the signaling payloads are not likewise translated, 1491 the signaling messages will refer to incorrect (and probably 1492 meaningless) flows after passing through the boundary. 1494 The simplest solution to this problem is to require that a NAT is 1495 GIMPS-aware, and to allow it to modify datagram mode messages based 1496 on the contents of the Flow-Routing-Information payload. (This is 1497 making the implicit assumption that NATs only rewrite the header 1498 fields included in this payload, and not higher layer identifiers.) 1499 Provided this is done consistently with the data flow header 1500 translation, signaling messages will be valid each side of the 1501 boundary, without requiring the NAT to be signaling application 1502 aware. An outline of the set of operations necessary on a downstream 1503 datagram mode message is as follows: 1505 1. Verify that bindings for the data flow are actually in place. 1507 2. Create bindings for subsequent C-mode signaling (based on the 1508 information in the Node-Addressing field). 1510 3. Create a new Flow-Routing-Information payload with fields 1511 modified according to the data flow bindings. 1513 4. Create a new Node-Addressing payload with fields to force 1514 upstream D-mode messages through the NAT, and to allow C-mode 1515 exchanges using the C-mode signaling bindings. 1517 5. Forward the message with these new payloads. 1519 The original Flow-Routing-Information and Node-Addressing payloads 1520 should be retained in the message, but encapsulated in a new TLV 1521 type. (In the case of a sequence of NATs, this TLV would become a 1522 list.) This TLV essentially becomes a recorded route for the D-mode 1523 message; GIMPS node that wished to do topology hiding could replace 1524 this original payloads with opaque tokens, or omit them altogether. 1525 Note that a consequence of this approach is that the routing state 1526 tables at the actual signaling application peers (either side of the 1527 NAT) are no longer directly compatible (the values of 1528 Flow-Routing-Information are different, and the Node-Addressing may 1529 be different between C- and D-mode). Details are for further study. 1531 The case of traversing a GIMPS unaware NAT is also for further study. 1532 There is a dual problem of whether the GIMPS peers either side of the 1533 boundary can work out how to address each other, and whether they can 1534 work out what translation to apply to the flow routing information 1535 from what is done to the signaling packet headers. The fundamental 1536 problem is that GIMPS messages contain 3 or 4 interdependent 1537 addresses which all have to be consistently translated, and existing 1538 generic NAT traversal techniques such as STUN [19] can process only 1539 two. 1541 6.4 Interaction with IP Tunnelling 1543 The interaction between GIMPS and IP tunnelling is very simple. An IP 1544 packet carrying a GIMPS message is treated exactly the same as any 1545 other packet with the same source and destination addresses: in other 1546 words, it is given the tunnel encapsulation and forwarded with the 1547 other data packets. 1549 Tunnelled packets will not have the router alert option or the 1550 standard GIMPS protocol encapsulation (e.g. port numbers). They will 1551 not be identifiable as GIMPS messages until they leave the tunnel 1552 again. If signaling is needed for the tunnel itself, this has to be 1553 initiated as a separate signaling session by one of the tunnel 1554 endpoints - that is, the tunnel counts as a new flow. Because the 1555 relationship between signaling for the 'microflow' and signaling for 1556 the tunnel as a whole will depend on the signaling application in 1557 question, we are assuming that it is a signaling application 1558 responsibility to be aware of the fact that tunnelling is taking 1559 place and to carry out additional signaling if necessary; in other 1560 words, one tunnel endpoint must be signaling application aware. 1562 In some cases, it is the tunnel exit point (i.e. the node where 1563 tunnelled data and downstream signaling packets leave the tunnel) 1564 that will wish to carry out the tunnel signaling, but this node will 1565 not have knowledge or control of how the tunnel entry point is 1566 carrying out the data flow encapsulation. This information could be 1567 carried as additional data (an additional GIMPS payload) in the 1568 tunnelled signaling packets if the tunnel entry point was at least 1569 GIMPS aware. This payload would be the GIMPS equivalent of the RSVP 1570 SESSION_ASSOC object of [11]. Whether this functionality should 1571 really be part of GIMPS and if so how the payload should be handled 1572 will be considered in a later version. 1574 6.5 IPv4-IPv6 Transition and Interworking 1576 GIMPS itself is essentially IP version neutral (version dependencies 1577 are isolated in the formats of the Flow-Routing-Information and 1578 Node-Addressing TLVs, and GIMPS also depends on the version 1579 independence of the protocols that underly messaging associations). 1580 In mixed environments, GIMPS operation will be influenced by the IP 1581 transition mechanisms in use. This section provides a high level 1582 overview of how GIMPS is affected, considering only the currently 1583 predominant mechanisms. 1585 Dual Stack: (This applies both to the basic approach described in 1586 [24] as well as the dual-stack aspects of more complete 1587 architectures such as [26].) In mixed environments, GIMPS should 1588 use the same IP version as the flow it is signaling for; hosts 1589 which are dual stack for applications and routers which are dual 1590 stack for forwarding should have GIMPS implementations which can 1591 support both IP versions. 1593 In theory, for some connection mode encapsulation options, a 1594 single messaging association could carry signaling messages for 1595 flows of both IP versions, but the saving seems of limited value. 1596 The IP version used in datagram mode is closely tied to the IP 1597 version used by the data flow, so it is intrinsically impossible 1598 for a IPv4-only or IPv6-only GIMPS node to support signaling for 1599 flows using the other IP version. 1601 Applications with a choice of IP versions might select a version 1602 for which GIMPS support was available in the network, which could 1603 be established by running parallel discovery procedures. In 1604 theory, a GIMPS message related to a flow of one IP version could 1605 flag support for the other; however, given that IPv4 and IPv6 1606 could easily be separately routed, the correct GIMPS peer for a 1607 given flow might well depend on IP version anyway, making this 1608 flagged information irrelevant. 1610 Packet Translation: (Applicable to SIIT [5] and NAT-PT [12].) Some 1611 transition mechanisms allow IPv4 and IPv6 nodes to communicate by 1612 placing packet translators between them. From the GIMPS 1613 perspective, this should be treated essentially the same way as 1614 any other NAT operation (e.g. between 'public' and 'private' 1615 addresses) as described in Section 6.3. In other words, the 1616 translating node needs to be GIMPS aware; it will run GIMPS with 1617 IPv4 on some interfaces and with IPv6 on others, and will have to 1618 translate the Flow-Routing-Information payload between IPv4 and 1619 IPv6 formats for flows which cross between the two. The 1620 translation rules for the fields in the payload (including e.g. 1621 traffic class and flow label) are as defined in [5]. 1623 Tunnelling: (Applicable to 6to4 [14] and a whole host of other 1624 tunnelling schemes.) Many transition mechanisms handle the problem 1625 of how an end to end IPv6 (or IPv4) flow can be carried over 1626 intermediate IPv4 (or IPv6) regions by tunnelling; the methods 1627 tend to focus on minimising the tunnel administration overhead. 1629 From the GIMPS perspective, the treatment should be as similar as 1630 possible to any other IP tunnelling mechanism, as described in 1631 Section 6.4. In particular, the end to end flow signaling will 1632 pass transparently through the tunnel, and signaling for the 1633 tunnel itself will have to be managed by the tunnel endpoints. 1634 However, additional considerations may arise because of special 1635 features of the tunnel management procedures. For example, [15] is 1636 based on using an anycast address as the destination tunnel 1637 endpoint. It might be unwise to carry out signaling for the tunnel 1638 to such an address, and the GIMPS implementation there would not 1639 be able to use it as a source address for its own signaling 1640 messages (e.g. GIMPS-responses). Further analysis will be 1641 contained in a future version of this specification. 1643 7. Security Considerations 1645 The security requirement for the GIMPS layer is to protect the 1646 signaling plane against identified security threats. For the 1647 signaling problem as a whole, these threats have been outlined in 1648 [21]; the NSIS framework [20] assigns a subset of the responsibility 1649 to the NTLP. The main issues to be handled can be summarised as: 1651 Message Protection: Signaling message content should be protected 1652 against eavesdropping, modification, injection and replay while in 1653 transit. This applies both to GIMPS payloads, and GIMPS should 1654 also provide such protection as a service to signaling 1655 applications between adjacent peers. 1657 State Integrity Protection: It is important that signaling messages 1658 are delivered to the correct nodes, and nowhere else. Here, 1659 'correct' is defined as 'the same nodes that the infrastructure 1660 will route data flow packets through'. (GIMPS has no role in 1661 deciding whether the data flow itself is being routed correctly; 1662 all it can do is ensure the signaling is routed consistently with 1663 it.) GIMPS uses internal state to decide how to route signaling 1664 messages, and this state needs to be protected against corruption. 1666 Prevention of Denial of Service Attacks: GIMPS nodes and the network 1667 have finite resources (state storage, processing power, 1668 bandwidth). The protocol should try to minimise exhaustion attacks 1669 against these resources and not allow GIMPS nodes to be used to 1670 launch attacks on other network elements. 1672 The main missing issue is handling authorisation for executing 1673 signaling operations (e.g. allocating resources). This is assumed to 1674 be done in each signaling application. 1676 In many cases, GIMPS relies on the security mechanisms available in 1677 messaging associations to handle these issues, rather than 1678 introducing new security measures. Obviously, this requires the 1679 interaction of these mechanisms with the rest of the GIMPS protocol 1680 to be understood and verified. 1682 7.1 Message Confidentiality and Integrity 1684 GIMPS can use messaging association functionality, such as TLS or 1685 IPsec, to ensure message confidentiality and integrity. In many 1686 cases, confidentiality of GIMPS information itself is not likely to 1687 be a prime concern, in particular since messages are often sent to 1688 parties which are unknown ahead of time, although the content visible 1689 even at the GIMPS level gives significant opportunities for traffic 1690 analysis. Signaling applications may have their own mechanism for 1691 securing content as necessary; however, they may find it convenient 1692 to rely on protection provided by messaging associations, 1693 particularly if this is provided efficiently and if it runs unbroken 1694 between signaling application peers. 1696 7.2 Peer Node Authentication 1698 Cryptographic protection (of confidentiality or integrity) requires a 1699 security association with session keys, which can be established 1700 during an authentication and key exchange protocol run based on 1701 shared secrets, public key techniques or a combination of both. 1702 Authentication and key agreement is possible using the protocols 1703 associated with the messaging association being secured (TLS 1704 incorporates this functionality directly; IKE, IKEv2 or KINK can 1705 provide it for IPsec). GIMPS nodes rely on these protocols to 1706 authenticate the identity of the next hop, and GIMPS has no 1707 authentication capability of its own. 1709 However, with discovery, there are few effective ways to know what is 1710 the legitimate next or previous hop as opposed to an impostor. In 1711 other words, cryptographic authentication here only provides 1712 assurance that a node is 'who' it is (i.e. the legitimate owner of 1713 identity in some namespace), not 'what' it is (i.e. a node which is 1714 genuinely on the flow path and therefore can carry out signaling for 1715 a particular flow). Authentication provides only limited protection, 1716 in that a known peer is unlikely to lie about its role. Additional 1717 methods of protection against this type of attack are considered in 1718 Section 7.3 below. 1720 It is open whether peer node authentication should be made signaling 1721 application dependent; for example, whether successful authentication 1722 could be made dependent on presenting authorisation to act in a 1723 particular signaling role (e.g. signaling for QoS). 1725 7.3 Routing State Integrity 1727 The internal state in a node (see Section 4.1), specifically the 1728 upstream and downstream peer identification, is used to route 1729 messages along the data flow path. If this state is corrupted, 1730 signaling messages may be misdirected. 1732 The routing state table is the GIMPS view of how flows are being 1733 routed through the network in the immediate neighbourhood of the 1734 node. Routes are only weakly secured (e.g. there is usually no 1735 cryptographic binding of a flow to a route), and there is no other 1736 authoritative information about flow routes than the current state of 1737 the network itself. Therefore, consistency between GIMPS and network 1738 routing state has to be ensured by directly interacting with the 1739 routing mechanisms to ensure that the upstream and downstream 1740 signaling peers are the appropriate ones for any given flow. A good 1741 overview of security issues and techniques in this sort of context is 1742 provided in [25]. 1744 Downstream peer identification is installed and refreshed only on 1745 receiving a GIMPS-reponse message (compare Figure 4). This must echo 1746 the cookie from a previous GIMPS-query message, which will have been 1747 sent downstream along the flow path (in datagram mode, i.e. 1748 end-to-end addressed). Hence, only the true next peer or an on-path 1749 attacker will be able to generate such a message, provided freshness 1750 of the cookie can be checked at the querying node. 1752 Upstream peer identification can be installed directly on receiving a 1753 GIMPS-query message containing addressing information for the 1754 upstream peer. However, any node in the network could generate such a 1755 message (indeed, almost any node in the network could be the genuine 1756 upstream peer for a given flow). To protect against this, two 1757 strategies are possible: 1759 Filtering: the receiving node may be able to reject signaling 1760 messages which claim to be for flows with flow source addresses 1761 which would be ruled out by ingress filtering. An extension of 1762 this technique would be for the receiving node to monitor the data 1763 plane and to check explicitly that the flow packets are arriving 1764 over the same interface and if possible from the same link layer 1765 neighbour as the datagram mode signaling packets. (If they are 1766 not, it is likely that at last one of the signaling or flow 1767 packets is being spoofed.) Signaling applications should only 1768 install state on the route taken by the signaling itself. 1770 Authentication (weak or strong): the receiving node may refuse to 1771 install upstream state until it has handshaked by some means with 1772 the upstream peer. This handshaking could be as simple as 1773 requesting the upstream peer to echo the response cookie in the 1774 discover-response payload of a GIMPS-response message (to 1775 discourage nodes impersonating upstream peers from using forged 1776 source addresses); or, it could be full peer authentication within 1777 the messaging association, the reasoning being that an 1778 authenticated peer can be trusted not to pretend to be on path 1779 when it is not. 1781 The second technique also plays a role in denial of service 1782 prevention, see below. In practice, a combination of both techniques 1783 may be appropriate. 1785 7.4 Denial of Service Prevention 1787 GIMPS is designed so that each connectionless discovery message only 1788 generates at most one response, so that a GIMPS node cannot become 1789 the source of a denial of service amplification attack. 1791 However, GIMPS can still be subjected to denial-of-service attacks 1792 where an attacker using forged source addresses forces a node to 1793 establish state without return routability, causing a problem similar 1794 to TCP SYN flood attacks. In addition to vulnerabilities of a next 1795 peer discovery an unprotected path discovery procedure might 1796 introduce more denial of service attacks since a number of nodes 1797 could possibly be forced to allocate state. Furthermore, an 1798 adversary might modify or replay unprotected signaling messages. 1799 There are two types of state attacks and one computational resource 1800 attack. In the first state attack, an attacker floods a node with 1801 messages that the node has to store until it can determine the next 1802 hop. If the destination address is chosen so that there is no 1803 GIMPS-capable next hop, the node would accumulate messages for 1804 several seconds until the discovery retransmission attempt times out. 1805 The second type of state-based attack causes GIMPS state to be 1806 established by bogus messages. A related computational/ 1807 network-resource attack uses unverified messages to cause a node to 1808 make AAA queries or attempt to cryptographically verify a digital 1809 signature. (RSVP is vulnerable to this type of attack.) Relying only 1810 on upper layer security, for example based on CMS, might open a 1811 larger door for denial of service attacks since the messages are 1812 often only one-shot-messages without utilizing multiple roundtrips 1813 and DoS protection mechanisms. 1815 There are at least three defenses against these attacks: 1817 1. The responding node does not establish a session or discover its 1818 next hop on receiving the GIMPS-query message, but can wait for a 1819 setup message on a reliable channel. If the reliable channel 1820 exists, the additional delay is a one one-way delay and the total 1821 is no more than the minimal theoretically possible delay of a 1822 three-way handshake, i.e., 1.5 node-to-node round-trip times. 1823 The delay gets significantly larger if a new connection needs to 1824 be established first. 1826 2. The response to the initial discovery message contains a cookie. 1827 The previous hop repeats the discovery with the cookie included. 1828 State is only established for messages that contain a valid 1829 cookie. The setup delay is also 1.5 round-trip times. (This 1830 mechanism is similar to that in SCTP [6] and other modern 1831 protocols.) 1833 3. If there is a chance that the next-hop node shares a secret with 1834 the previous hop, the sender could include a hash of the session 1835 ID and the sender's secret. The receiver can then verify that the 1836 message was likely sent by the purported source. This does not 1837 scale well, but may work if most nodes tend to communicate with a 1838 small peer clique of nodes. (In that case, however, they might as 1839 well establish more-or-less permanent transport sessions with 1840 each other.) 1842 These techniques are complementary; we chose a combination of the 1843 first and second method. 1845 Once a node has decided to establish routing state, there may still 1846 be transport and security state to be established between peers. This 1847 state setup is also vulnerable to additional denial of service 1848 attacks. GIMPS relies on the lower layer protocols that make up 1849 messaging associations to mitigate such attacks. The current 1850 description assumes that the upstream node is always the one wishing 1851 to establish a messaging association, so it is typically the 1852 downstream node that is protected. Extensions are considered in 1853 Section 8.6; these would require further analysis. 1855 8. Open Issues 1857 8.1 Protocol Naming 1859 Alternate names: 1860 GIST: General Internet Signaling Transport 1861 GIMPS: General Internet Messaging Protocol for Signaling 1862 LUMPS: Lightweight Universal Messaging for Path associated Signaling 1864 There is a danger of some ambiguity as to whether the protocol name 1865 refers to the complete transport stack below the signaling 1866 applications, or only to the additional protocol functionality above 1867 the standard transport protocols (UDP, TCP etc.) The NSIS framework 1868 uses the term NTLP for the first, but this specification uses the 1869 GIST/variants names for the second (see Figure 2 in Section 3.1). In 1870 other words, this specification proposes to meet the requirements for 1871 NTLP functionality by layering GIMPS/... over existing standard 1872 transport protocols. It isn't clear if additional terminological 1873 surgery is needed to make this clearer. 1875 8.2 General IP Layer Issues 1877 Some NSIS messages have to be addressed end-to-end but intercepted at 1878 intermediate routers, and this imposes some special constraints on 1879 how they can be encapsulated. RSVPv1 [9] primarily uses raw IP with a 1880 specific protocol number (46); a UDP encapsulation is also possible 1881 for hosts unable to perform raw network i/o. RSVP aggregation [17] 1882 uses an additional protocol number (134) to bypass certain interior 1883 nodes. 1885 The critical requirements for the encapsulation at this level are 1886 that routers should be able to identify signaling packets for 1887 processing, and that they should not mis-identify packets for 1888 'normal' end-to-end user data flows as signaling packets. The current 1889 assumption is that UDP encapsulation can be used for such messages, 1890 by allocating appropriate (new) value codes for the router alert 1891 option (RAO) [1][4] to identify NSIS messages. Specific open issues 1892 about how to allocate such values are discussed in Section 8.4. 1894 An alternative approach would be to use raw IP with the RSVP protocol 1895 numbers and a new RSVP version number. Although this would provide 1896 some more commonality with existing RSVP implementations, the NAT 1897 traversal problems for such an encapsulation seem much harder to 1898 solve. 1900 8.3 Encapsulation and Addressing for Datagram Mode 1902 The discussion in Section 4 essentially assumes that datagram mode 1903 messages are UDP encapsulated. This leaves open the question of 1904 whether other encapsulations are possible, and exactly how these 1905 messages should be addressed. 1907 As well as UDP/IP (and raw IP as discussed and temporarily ruled out 1908 in Section 8.2), DCCP/IP and UDP/IPsec could also be considered as 1909 'datagram' encapsulations. However, they still require explicit 1910 addressing between GIMPS peer nodes and some per-peer state to be set 1911 up and maintained. Therefore, it seems more appropriate to consider 1912 these encapsulation options as possible messaging association types, 1913 for use where there is a need for congestion control or security 1914 protection but without reliability. This would leave UDP/IP as the 1915 single encapsulation allowed for all datagram mode messages. 1917 Addressing for upstream datagram mode messages is simple: the IP 1918 source address is the signaling source address, and the IP 1919 destination address is the signaling destination address (compare 1920 Figure 1). For downstream datagram mode messages, the IP destination 1921 address will be the flow destination address, but the IP source 1922 address could be either of the flow source address or signaling 1923 source address. Some of the relative merits of these options are as 1924 follows: 1926 o Using the flow source address makes it more likely that the 1927 message will be correctly routed through any intermediate 1928 NSIS-unaware region which is doing load sharing or policy routing 1929 on the {source, destination} address pair. If the signaling source 1930 address is used, the message will be intercepted at some node 1931 closer to the flow destination, but it may not be the same as the 1932 next node for the data flow packets. 1934 o Conversely, using the signaling source address means that ICMP 1935 error messages (specifically, unreachable port or address) will be 1936 correctly delivered to the message originator, rather than being 1937 sent back to the flow source. Without seeing these messages, it is 1938 very difficult for the querying node to recognise that it is the 1939 last NSIS node on the path. In addition, using the signaling 1940 source address may make it possible to exchange messages through 1941 GIMPS unaware NATs (although it isn't clear how useful the 1942 resulting messages will be, see Section 6.3). 1944 It is not clear which of these situations it is more important to 1945 handle correctly and hence which source addressing option to use. 1946 (RSVP uses the flow source address, although this is primarily for 1947 multicast routing reasons.) A conservative approach would be to allow 1948 both, possibly even in parallel (although this might open up the 1949 protocol to amplification attacks). 1951 As well as the addressing, downstream datagram mode messages could be 1952 given the same traffic class (and, in the case of IPv6, flow label) 1953 as data flow messages. Doing this would increase the faithfulness of 1954 the routing of such messages. The traffic class may not be strictly 1955 appropriate for signaling; however, in many cases the bulk of the 1956 signaling messages will be sent in connection mode (for which a 1957 different traffic class can be freely chosen). 1959 8.4 Intermediate Node Bypass and Router Alert Values 1961 We assume that the primary mechanism for intercepting messages is the 1962 use of the RAO. The RAO contains a 16 bit value field, within which 1963 35 values have currently been assigned by IANA. It is open how to 1964 assign values for use by GIMPS messages to optimise protocol 1965 processing, i.e. to minimise the amount of slow-path processing that 1966 nodes have to carry out for messages they are not actually interested 1967 in the content of. 1969 There are two basic reasons why a GIMPS node might wish to ignore a 1970 message: 1972 o because it is for a signaling application that the node does not 1973 process; 1975 o because even though the signaling application is present, the node 1976 is only processing signaling messages at the aggregate level and 1977 not for individual flows (compare [17]). 1979 Once a message is ignored and forwarded onwards towards the next 1980 node, the current node has essentially dropped out of the signaling 1981 path for this flow and signaling application. Its address will not be 1982 discovered and used for upstream datagram mode messages or any 1983 connection mode messages. 1985 Some or all of this information could be encoded in the RAO value 1986 field, which would then allow these messages to be filtered on the 1987 fast path. (Even if the information is encoded deeper into the 1988 message, such as in the GIMPS fixed header, it may still be possible 1989 to process it on the fast path, and the semantics of the node 1990 dropping out of the signaling path are the same however the filtering 1991 is done. However, using the RAO seems the most efficient method if 1992 this is possible.) It is not clear whether the signaling application 1993 and aggregation level should be directly identified in the RAO value, 1994 or whether IANA should allocate special values for 'popular' 1995 applications or groups of applications or network configurations. The 1996 former is most flexible but is liable to be expensive in terms of 1997 value allocations. 1999 There is a special consideration in the case of the aggregation 2000 level. In this case, whether a message should be processed depends on 2001 the network region it is in. There are then two basic possibilities: 2003 1. All routers have essentially the same algorithm for which 2004 messages they process, i.e. all messages at aggregation level 0. 2005 However, messages have their aggregation level incremented on 2006 entry to an aggregation region and decremented on exit. 2008 2. Routers process messages only above a certain aggregation level 2009 and ignore all others. The aggregation level of a message is 2010 never changed; signaling messages for end to end flows have level 2011 0, but signaling messages for aggregates are generated with a 2012 higher level. 2014 The first technique requires aggregating/deaggregating routers to be 2015 configured as being at a particular aggregation level, and also 2016 requires consistent message rewriting at these boundaries. The second 2017 technique eliminates the rewriting, but requires interior routers to 2018 be configured also. It is not clear what the right trade-off between 2019 these options is. 2021 8.5 Messaging Association Flexibility 2023 The language of Section 4 is mainly based on the use of 0 or 1 2024 messaging associations between any pair of GIMPS nodes. However, 2025 logically it would be quite possible to have more than one 2026 association, for example: 2028 o to allow different reliability characteristics; 2030 o to provide different levels of security protection or to have 2031 security separation between different signaling streams; 2033 o even simply to have load split between different connections 2034 according to priority (so there could be two associations with 2035 identical protocol stacks). 2037 It is possible to imagine essentially infinite flexibility in these 2038 options, both in terms of how many possibilities are allowed and how 2039 nodes signal their capabilities and preferences, without much 2040 changing the overall GIMPS structure. (The GIMPS-query and 2041 GIMPS-response messages described in section Section 4.3 can be used 2042 to exchange this information.) What is not clear is how much 2043 flexibility is actually needed. 2045 8.6 Messaging Association Setup Message Sequences 2047 The discussion of Section 4.3 assumes a simple fixed message 2048 sequence, which we can picture as follows: 2050 +---------------------------------+---------------------------------+ 2051 | Direction | Message | 2052 +---------------------------------+---------------------------------+ 2053 | ---> | GIMPS-query message | 2054 | | | 2055 | <--- | GIMPS-response message | 2056 | | | 2057 | ===> | Querying node initiates | 2058 | | messaging association setup | 2059 | | messages | 2060 | | | 2061 | <--> | Signaling messages exchanged | 2062 +---------------------------------+---------------------------------+ 2064 There are several variants which could be considered at this level, 2065 for example whether the messaging association could be set up by the 2066 responding node: 2068 +---------------------------------+---------------------------------+ 2069 | Direction | Message | 2070 +---------------------------------+---------------------------------+ 2071 | ---> | GIMPS-query message | 2072 | | | 2073 | <=== | Responding node initiates | 2074 | | messaging association setup | 2075 | | messages | 2076 | | | 2077 | <--> | Signaling messages exchanged | 2078 +---------------------------------+---------------------------------+ 2080 This saves a message but may be vulnerable to additional denial of 2081 service attacks. 2083 Another open area is how the responding node propagates the signaling 2084 message downstream. It could initiate the downstream discovery 2085 process as soon as it received the initial GIMPS-query message, or it 2086 could wait until the first signaling application message has been 2087 received (which might not be until a messaging association has been 2088 established). A similar timing question applies to when it should 2089 initiate its own downstream messaging associations. It is possible 2090 that all these options are simply a matter for implementation 2091 freedom, although leaving them open will make mobility and re-routing 2092 behaviour rather harder to analyse, and again there are denial of 2093 service implications for some approaches (see Section 7.4). 2095 A final open area is how to manage the protocol exchanges that take 2096 place in setting up the messaging association itself. It is probably 2097 an implementation matter to consider whether to carry out, for 2098 example, the SCTP 4-way handshake only after IKE exchanges (for IPsec 2099 SA initialisation) have completed, or whether these can be done 2100 partly in parallel. A more radical step is to carry the initial 2101 request and response messages of both exchanges as payloads in the 2102 GIMPS-query/response exchange, with the request message initially 2103 formatted by the querying node with an unspecified destination IP 2104 address. This would require modifications to the protocol 2105 implementations (especially at the querying node) similar to what is 2106 needed for NAT traversal; it would have to be evaluated whether this 2107 was worth the one or two round trip times that are saved. 2109 8.7 GIMPS State Teardown 2111 The description of Section 4.3 provides for GIMPS state (per-flow 2112 routing state and per-peer messaging association state) to be removed 2113 on timer expiry; routing state can also be replaced (updated). This 2114 is the fundamental technique. An additional possibility would be to 2115 have explicit removal, i.e. a protocol mechanism to tear down GIMPS 2116 state immediately for a particular flow. On recieving such a message, 2117 a GIMPS node would clear routing entries and possibly take down 2118 messaging associations that were no longer used. 2120 Even if one peer indicates that routing state is no longer required, 2121 the receiving GIMPS node would have to ensure that no other peers 2122 (e.g. supporting different signaling applications) might generate 2123 messages of their own still needing the state. In addition, it is not 2124 clear how useful it is to remove GIMPS state promptly, since 2125 maintaining it only requires table storage without retention of any 2126 actual network resources. 2128 8.8 Datagram Mode Retries and Single Shot Message Support 2130 The GIMPS-query and GIMPS-response messages may suffer from message 2131 loss (e.g. due to congestion or corruption). Because a successful 2132 handshake is necessary before a messaging association can even be 2133 initiated, GIMPS must provide its own recovery method for these 2134 cases. A working assumption is that the querying node can repeat the 2135 GIMPS-query with an exponential backoff until a response is received 2136 or some retry threshold is reached. 2138 The same technique could be used by the GIMPS layer to provide a 2139 'low-cost' reliable message transfer service, restricted to short 2140 messages, without incurring the cost of setting up a messaging 2141 association. (If a messaging association exists, it will often be 2142 cheaper to discover and use that.) Providing such a service would 2143 require some minor extensions to the basic GIMPS protocol. It isn't 2144 clear if this additional option fills an important gap in the 2145 spectrum between datagram and connection mode message transfer. 2147 8.9 GIMPS Support for Message Scoping 2149 Many signaling applications are interested in sending messages over a 2150 specific region of the network. Message scoping of this nature seems 2151 to be hard to achieve in a topologically robust way, because such 2152 region boundaries are not well defined in the network layer. 2154 It may be that the GIMPS layer can assist such scoping, by detecting 2155 and counting different types of nodes in the signaling plane. The 2156 simplest solution would be to count GIMPS nodes supporting the 2157 relevant signaling application - this is already effectively done by 2158 the GIMPS hop count. A more sophisticated approach would be to track 2159 the crossing of aggregation region boundaries, as introduced in 2160 Section 8.4. Whether this is plausible depends on the willingness of 2161 operators to configure such boundary information in their routers. 2163 8.10 Mandatory or Optional Reverse Routing State 2165 Reverse routing state (i.e. the upstream peer addressing information 2166 in the routing state table) is installed per-flow when receiving a 2167 downstream datagram mode message containing an addressing information 2168 payload for the signaling source. 2170 Technically, the presence of this payload (and hence the installation 2171 of the state) is optional. This allows for very lightweight sending 2172 of multi-hop downstream signaling messages (even all the way from 2173 flow sender to flow receiver) because no state needs to be installed 2174 or managed by GIMPS at the intermediate nodes. However, this rules 2175 out the possibility of any downstream node sending signaling 2176 responses (including error messages) directly upstream; they have to 2177 be sent via the flow endpoints, leading to additional processing 2178 there, as well as more complex security considerations. 2180 8.11 Additional Discovery Mechanisms 2182 The routing state maintenance procedures described in Section 4.3 are 2183 strongly focussed on the problem of discovering, implicitly or 2184 explicitly, the neighbouring peers on the flow path - which is the 2185 necessary functionality for path-coupled signaling. 2187 As well as the GIMPS-query/response discovery mechanism, other 2188 techniques may sometimes also be possible. For example, in many 2189 environments, a host has a single access router, i.e. the downstream 2190 peer (for outgoing flows) and the upstream peer (for incoming ones) 2191 are known a priori. More generally, a link state routing protocol 2192 database can be analysed to determine downstream peers in more 2193 complex topologies, and maybe upstream ones if strict ingress 2194 filtering is in effect. More radically, much of the GIMPS protocol is 2195 unchanged if we consider off-path signaling nodes, although there are 2196 significant differences in some of the security analysis (Section 2197 7.3). However, none of these possibilities are considered further in 2198 this specification. 2200 8.12 Alternative Message Routing Requirements 2202 The basic assumption of GIMPS is that signaling messages are to be 2203 routed identically to data flow messages. GIMPS messages include 2204 information (the Flow-Routing-Information TLV and upstream/downstream 2205 flag in the Common-Header) which defines the flow and the 2206 relationship of the signaling to it sufficiently for GIMPS to route 2207 its messages correctly. However, some additional modes of routing 2208 signaling messages have been identified: 2210 Predictive Routing: Here, the intent is to send signaling along a 2211 path that the data flow may or will follow in the future. Possible 2212 cases are pre-installation of state on the backup path that would 2213 be used in the event of a link failure; and predictive 2214 installation of state on the path that will be used after a mobile 2215 node handover. It is currently unclear whether these cases can be 2216 met using the existing GIMPS routing capabilities (and if they 2217 cannot, whether they are in the initial scope of the work). 2219 NAT Address Reservations: This applies to the case where a node 2220 behind a NAT wishes to use NSIS signaling to reserve an address 2221 from which it can be reached by a sender on the other side. This 2222 requires a message to be sent outbound from what will be the flow 2223 receiver although no reverse routing state exists. One possible 2224 solution (assumed in [22]) is to construct a message with the 2225 Flow-Routing-Information matching the possible senders and send it 2226 as though it was downstream signaling. It is not clear whether 2227 signaling for the 'wrong direction' in this way will always be 2228 treated consistently by GIMPS, especially if routing policies and 2229 encapsulations for inbound and outbound traffic are treated very 2230 differently within the rest of the network. 2232 8.13 Congestion Control in Datagram Mode 2234 Datagram mode still requires (primitive) transport functions for 2235 backoff on retransmission (for example, when failing to receive a 2236 response to a GIMPS-query), and rate limiting in general. 2238 Retransmission should probably be handled with a simple exponential 2239 backoff process. This is cautious, but since by definition it is 2240 required when the peer is actually unknown, it is probably the best 2241 that can be achieved anyway. 2243 More subtle is the case where there is a stream of D-mode messages 2244 with no immediate feedback from the neighbour node. This could be the 2245 case where a signaling application was generating messages for 2246 stateless processing in the interior of the network. Here, the 2247 appropriate approach may be to use rate-limiting algorithms such as 2248 in ICMPv6 [10]. Another possibility would be to use ECN [16], if the 2249 datagram mode messages can be correlated with a congestion controlled 2250 messaging association which also supports ECN. Details are clearly 2251 for further study. 2253 8.14 Protocol Design Details 2255 Clearly, not all details of GIMPS operation have been defined so far. 2256 This section provides a list of slightly non-trivial areas where more 2257 detail is need, where these have not been mentioned elsewhere in the 2258 text. 2260 o Processing of the GIMPS hop count and IP TTL needs to be 2261 clarified, especially for messages which are being bypassed 2262 without going through full GIMPS processing. 2264 o Receiver initiated signaling applications need to have reverse 2265 path state set up in the network. Should this be done by GIMPS 2266 carrying out the discovery for the specific signaling application 2267 (which requires the flow sender to know what signaling 2268 applications are going to be used), or should the discovery 2269 attempt to find every GIMPS node and the signaling applications 2270 they support? 2272 9. Change History 2274 9.1 Changes In Version -01 2276 The major change in version -01 is the elimination of 2277 'intermediaries', i.e. imposing the constraint that signaling 2278 application peers are also GIMPS peers. This has the consequence that 2279 if a signaling application wishes to use two classes of signaling 2280 transport for a given flow, maybe reaching different subsets of 2281 nodes, it must do so by running different signaling sessions; and it 2282 also means that signaling adaptations for passing through NATs which 2283 are not signaling application aware must be carried out in datagram 2284 mode. On the other hand, it allows the elimination of significant 2285 complexity in the connection mode handling and also various other 2286 protocol features (such as general route recording). 2288 The full set of changes is as follows: 2290 1. Added a worked example in Section 3.3. 2292 2. Stated that nodes which do not implement the signaling 2293 application should bypass the message (Section 4.2). 2295 3. Decoupled the state handling logic for routing state and 2296 messaging association state in Section 4.3. Also, allow 2297 messaging associations to be used immediately in both directions 2298 once they are opened. 2300 4. Added simple ABNF for the various GIMPS message types in a new 2301 Section 5.1, and more details of the common header and each 2302 object in Section 5.2, including bit formats in Appendix C. The 2303 common header format means that the encapsulation is now the 2304 same for all transport types (Section 5.4.1). 2306 5. Added some further details on datagram mode encapsulation in 2307 Section 5.3, including more explanation of why a well known port 2308 it needed. 2310 6. Removed the possibility for fragmentation over DCCP (xref 2311 target='shims'/>), mainly in the interests of simplicity and 2312 loss amplification. 2314 7. Removed all the tunnel mode encapsulations (old sections 5.3.3 2315 and 5.3.4). 2317 8. Fully re-wrote the route change handling description (xref 2318 target='route-changes'/>), including some additional detection 2319 mechanisms and more clearly distinguishing between upstream and 2320 downstream route changes. Included further details on GIMPS/NSLP 2321 interactions, including where notifications are delivered and 2322 how local repair storms could be avoided. Removed old discussion 2323 of propagating notifications through signaling application 2324 unaware nodes (since these are now bypassed automatically). 2325 Added discussion on how to route messages for local state 2326 removal on the old path. 2328 9. Revised discussion of policy-based forwarding (Section 6.2) to 2329 account for actual FLow-Routing-Information definition, and also 2330 how wildcarding should be allowed and handled. 2332 10. Removed old route recording section (old Section 6.3). 2334 11. Extended the discussion of NAT handling (Section 6.3) with an 2335 extended outline on processing rules at a GIMPS-aware NAT and a 2336 pointer to implications for C-mode processing and state 2337 management. 2339 12. Clarified the definition of 'correct routing' of signaling 2340 messages in Section 7 and GIMPS role in enforcing this. Also, 2341 opened the possibility that peer node authentication could be 2342 signaling application dependent. 2344 13. Removed old open issues on Connection Mode Encapsulation 2345 (section 8.7); added new open issues on Message Routing (Section 2346 8.12) and Datagram Mode congestion control (Section 8.13). 2348 14. Added this change history. 2350 Normative References 2352 [1] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 2354 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2355 Levels", BCP 14, RFC 2119, March 1997. 2357 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2358 Specifications: ABNF", RFC 2234, November 1997. 2360 [4] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2361 2711, October 1999. 2363 [5] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 2364 RFC 2765, February 2000. 2366 [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 2367 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 2368 "Stream Control Transmission Protocol", RFC 2960, October 2000. 2370 [7] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 2371 draft-ietf-dccp-spec-05 (work in progress), October 2003. 2373 [8] Stewart, R., "SCTP Partial Reliability Extension", 2374 draft-ietf-tsvwg-prsctp-03 (work in progress), January 2004. 2376 Informative References 2378 [9] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 2379 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 2380 Specification", RFC 2205, September 1997. 2382 [10] Conta, A. and S. Deering, "Internet Control Message Protocol 2383 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 2384 Specification", RFC 2463, December 1998. 2386 [11] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP 2387 Operation Over IP Tunnels", RFC 2746, January 2000. 2389 [12] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 2390 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 2392 [13] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. 2393 Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2394 2961, April 2001. 2396 [14] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 2397 IPv4 Clouds", RFC 3056, February 2001. 2399 [15] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 2400 3068, June 2001. 2402 [16] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 2403 Explicit Congestion Notification (ECN) to IP", RFC 3168, 2404 September 2001. 2406 [17] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, 2407 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 2408 September 2001. 2410 [18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2411 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2412 Session Initiation Protocol", RFC 3261, June 2002. 2414 [19] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 2415 Simple Traversal of User Datagram Protocol (UDP) Through 2416 Network Address Translators (NATs)", RFC 3489, March 2003. 2418 [20] Hancock, R., "Next Steps in Signaling: Framework", 2419 draft-ietf-nsis-fw-05 (work in progress), October 2003. 2421 [21] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 2422 draft-ietf-nsis-threats-03 (work in progress), October 2003. 2424 [22] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol 2425 (NSLP)", draft-ietf-nsis-nslp-natfw-00 (work in progress), 2426 October 2003. 2428 [23] Bosch, S., "NSLP for Quality-of-Service signaling", 2429 draft-ietf-nsis-qos-nslp-01 (work in progress), October 2003. 2431 [24] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 2432 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in 2433 progress), February 2004. 2435 [25] Nikander, P., "Mobile IP version 6 Route Optimization Security 2436 Design Background", draft-nikander-mobileip-v6-ro-sec-02 (work 2437 in progress), December 2003. 2439 [26] Bound, J., "Dual Stack Transition Mechanism", 2440 draft-bound-dstm-exp-00 (work in progress), August 2003. 2442 Authors' Addresses 2444 Henning Schulzrinne 2445 Columbia University 2446 Department of Computer Science 2447 450 Computer Science Building 2448 New York, NY 10027 2449 US 2451 Phone: +1 212 939 7042 2452 EMail: hgs+nsis@cs.columbia.edu 2453 URI: http://www.cs.columbia.edu 2455 Robert Hancock 2456 Siemens/Roke Manor Research 2457 Old Salisbury Lane 2458 Romsey, Hampshire SO51 0ZN 2459 UK 2461 EMail: robert.hancock@roke.co.uk 2462 URI: http://www.roke.co.uk 2464 Appendix A. Acknowledgements 2466 This document is based on the discussions within the IETF NSIS 2467 working group. It has been informed by prior work and formal and 2468 informal inputs from: Cedric Aoun, Attila Bader, Bob Braden, Marcus 2469 Brunner, Xiaoming Fu, Ruediger Geib, Eleanor Hepworth, Georgios 2470 Karagiannis, John Loughney, Jukka Manner, Andrew McDonald, Dave Oran, 2471 Charles Shen, Melinda Shore, Martin Stiemerling, Mike Thomas, Hannes 2472 Tschofenig, Sven van den Bosch, Michael Welzl, and Lars Westberg. In 2473 particular, Hannes Tschofenig provided a detailed set of review 2474 comments on the security section, and Andrew McDonald provided the 2475 formal description for the initial packet formats. We look forward to 2476 inputs and comments from many more in the future. 2478 Appendix B. Example Routing State Table 2480 Figure 7 shows a signaling scenario for a single flow being managed 2481 by two signaling applications. The flow sender and receiver and one 2482 router support both, two other routers support one each. 2484 A B C D E 2485 +------+ +-----+ +-----+ +-----+ +--------+ 2486 | Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow | 2487 |Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver| 2488 | | +-+ +-+ |GIMPS| |GIMPS| |GIMPS| | | 2489 +------+ +-----+ +-----+ +-----+ +--------+ 2491 ------------------------------>> 2492 Flow Direction 2494 Figure 7: A Signaling Scenario 2496 Routing state table at node B: 2498 +-------------+-----------+--------------+-----------+--------------+ 2499 | Flow | Session | Signaling | Upstream | Downstream | 2500 | Routing | ID | Application | Peer | Peer | 2501 | Information | | | | | 2502 +-------------+-----------+--------------+-----------+--------------+ 2503 | {IP-#A, | 0xABCDEF | NSLP1 | IP-#A | (null) | 2504 | IP-#E, | | | | | 2505 | protocol, | | | | | 2506 | ports} | | | | | 2507 | | | | | | 2508 | {IP-#A, | 0x123456 | NSLP2 | IP-#A | Pointer to | 2509 | IP-#E, | | | | B-D | 2510 | protocol, | | | | messaging | 2511 | ports} | | | | association | 2512 +-------------+-----------+--------------+-----------+--------------+ 2514 The table shows the routing state at Node B for the single flow from 2515 A to E. The upstream state is just the same address for each 2516 application. For the downstream case, NSLP1 only requires datagram 2517 mode messages and so no explicit routing state towards C is needed. 2518 NSLP2 requires a messaging association for its messages towards node 2519 D, and node C does not process NSLP2 at all, so the downstream peer 2520 state for NSLP2 is a pointer to a messaging association that runs 2521 directly from B to D. Note that E is not visible in the state table 2522 (except implicitly in the address in the flow routing information); 2523 routing state is stored only for adjacent peers. 2525 Appendix C. Information Element Formats 2527 This appendix provides initial formats for the various component 2528 parts of the GIMPS messages defined abstractly in Section 5.2. It 2529 should be noted that these formats are extremely preliminary and 2530 should be expected to change completely several times during the 2531 further development of this specification. 2533 C.1 The Common Header 2535 This header precedes all GIMPS messages. It has a fixed format, as 2536 shown below. 2538 0 1 2 3 2539 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 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 | Version | GIMPS hops | Number of TLVs | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | Signalling Application ID |D|R| Reserved | 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2546 The flags are: 2547 D - Direction (Set for "Upstream", Unset for "Downstream") 2548 R - Response requested 2550 C.2 TLV Objects 2552 C.2.1 Standard Object Header 2554 Each object begins with a fixed header giving the object type and 2555 object length. A later version of this specification will contain 2556 more details on rules for object encodings which enable protocol 2557 extensibility. 2559 0 1 2 3 2560 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 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 | Type | Length | 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2565 In the following object diagrams, '//' is used to indicate a variable 2566 sized field and ':' is used to indicate a field that is optionally 2567 present. 2569 C.2.2 Flow-Routing-Information 2570 Type: Flow-Routing-Information 2572 Length: Variable (depends on address version and how much upper layer 2573 information is included) 2575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2576 | Version |P|T|F|S|O| Reserved | 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 // Source Address // 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 // Destination Address // 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2582 | Source Prefix | Dest Prefix | Protocol | Traffic Class | 2583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 : Reserved : Flow Label : 2585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2586 : SPI : 2587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2588 : Source Port : Destination Port : 2589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2591 The flags are: 2592 P - Protocol 2593 T - Traffic Class 2594 F - Flow Label 2595 S - SPI 2596 O - Source/Destination Ports 2598 C.2.3 Session Identification 2600 Type: Session-Identification 2602 Length: Fixed (TBD 128 bits) 2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2605 | | 2606 + + 2607 | | 2608 + Session ID + 2609 | | 2610 + + 2611 | | 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 C.2.4 Node Addressing 2616 Type: Node-Addressing 2618 Length: Variable (depends on detailed format and what optional fields 2619 are present) 2621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2622 | | 2623 // Node Addressing // 2624 | | 2625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 C.2.5 Query Cookie 2629 Type: Query-Cookie 2631 Length: Variable (selected by querying node) 2633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2634 | | 2635 // Query Cookie // 2636 | | 2637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2639 C.2.6 Responder Cookie 2641 Type: Responder-Cookie 2643 Length: Variable (selected by querying node) 2645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 | | 2647 // Responder Cookie // 2648 | | 2649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2651 C.2.7 Lifetime 2653 Type: Lifetime 2654 Length: Fixed (TBD 4 bytes) 2656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 | Lifetime | 2658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2660 C.2.8 NSLP Data 2662 Type: NSLP-Data 2664 Length: Variable (depends on NSLP) 2666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2667 | | 2668 // NSLP Data // 2669 | | 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 Intellectual Property Statement 2674 The IETF takes no position regarding the validity or scope of any 2675 intellectual property or other rights that might be claimed to 2676 pertain to the implementation or use of the technology described in 2677 this document or the extent to which any license under such rights 2678 might or might not be available; neither does it represent that it 2679 has made any effort to identify any such rights. Information on the 2680 IETF's procedures with respect to rights in standards-track and 2681 standards-related documentation can be found in BCP-11. Copies of 2682 claims of rights made available for publication and any assurances of 2683 licenses to be made available, or the result of an attempt made to 2684 obtain a general license or permission for the use of such 2685 proprietary rights by implementors or users of this specification can 2686 be obtained from the IETF Secretariat. 2688 The IETF invites any interested party to bring to its attention any 2689 copyrights, patents or patent applications, or other proprietary 2690 rights which may cover technology that may be required to practice 2691 this standard. Please address the information to the IETF Executive 2692 Director. 2694 Full Copyright Statement 2696 Copyright (C) The Internet Society (2004). All Rights Reserved. 2698 This document and translations of it may be copied and furnished to 2699 others, and derivative works that comment on or otherwise explain it 2700 or assist in its implementation may be prepared, copied, published 2701 and distributed, in whole or in part, without restriction of any 2702 kind, provided that the above copyright notice and this paragraph are 2703 included on all such copies and derivative works. However, this 2704 document itself may not be modified in any way, such as by removing 2705 the copyright notice or references to the Internet Society or other 2706 Internet organizations, except as needed for the purpose of 2707 developing Internet standards in which case the procedures for 2708 copyrights defined in the Internet Standards process must be 2709 followed, or as required to translate it into languages other than 2710 English. 2712 The limited permissions granted above are perpetual and will not be 2713 revoked by the Internet Society or its successors or assignees. 2715 This document and the information contained herein is provided on an 2716 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2717 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2718 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2719 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2720 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2722 Acknowledgment 2724 Funding for the RFC Editor function is currently provided by the 2725 Internet Society.