idnits 2.17.00 (12 Aug 2021) /tmp/idnits24282/draft-schulzrinne-nsis-casp-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 20 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 229: '... [7,8] as RECOMMENDED protocols. Using TCP and SCTP also...' RFC 2119 keyword, line 415: '...er. A CASP node MAY maintain a transp...' RFC 2119 keyword, line 620: '... MAY, but does not have to...' RFC 2119 keyword, line 891: '... SHOULD listen for all scout respons...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 15, 2002) is 7187 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 2144 looks like a reference -- Missing reference section? '2' on line 2147 looks like a reference -- Missing reference section? '3' on line 2151 looks like a reference -- Missing reference section? '4' on line 2155 looks like a reference -- Missing reference section? '5' on line 2158 looks like a reference -- Missing reference section? '6' on line 2162 looks like a reference -- Missing reference section? '7' on line 2165 looks like a reference -- Missing reference section? '8' on line 2169 looks like a reference -- Missing reference section? '9' on line 2174 looks like a reference -- Missing reference section? '10' on line 2178 looks like a reference -- Missing reference section? '11' on line 2181 looks like a reference -- Missing reference section? '12' on line 2185 looks like a reference -- Missing reference section? '13' on line 2188 looks like a reference -- Missing reference section? '14' on line 2191 looks like a reference -- Missing reference section? '15' on line 2194 looks like a reference -- Missing reference section? '16' on line 2198 looks like a reference -- Missing reference section? '17' on line 2201 looks like a reference -- Missing reference section? '18' on line 2205 looks like a reference -- Missing reference section? '19' on line 2208 looks like a reference -- Missing reference section? '20' on line 2211 looks like a reference -- Missing reference section? '21' on line 2214 looks like a reference -- Missing reference section? '22' on line 2218 looks like a reference -- Missing reference section? '23' on line 2222 looks like a reference -- Missing reference section? '24' on line 2225 looks like a reference -- Missing reference section? '25' on line 2229 looks like a reference -- Missing reference section? '26' on line 2233 looks like a reference -- Missing reference section? '27' on line 2236 looks like a reference -- Missing reference section? '28' on line 2239 looks like a reference -- Missing reference section? '29' on line 2243 looks like a reference -- Missing reference section? '30' on line 2248 looks like a reference -- Missing reference section? '31' on line 2252 looks like a reference -- Missing reference section? '32' on line 2256 looks like a reference -- Missing reference section? '33' on line 2260 looks like a reference -- Missing reference section? '34' on line 2265 looks like a reference -- Missing reference section? '35' on line 2268 looks like a reference -- Missing reference section? '36' on line 2271 looks like a reference -- Missing reference section? '37' on line 2274 looks like a reference -- Missing reference section? '38' on line 2277 looks like a reference -- Missing reference section? '39' on line 2281 looks like a reference -- Missing reference section? '40' on line 2285 looks like a reference -- Missing reference section? '41' on line 2289 looks like a reference -- Missing reference section? '42' on line 2293 looks like a reference -- Missing reference section? '43' on line 2296 looks like a reference -- Missing reference section? '44' on line 2299 looks like a reference -- Missing reference section? '45' on line 2302 looks like a reference -- Missing reference section? '46' on line 2307 looks like a reference -- Missing reference section? '47' on line 2311 looks like a reference -- Missing reference section? '48' on line 2315 looks like a reference -- Missing reference section? '49' on line 2319 looks like a reference -- Missing reference section? '50' on line 2323 looks like a reference -- Missing reference section? '51' on line 2327 looks like a reference -- Missing reference section? '52' on line 2332 looks like a reference -- Missing reference section? '53' on line 2335 looks like a reference -- Missing reference section? '54' on line 2339 looks like a reference -- Missing reference section? '55' on line 2343 looks like a reference -- Missing reference section? '56' on line 2346 looks like a reference -- Missing reference section? '57' on line 2350 looks like a reference -- Missing reference section? '58' on line 2354 looks like a reference -- Missing reference section? '59' on line 2357 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 62 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft H. Schulzrinne 4 Columbia U. 5 H. Tschofenig 6 Siemens 7 X. Fu 8 TU Berlin 9 J. Eisl 10 Siemens 11 R. Hancock 12 Siemens-Roke Manor 13 draft-schulzrinne-nsis-casp-00.txt 14 September 15, 2002 15 Expires: January 2003 17 CASP - Cross-Application Signaling Protocol 19 STATUS OF THIS MEMO 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress". 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 To view the list Internet-Draft Shadow Directories, see 38 http://www.ietf.org/shadow.html. 40 Abstract 42 The Cross-Application Signaling Protocol (CASP) is a general-purpose 43 protocol for managing state in routers and other on-path network 44 devices. It can be used for QoS signaling, middlebox control, 45 topology discovery, measurement data collection, active network 46 instantiation and any other application where state needs to be 47 established along a data path. CASP consists of a set of building 48 blocks that can be used to construct protocol behavior suited for a 49 particular application. It is transport-neutral, network-friendly and 50 securable. This document describes the usage-independent components 51 of CASP. 53 1 Introduction 55 1.1 Protocol Overview 57 The Cross-Application Signaling Protocol (CASP) provides a generic 58 signaling service by establishing state along the data path from a 59 sender to one receiver, for unicast data, or multiple receivers, for 60 multicast data. CASP sessions can be initiated by the sender or the 61 receiver. 63 CASP is not restricted to sender or receiver-initiated reservations; 64 it can be used for a variety of signaling purposes. Examples include 65 resource reservation in both in-path and out-of-path modes, 66 configuration of middleboxes [1] such as firewalls and NATs, 67 distribution of code segments in active networks, network 68 diagnostics, and MPLS label distribution. 70 CASP does not place restrictions on the location of signaling 71 initiators and receivers. They can be the same as the data sources or 72 sinks, or can be separate hosts ("proxies"). 74 CASP consists of two layers, the client (C) and messaging (M) layer, 75 as shown in Fig. 1. 77 +-----------------------------+ +-----------------------------+ 78 | | | Discovery protocol | 79 | CASP client (C) layer | | (Scout protocol) | 80 | | | | 81 +-------------------------------------------------------------+ 82 | | 83 | CASP messaging (M) layer | 84 | | 85 +-------------------------------------------------------------+ 86 | | | | 87 | reliable transport layer | | UDP | 88 | (TCP, SCTP, ...) | | | 89 +-----------------------------+ +-----------------------------+ 91 Figure 1: CASP Protocol Layering 93 The motivation for a separate client (application) and messaging 94 layer is given by [2]. For the reasons discussed in Section 5, CASP 95 uses existing transport protocols. 97 CASP establishes sessions. A CASP session consists of all CASP 98 messages that refer to the same state, traverse the same path or 99 parts of it and share the same session identifier, independent of 100 which direction messages travel. 102 The origin and destination of the C and M layers have to be the same 103 for each CASP session. 105 Each CASP message consists of two parts: an application-independent 106 part that handles message routing, discovery and feature negotiation 107 (i.e., the messaging layer), and an application-dependent part that 108 is carried as a payload inside the client layer. We refer to the 109 protocol elements carried in the payload of CASP messages as the 110 client protocol. A sample client protocol for resource reservation is 111 described in [3]. This memo describes the messaging and transport 112 layer common to all CASP client protocols, the common attributes 113 required of client protocols, and a specialized client protocol, 114 namely the scout protocol for next-peer discovery. 116 CASP can establish state for its own use in forwarding messages; the 117 client layer can establish its own state. Expiration of the message- 118 layer state triggers removal of the client-layer state, but the 119 converse may not be true. We assume that client layers within the 120 same messaging layer session share fate and trust. 122 Network nodes that process CASP messages are called CASP nodes. CASP 123 nodes are divided into omnivorous and selective nodes. An omnivorous 124 nodes processes all CASP messages, even if it does not understand the 125 client protocol and thus ignores the client layer object. For 126 example, a CASP node residing at a firewall or NAT may need to see 127 each CASP message, so that it can inspect and modify the traffic 128 selector. 130 A selective CASP node is only interested in messages that carry one 131 of the client protocols it supports. It is not visited by any other 132 CASP message. 134 We call the sequence of omnivorous and selective CASP nodes traversed 135 by a CASP message between the NSIS Initiatior (NI) and the NSIS 136 responder (NR) [4,5] CASP chain. 138 1.2 Protocol Properties 140 CASP has the following properties: 142 Layered: CASP is a layered protocol with two layers, the client 143 and messaging layer. Each can be changed without affecting 144 the other component. A separate discovery component 145 determines the next CASP peer, which can be either the next 146 router, following the data flow direction, or some other 147 node. One example of the discovery component is the scout 148 protocol, a CASP client protocol, that discovers the next 149 CASP peer. 151 CASP uses the services of a reliable transport protocol 152 that provides sequenced, reliable, flow- and congestion- 153 controlled message transport between two CASP nodes. The 154 messaging layer provides state identification, peer-to-peer 155 message routing and other functionality common across all 156 client layers. The client layer contains the application- 157 specific components. 159 A single CASP messaging layer session can be used by 160 multiple client states, to ensure that all client states 161 are removed at the same time. As an example, active 162 networking or firewall traversal state may be bound to QoS 163 state. C state can only exist as long as the underlying M 164 state exists. 166 Network-friendly: While most signaling messages for classical 167 signaling applications are likely to be small and the 168 overall data volume modest, CASP recognizes that there are 169 potential applications that may need to deliver larger 170 volumes of data or larger packets. For example, 171 instantiating active network nodes may require payloads 172 that are significantly larger than typical network MTUs. 173 Similarly, cryptographic signatures may cause even common 174 signaling messages to exceed MTU size. Thus, CASP would 175 have to deal with fragmentation if it were to implement its 176 own reliability mechanism. 178 Also, we believe that the total volume of signaling 179 information between two nodes can be substantial, even if 180 each signaling flow only contributes a message every few 181 tens of seconds. For example, if we assume resource 182 reservation for a VoIP application with 3-minute calls, 183 four 500 byte signaling messages (for establishment and 184 teardown and the responses), a 45 Mb/s access link could 185 see about 64 kb/s of signaling traffic, which is a modest 186 overhead relative to the useful application data (about 700 187 simultaneous calls), but still larger than many 188 applications. Also, during overload situations, user 189 applications will be tempted to retry their reservation 190 requests frequently, so that congestion and flow control is 191 desirable. 193 Thus, instead of using its own retransmission mechanism for 194 each session within the messaging layer, CASP establishes a 195 soft-state peer session. Unlike in BGP, these are 196 established on demand and can be torn down after periods of 197 inactivity. Such sessions are likely to result in 198 significantly improved performance for each signaling flow, 199 since retransmission can use better estimates for round- 200 trip times and can reduce the time to loss discovery to 201 multiple packet spacings plus a one-way delay rather than a 202 conservative estimate of the round-trip time. Given that 203 almost all nodes will already have support for a transport 204 protocol, this approach is likely to greatly reduce the 205 complexity of protocol implementations and avoid subtle 206 interoperability problems. 208 Re-using peer sessions also reduces the number of 209 cryptographic computations. Reusing an already established 210 security association at the transport layer and possibly at 211 the client layer avoids expensive security association 212 establishment when a new connection is set up. TLS with 213 session resuming (RFC 2246 [6]) can further reduce the 214 impact of establishing a new transport association. In case 215 of IPsec, SAs are valid for a given time period (if the SA 216 lifetime is bound to a time duration and not to the number 217 of transmitted bytes) and operates at a lower layer 218 uneffected by TCP and SCTP connections. 220 Thus, new CASP sessions will only very rarely suffer from 221 delays caused by setting up a transport connection. (We 222 expect that frequent session setup will only be necessary 223 if a CASP node exchanges messages with several thousand or 224 more peer nodes with equal frequency, so that maintaining 225 transport sessions becomes infeasible.) 227 Transport-neutral: CASP is transport-protocol neutral. Each peer 228 could use a different transport protocol, with TCP and SCTP 229 [7,8] as RECOMMENDED protocols. Using TCP and SCTP also 230 allows it to use channel security for protection of 231 messaging and client layer messages in a peer-to-peer mode 232 and mutual-authentication via TLS. Note that IPsec can be 233 deployed independent of any upper layer transport protocol. 234 The messaging layer only assumes that the transport layer 235 offers reliable, sequenced message or byte stream delivery 236 with flow and congestion control. 238 Use of TCP or SCTP does not necessarily make CASP NAT- 239 friendly [9], since it carries network addresses by 240 necessity. It may, however, simplify traversal of 241 firewalls. 243 Policy-neutral: CASP does not impose a particular AAA or usage 244 policy, but can carry necessary information for AAA 245 protocols such as DIAMETER [10] or public-key credentials 246 in the messaging or client layer. (We make no claim that 247 CASP can support all AAA architectures or support them 248 equally well.) 250 Soft state: CASP provides a generic soft-state mechanism that 251 can be used by all client protocols. Soft state is only 252 used for logical state, not to deal with packet loss. To 253 maintain soft state, requests are simply resent 254 periodically by each node. Refresh periods can vary among 255 CASP nodes. Nodes can also remove state explicitly. 257 Peer-to-Peer refresh was chosen to allow different 258 choices by each administrator, e.g., to enforce 259 uniform values within an autonomous system or to 260 control resource usage. Non-uniform refresh intervals 261 mean, however, that islands of state can persist. 262 Also, dead applications need to be detected at the 263 client layer. 265 Extensible: CASP is extensible. It consists of a sequence of, 266 possibly nested, type-length-value (TLV) objects. Extension 267 objects can be added at any time. Protocol features are 268 negotiated via feature negotiation, not as individual 269 objects. This allows semantic negotiation such as "node X 270 does not support mandatory feature Y" rather than low-level 271 indications that some combination of objects is not 272 supported. Nodes can add and modify objects. 273 Cryptographically protected client-layer objects must not 274 be modified or reordered. These digitally signed or 275 encrypted objects can be recognized easily by their object 276 identification to prevent accidental modification or 277 reordering as described in Section 16. 279 Signaling message security: CASP integrates security protection. 280 The security mechanisms provide means to protect the 281 different signaling messages in different portions of the 282 network, including first-peer, intra and inter domain. They 283 accomodate environments with varying security and 284 performance requirements. 286 Flow splitting: Some networks route packets differently 287 depending on their flow labels or DSCP. Operators may want 288 to treat signaling packets differently than the 289 corresponding data packets. These two objectives may 290 conflict since it may cause signaling packets to diverge 291 from the data path. 293 Because CASP is split into a signaling protocol and a 294 discovery mechanism, CASP only needs to label the scout 295 (discovery) packets in the same manner as the data packets, 296 but can assign labels to signaling packets based on the 297 handling needed for them. 299 Topology hiding: Even in record-routing mode (Section 6), nodes 300 can hide the addresses of nodes already visited by the 301 message. A more detailed description of network topology 302 hiding is given in 16.5. 304 Light-weight: CASP is light-weight in terms of implementation 305 complexity and message forwarding overhead. CASP is 306 designed so that a forwarding implementation can be 307 implemented with minimal effort, consisting of a socket 308 listening for TCP connections, a next-peer lookup table and 309 a state timer. In some cases, the messaging layer can be 310 implemented in user space by non-privileged (non-"root") 311 processes. Depending on the details of the traffic 312 operation needed, the client layer may, however, require 313 access to protected resources. 315 The proposed security mechanisms try to reuse existing 316 protocols to the extent possible. 318 CASP has not been assigned a port yet; we assume that 319 the port number will be above 512. Also, the M layer 320 may require access to kernel data structures to 321 determine the current network address, particularly 322 for mobile hosts. 324 Due to the re-use of transport connections, session setup 325 latency is, on average, low. Once the authentication and 326 key exchange protocol is finished signaling messages at the 327 M layer can be protected efficiently. 329 Mobility transparent: CASP interfaces with route change 330 detection mechanisms; IP mobility is also treated as a 331 route change case. 333 CASP attempts to satisfy the NSIS requirements [4] and framework [5]. 334 However, it also adds additional functionality, such as support for 335 source-specific multicast (SSM) [11] and multiple discovery modes 336 including edge-to-edge and AS routes. 338 2 Terminology 340 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 341 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 342 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 343 described in RFC 2119 [12] and indicate requirement levels for 344 compliant CASP implementations. 346 3 Definitions 348 CASP node: Application that supports at least the CASP message 349 layer. 351 CASP chain: The collection of CASP nodes traversed by a CASP 352 message from originator to destination. 354 CASP session: The set of CASP messages that refer to the same 355 state record, along a path of CASP nodes. All messages with 356 the same session identifier belong to the same CASP 357 session, regardless of the direction of travel. 359 Downstream: Downstream refers to the direction of the data flow 360 associated with the CASP session. 362 Originator: The CASP node that sends the CASP message. 364 State record: State (data) that is managed by CASP, located on 365 each CASP node. There is both CASP state and client state. 367 4 Message Delivery 369 Messages within a CASP session can be generated by the end points or 370 by any intermediate point. An intermediate CASP node can sent a 371 message when triggered by internal state changes, such as a routing 372 change, or a timer expiration. In either case, messages traverse the 373 remainder of the CASP nodes, unless they exhaust their node counter 374 or reach the target IP address. 376 At the messaging layer, CASP is not a request-response protocol, but 377 rather a messaging protocol, i.e., it delivers messages along a path. 378 Client layer applications can, however, send back responses that 379 allow the originator to confirm that the initial message was 380 delivered and to determine whether the operation was successful or 381 encountered an error. This offers end-to-end reliability. The 382 response message uses the existing transport associations in the 383 reverse direction. At the message layer, such responses look the same 384 as requests. 386 CASP messages using a reliable transport protocol are not constrained 387 in length (except by the CASP length field). They make use of the 388 reliable delivery services offered by the transport layer. CASP scout 389 messages are restricted to the path MTU. 391 Soft-state refresh is performed by each node, using the algorithm 392 described in Section 11. Refresh intervals are randomized around a 393 nominal value provided by the originator. 395 5 Transport Protocol Usage 397 For regular (non-scout) messages, CASP requires reliable, sequenced 398 message delivery with flow and congestion control and can use any 399 transport protocol that supports such a service. (Sequencing is only 400 required for messages within a single CASP session.) Currently, SCTP 401 [8] and TCP provide such services. 403 If we had used a new protocol running directly on top of IP 404 or UDP, we would have had to add much of the same 405 functionality, essentially replicating a full-fledged 406 transport protocol. We believe it is not safe to assume 407 that all signaling messages are small and infrequent. Re- 408 use of connections allows improved round-trip time 409 estimation and amortizes the cost of establishing the 410 connection and security association over many CASP 411 sessions. 413 There generally is only one lower-layer CASP transport connection 414 between any two CASP nodes, regardless of the message and client 415 layer. A CASP node MAY maintain a transport association with another 416 node even if there is no current CASP session. The holding time of 417 these transport connections is an implementation choice. 419 A CASP node discovers the next CASP node for message delivery using 420 any of the methods in Section 9 and then checks if there is an 421 existing transport connection between these two nodes. If so, it 422 sends the CASP message on that transport connection. If not, it 423 establishes a new connection. It is assumed that transport 424 connections are bidirectional, so that response messages can reuse 425 existing transport connections. However, a response message may also 426 establish a new connection if there is no existing one (e.g., after a 427 reboot of the node to be contacted). 429 CASP scout messages can, by their nature, not use an existing 430 transport connection. They are transmitted by the origin towards the 431 network-layer destination, marked with the IP router alert option 432 [13,14]. The originator of a scout message retransmits the message 433 with exponentially increasing time intervals until a response is 434 received, a maximum number of retransmission attempts is reached or 435 an ICMP error message indicates that the destination host or network 436 is unreachable. For each destination and client layer, there can only 437 be one scout message outstanding. 439 Note that a scout message typically does not reach the IP destination 440 address contained in the IP header. 442 6 Message Forwarding 444 CASP messages can be routed either statefully or statelessly. This 445 generality avoids the strict request-response mechanisms found in 446 other protocols. A message has two routing and state fields that 447 determine forwarding behavior: 449 Destination: The destination flag can have five values: 450 "address" (A), "address+record' (AR), "route" (R), "state 451 forward" (SF) and "state backward" (SB). In "address" mode, 452 each node determines the next CASP node within the chain by 453 looking at the destination address object. In 454 "address+route" mode, it also records the local IP address, 455 transport mechanism and port for future CASP messages, 456 using RecordRoute objects. In "route" mode, the node uses 457 the embedded Route object to find the next location. In 458 "state forward" mode, the node forwards the message in the 459 direction of the initial message that established the CASP 460 session. In "state backward" mode, the message is sent 461 towards the previous CASP node. 463 For the "state forward" and "state backward" modes, nodes 464 fall back to "address" mode if there is no state record. 465 This can occur after route changes. 467 State: The state flag can indicate three operations: "no-op" 468 (NOOP), "add" (ADD), "delete" (DEL). The operations 469 manipulate message layer state. With "no-op", the node does 470 not establish any state. ADD establishes state and DEL 471 deletes the state record. All messages within a CASP 472 session should use the ADD operation. Deleting the state 473 record deletes all client states. The NOOP message is meant 474 for messages that should not establish state. 476 In SF and SB modes, the CASP node only inspects the CASP session 477 identifier and then routes the message according to the stored next- 478 node or previous-node information. 480 Error responses typically contain the "delete" flag and one or more 481 error description objects (see below). They can be routed in "state 482 backward" mode. 484 The origination of CASP messages does not imply that the client 485 protocol has to follow the same direction. For example, in a 486 receiver-oriented QoS protocol, the recipient of the CASP request, 487 sent in "SF/ADD" mode, would return a "SB/ADD" message containing the 488 reservation data. 490 7 Message Format 492 Unlike most other protocols, CASP does not have requests and 493 responses. Rather, it is based on messages that can make use of 494 state established or paths discovered earlier, traversing such paths 495 in either the original sequence of nodes or the reverse. 497 The CASP message and its components are type-length-value objects, 498 making it possible to use the messages directly with stream-based 499 protocols such as TCP, without having to add an encapsulation layer. 500 The client protocol is encapsulated in one such object, so that no 501 IPv6-style "next protocol" identifier is needed in the common message 502 part. 504 The objects within a CASP message can appear in any order, except 505 that the first object is the message identifier and the final object 506 in each CASP message is the CASP client payload. The order of objects 507 has no semantic signficance. There can be at most one client payload 508 in each message; the client payload is optional. (For example, a CASP 509 node discovery or "traceroute" message may not need a client 510 payload.) 512 CASP nodes can insert and modify certain objects. The design of 513 objects should separate data that is modifiable from end-to-end 514 constant data, to simplify object signing. CASP nodes do not reorder 515 objects; new objects are added at the end of the message. 517 Restricting CASP messages to one client layer message 518 simplifies error reporting and reduces the number of 519 failure scenarios. 521 Destination flag: Governs the determination of the next node. 522 See Section 6. 524 State flag: Governs state establishment and teardown, with the 525 values ADD, DEL and NOOP. See Section 6. 527 Session identifier: The session identifier describes a CASP 528 session, a set of CASP messages that belong together and 529 refer to the same state. It allows subsequent messages that 530 belong together to add, modify or delete existing state 531 information. 533 The special value of zero indicates that this message 534 neither refers to existing state nor establishes state. The 535 session identifier is a random number with 128-bits in 536 length. The length of this value is motivated to prevent 537 collisions since it has to be globally unique for a given 538 path. Thus, messages that have different CASP origin and 539 destination addresses still belong to the same CASP session 540 if they share a session identifier. Security issues related 541 with this session identifier are described in Section 11 542 and in 16. As motivated in Section 11 it is important to 543 have some sort of identifier which is not based on a 544 network layer address or a combination of it. 546 A globally unique session identifier that is 547 independent of the origin and destination addresses 548 makes it easy for nodes in the middle of the CASP 549 chain to generate messages that only traverse part of 550 the chain. 552 Flow identification: The flow identification (or descriptor) 553 contains fields that assist in the identification of 554 traffic (data packets) which receive treatment by the 555 client-layer protocol. The client layer determines what 556 action is taken for packets matching the flow 557 identification. In case of a QoS reservation client layer 558 the flow identification determines which data packets 559 experience preferential treatment. It therefore maps 560 individual incoming packets to a given QoS class. Depending 561 on the given flow identification values the effect could be 562 a per-flow treatment or a more broad selection of data 563 traffic. Currently, the following fields should be 564 supported: source, destination IP address, port numbers, 565 transport protocol, flow label (for example described in 566 [15]), destination address options (such as the home 567 address), the SPI (which is motivated in [16]), DiffServ 568 code point (DSCP) and VPN tunnel identifiers. 570 A CASP message can contain multiple flow descriptors which 571 might be useful in case of SCTP or for specifying 572 individual flow identifiers which cannot be combined into a 573 single one (e.g. traffic of several non-continuous port 574 regions). A flow identifier should allow ranges of ports to 575 be specified as described in Section 7.13.1 of [17]. The 576 usage of flow identifier stacking was considered but 577 requires further investigations. An application for TSEL 578 stacking would allow reservations for tunnels where the 579 ingress node adds a new flow identifier to a stack knowing 580 that the new traffic selector is useful only for a 581 particular region. The original traffic selector is 582 restored at the egress node. IPv4-to-IPv6 translation is an 583 example of such a flow selector stacking. 585 The flow identifier is included in the common part of 586 a CASP message so that NATs and firewalls can inspect 587 and possibly modify this data. 589 Flow identifiers can change mid-session and mid-chain. 591 Message sequence number: A 32-bit integer that uniquely 592 identifies the message. (Retransmissions are not seen at 593 the message layer.) Each origin issues messages with 594 sequence numbers that increase by one for each message. 595 Message sequence numbers are assigned consecutively by each 596 origin within a CASP session. Sequence numbers are not 597 reset if the transport connection is re-established in 598 mid-session. 600 Sequence numbers are relative to each origin so that 601 intermediate nodes can issue messages without 602 conflicting with the sequence numbers chosen by other 603 nodes in the chain. 605 Origin: The network source address corresponding to the origin 606 of the message; an IPv4 or IPv6 address. Each network 607 source address has its own sequence number space. The 608 network source address does not imply that the data traffic 609 has this origin or destination. 611 Target: The target field indicates the destination IP address to 612 which data packets are later sent. It is used to route the 613 signaling messages along the same path as used by later 614 data packets. 616 Message destination: This field contains either the destination 617 address of the message or a scope flag. The address 618 indicates how far the message should travel; if it reaches 619 the destination named, the CASP chain ends. The address 620 MAY, but does not have to, correspond to the target 621 address. It will be different if the message traverse only 622 part of the path for the CASP session. The message 623 destination address does not have to correspond to the 624 address contained in the flow identifier. For example, for 625 proxied CASP session, they will differ. 627 The scope flag indicates that the CASP chain should 628 terminate at the boundary of the (administrative) scope 629 [18]. 631 For simplicity, only a single scope is supported, 632 rather than, say, nested scopes. This reflects the 633 typical intra/interdomain division or the division 634 between a local network and "the Internet". 636 NodesLeft: To prevent message loops, the NodesLeft counter is 637 decremented by each CASP node and the message is not 638 forwarded if the counter reaches zero. A suitable "node 639 count exceeded" message is returned to the originator if 640 the counter reaches zero. 642 This also allows messages to only traverse parts of a 643 chain of CASP nodes. Other mechanisms are used to 644 restrict the forwarding of CASP messages by scope or 645 address. 647 Lifetime: If this message establishes state, the Lifetime field 648 determines how long the message soft state is to be kept by 649 each node if there is no additional CASP message. The life 650 time is established in an ADD message and can be updated 651 with ADD messages. (NOOP messages do not refer to state and 652 thus there is no lifetime.) Any client state expires with 653 the message state, but client lifetime can be smaller than 654 the message layer session lifetime. State is refreshed 655 node-by-node and may differ at each node. Thus, this value 656 can be adjusted along the CASP chain. 658 Dead branch removal flag: Governs whether to remove the CASP 659 states in the detected dead route. See Section 11. 661 Branch identifier: The branch identifier is a randomly chosen 662 integer that identifies a particular branch. See Section 11 663 for details. 665 There is no message type, since each client protocol, including the 666 scout protocol, identifies its own message types in the client 667 object. 669 In addition, there are a number of optional objects: 671 Record route: The Record route object is filled with the network 672 addresses of CASP nodes that this message has visited. 674 Route: The Route object enumerates the addresses of nodes that 675 the message should visit, along with a pointer that 676 indicates the next node. [TBD: Addresses could be simply 677 removed by the visited nodes, simplifying network topology 678 hiding, but making error diagnosis harder.] 680 8 Capability Negotiation 682 The CASP capability discovery model relies on named capabilities. 683 Capabilities are named by 16-bit unsigned integers. The value 0 is 684 reserved and not used for any capability. Client protocols are 685 registered as capability values. Client protocols need to negotiate 686 their own capabilities, possibly using the same mechanism and data 687 structures. 689 The originator can discover capabilities by including a CapDiscovery 690 object in the request. The object has a list of capabilities and 691 counters. Each node that supports a capability increments the counter 692 for that capability. In addition, an overall node count allows to 693 estimate the fraction of nodes supporting a particular feature. 695 If more detail is desired, the CapRecord object records the address 696 of each node and its list of capabilities. 698 A CapRequired object enumerates the capabilities that are required. 699 These capabilities are used in the discovery phase. A scout message 700 will traverse nodes that do not meet these capabilities and be 701 reflected back to its source by the first node that can satisfy all 702 requirements. If there are multiple CapRequired objects, it is 703 sufficient if the node satisfies the conditions in one of them. 705 Unlike other protocols, CASP does not label individual 706 objects as being mandatory-to-understand or optional. 707 Instead, it identifies certain behaviors that may well rely 708 on a set of objects. Each behavior needs certain types of 709 objects and ignores all others. This makes it easy to 710 define behaviors that require one of N objects. 712 9 Next-Node Discovery 714 There are two basic types of CASP nodes, depending on how close they 715 are to the data path. In next-in-path (Section 9.1), each CASP node 716 attempts to discover the next router along the data path that is 717 CASP-aware. In next-AS mode (Section 9.2), there is one (logical) 718 CASP server for each autonomous system and data packets and CASP 719 requests visit the same AS, but not necessarily the same routers. 720 Other paths, such as scopes [19], are possible, but harder to define 721 as a sequence and will not be considered here. (Scopes are, however, 722 important to limit the propagation of CASP messages.) 724 9.1 Next-in-Path Service 726 The problem of disccovering the next-in-path CASP node can be divided 727 into an intra-domain and inter-domain component. The intra-domain 728 problem can be split into two parts, namely discovering all CASP 729 nodes within a local domain and determining which of these is visited 730 next on the data path. Determining the next node in an adjacent 731 domain (inter-domain) is more difficult. It would greatly simplify 732 the problem if all border routers are CASP-aware. The scout protocol 733 (see below) can locate the next node both within and beyond the local 734 domain. 736 For discovering CASP-aware nodes within a domain, a number of methods 737 can be envisioned: 739 Enhanced routing protocols: It may be possible to extend routing 740 protocols to distribute information about CASP-capable 741 routers to the local routing domain. For example, OSPF [20] 742 could indicate this capability via an Options bit in the 743 common LSA header or a new LSA. A new LSA is needed if 744 capabilities are to be advertised. A CASP node then 745 computes the route based on the CASP request destination 746 address and determines the next CASP-aware node. 748 Routing protocol with probing: Since the identity of CASP-aware 749 nodes is unlikely to change quickly, a CASP node can 750 attempt to contact routers along the path of the request 751 and cache both positive and negative results. Thus, each 752 CASP node will build up a list of the CASP-capabilities of 753 the local domain and can then determine the next CASP node 754 as above. 756 Service discovery: Using standard service discovery mechanisms 757 such as SLP [21], CASP nodes can find out about local CASP 758 nodes and their capabilities. 760 First node: By adding an option to router advertisements [22], 761 local nodes can discover the first CASP node in their path. 763 DHCP: If there is a single CASP node in a local network, DHCP 764 [23] can advertise this node. 766 For inter-domain discovery, it may be possible to add information to 767 BGP advertisements. 769 For next-in-path service, the node wishing to send a CASP message 770 performs the following steps: 772 1. Determine address N of next CASP node for the destination 773 IP address, using routing table inspection or a scout 774 message. 776 2. If there already is a transport association with N, send 777 message on that transport association. Done. 779 3. If not, send a scout message towards the network-layer 780 destination. The first CASP node capable of handling the 781 message responds and includes its IP address in the 782 response. The origin checks whether there is an existing 783 transport association and proceeds as before. 785 The mechanism above works well if the next router in the data path is 786 CASP-capable, as the number of such routers is likely to be modest. 787 If that is not the case, the origin has to send an exploration packet 788 for each new signaling session, since a node cannot generally 789 determine the next CASP node by inspecting the destination address. 791 9.2 Next AS Service 793 CASP messages can be routed so that they "touch down" once per 794 autonomous system (AS), e.g., for a bandwidth-broker service. In this 795 model, each AS has a logical server, possibly consisting of many 796 physical servers, that provide service for a particular CASP client 797 protocol. 799 One mechanism to find an instance of this server is to create a new, 800 per AS, DNS namespace, such as ASN.as.arpa, where ASN is the AS 801 number. DNS NAPTR [24] queries are then used to determine a suitable 802 server for the AS, using the services "CASP+D2X" and "CASPS+D2X", 803 where X is a letter that corresponds to the the transport protocol 804 This specification defines D2U for UDP, D2T for TCP, and D2S for 805 SCTP. Thus, for example, the NAPTR [24] record 17.as.arpa would 806 identify the CASP service in AS 17. Each NAPTR record in turn points 807 to an SRV record, for coarse-grained redundancy and load balancing. 809 This approach has the advantage that an AS can designate different 810 server clusters for different CASP services. Also, it facilitates 811 discovery. 813 This approach is only necessary if the BGP peers for a domain do not 814 speak CASP. Otherwise, they can route and process CASP messages as 815 needed. 817 10 Scout Protocol 819 The scout protocol is a specialized client protocol for CASP, having 820 a relationship to the main protocol somewhat similar to control 821 protocols like ICMP, IGMP and RTCP [25]. It is used to discover the 822 next suitable CASP node and the required soft-state refresh interval. 823 Scout messages are only required if the next CASP node is more than 824 one network-layer hop away (Section 9) and if there is no other 825 suitable means of discovering the next CASP node. (Other mechanisms 826 are preferred if available since they incur lower overhead and 827 delay.) Each CASP node that needs to discover the next node 828 "triggers" a scout message that generates a response indicating the 829 next node. 831 Scout messages use the cap_required capability negotiation mechanism 832 to find a suitable node (Section 8). 834 Scout messages also return the session lifetime desired by the next 835 node. 837 Scout messages are UDP packets containing a subset of the CASP 838 message layer, a small client layer and the IP router alert option 839 [13,14]. There are scout requests and responses that follow the usual 840 UDP request-response pattern of reversing source and destination 841 address and ports. Scout requests have an IP destination address set 842 to the target address of the triggering CASP request. Each CASP node 843 that needs to determine the next node issues a scout request. An 844 omnivorous CASP node always returns a scout response message. A 845 selective CASP node checks if it supports the client protocol and 846 other features named in the scout message. If so, it responds with a 847 scout response message addressed to the packet's source address and 848 port. The scout response contains an address record that describes 849 how the CASP node can be reached, i.e., its IP address, the protocols 850 supported and their ports. If not, the scout message is forwarded 851 like a normal UDP/IP packet. The target node always turns around the 852 scout message. 854 TBD: It may be possible to use ICMP instead of UDP, with a new ICMP 855 message type. 857 Scout messages have their own reliability mechanism. They are 858 retransmitted periodically, with exponentially increasing 859 retransmission interval, starting at 500 ms. 861 Scout messages are strictly limited in size to one MTU. They are kept 862 small by only including the common header and a nonce. Requests 863 contain one 64-bit cryptographically random nonce; responses echo 864 that nonce and include an additional random nonce. Responses contain 865 the node's desired lifetime and capability vector, including the 866 security capabilities. Since they do not establish sessions, the 867 sequence number fields in scout messages is zero. 869 Scout messages can estimate the number of non-CASP IP nodes between 870 two nodes by comparing the original IP TTL value to the one received 871 by the next node. The original TTL value, if known, is included in 872 the scout client message. 874 Scout messages transport identity and capability information which 875 are security sensitive, as described in Section 16). Also, an 876 attacker can mislead a node into contacting the wrong next CASP node. 877 We define two nonces that protect against these attacks. The first 878 nonce, InitiatorNonce, is in the scout client layer and is echoed by 879 the target node. That prevents attackers that are not privy to the 880 request from impersonating a CASP node. It does not prevent an 881 attacker that can intercept the scout request from returning a bogus 882 response. The ScoutCheck object in the scout response deals with this 883 latter threat. The ScoutCheck allows the next CASP node to detect if 884 it is receiving a request that was preceded by a scout request. The 885 ScoutCheck object contains the InitiatorNonce and a quantity computed 886 by the next CASP node. The method used for computing this quantity is 887 implementation-defined; one possibility is a hash across a secret 888 known to the next node only and the InitiatorNonce. 890 To reduce the threat of such denial-of-service attacks, CASP nodes 891 SHOULD listen for all scout responses. (TBD: If a CASP node responds 892 to all such answers, this would introduce an amplification attack, 893 but this only occurs for attackers that can intercept messages, not 894 random Internet hosts.) 896 11 Route Change and Mobility 898 CASP adapts to route changes and node mobility. It supports fast 899 release of state on the old data paths that is no longer needed. 900 There are two cases: 902 Observed: The next CASP node is also the next IP router. In that 903 case, the CASP node can observe changes in the local 904 routing table and detect that the next-hop router for a 905 particular set of destinations has changed. If such a 906 change occurs, the node triggers the discovery process 907 (Section 9) to locate the new CASP node. 909 Refresh: CASP sessions are refreshed periodically end-to-end. 910 Even if there was no change in the routing table, each CASP 911 node has to perform the discovery process for each such 912 message since it has no way of knowing whether the old next 913 next CASP node is still correct. 915 If a CASP node sends a message to a CASP node that differs from the 916 existing next node for a session, that node becomes a branch point. 918 When a node receives a CASP message for an existing session, but with 919 a different IP source address, i.e., a different previous node, it 920 deduces that it is the merge point after a route change. The merge 921 point then performs dead-branch removal iff the dead-branch removal 922 flag is set, removing CASP state on nodes that are no longer on the 923 data path. The merge point, M, creates a DEL message and sends it to 924 the old previous node. The CASP origin is set to M, the CASP 925 destination of the message to the origin of the message that 926 triggered the dead-branch removal. 928 Having the merge point perform dead branch removal avoids 929 that state is removed before new state is installed. 931 We define a branch identifier that is incremented at each node if a 932 node sends a CASP message to a new next node for a given session. 933 Branch identifiers are defined within a session only. 935 TBD: Alternatively, the branch node could insert its 936 address, but this works less well for mobile systems or for 937 systems with addresses that are not globally unique. 939 Mobility is regarded as a special case of route change in CASP 940 processing, i.e., the mobile node (source or destination) is the node 941 which detects the route change. 943 Figure 2 shows an example of a route change. The old path traverses 944 the CASP nodes N1, N2, N3, and N6, while the new path traverses N4 945 and N5. N1 is the branch point, N6 the merge point. The notation "B=" 946 refers to the branch identifier. N6 detects that it is a branch point 947 and sends back a DEL message on the old branch, but using the new 948 branch identifier (B=2). N2 and N3 simply delete the old state; N1 949 recognizes that it generated the new branch and thus can terminate 950 the DEL. 952 <-DEL(B=2)- 953 +----+ +----+ 954 --- | N2 | -- | N3 | -- 955 / +----+ +----+ 956 /B=1 old route 957 / 958 +-----+ B=1 +----+ +----+ +-----+ 959 | S | -- > --| N1 | | N6 |-----| D | 960 +-----+ +----+ +----+ +-----+ 961 / 962 B=2 / 963 +----+ +----+ / 964 --- | N4 | -- | N5 | -- 965 +----+ +----+ 966 new route 967 -ADD-> 969 Figure 2: Route Change 971 12 Multicast Support 973 CASP supports source-specific multicast (SSM) service model [11], 974 which allows one-to-many group communications. 976 This can be achieved by a special scout message for SSM multicast. If 977 a node receives or initiates a CASP message intended for an SSM 978 multicast group, it sends a scout message towards the SSM 979 destination. The source and destination of this scout message should 980 be set (e.g., via raw socket) as the SSM source S and the destination 981 G, respectively. Also, the actual address of this CASP node should be 982 included in the scout message so that a CASP node receiving the scout 983 message can reply to the right address. There are two possibilities 984 to do this: either use origin object in scout message, or introduce 985 an optional scout-sender object. This scout message can detect new 986 and old branch(es), thus CASP transport association along the 987 source-specific multicast tree can be created, updated or removed. 989 If an SSM multicast routing entry (S, G) is created in an 990 SSM-enabled node, only messages with source address S and 991 destination address G can be forwarded according to this 992 entry. 994 In case the multicast routing next hop is CASP-aware, it is possible 995 to speed up the process by inspecting the IP multicast routing next 996 hop table as defined in the IP multicast MIB [26,27]. 998 1. If all the next hop addresses have an associated CASP 999 state, done. 1001 2. If a next hop has not yet CASP transport association (i.e., 1002 pruning a new branch), it sends an "SF/ADD" message to the 1003 next hop in this branch to create a new CASP transport 1004 association. 1006 3. If a next hop was previously in the next hop table, but 1007 currently not any more, it sends an "SF/DEL" message toward 1008 this next hop to release the the unnecessary CASP transport 1009 association due to dynamic receiver membership. 1011 Typically, multicast support replies on the special scout 1012 message in addition to similar mechanisms that handle route 1013 changes (Section 11). 1015 13 CASP over Tunnels 1017 The authors of [28] identified three types of tunnels. These tunnels 1018 are differentiated whether they support QoS reservation and to which 1019 degree (per-flow allocated resources within the tunnel or non-flow 1020 allocated resources). CASP tunnel operation as described in this 1021 document is independent of the C layer operation. The implication of 1022 tunnels is therefore that they modify routing and they might require 1023 modification to the traffic selector since information like ports and 1024 transport protocols are hidden. Unlike RSVP only the scout protocol 1025 uses a router alert option. A CASP aware ingress node can therefore 1026 decide whether to hide the router alert option. In case that the 1027 router alert option is hidden then the egress node is the next 1028 discovered CASP peer (assuming the egress node is CASP aware). 1029 Otherwise other CASP nodes along the tunneled region can be 1030 discovered as well. 1032 CASP can operate over any types of tunnels (for example IPsec, IP- 1033 in-IP, IPv4/IPv6) if both ingress node and egress node of a tunnel 1034 support CASP. In case that CASP is not supported at these nodes then 1035 the CASP messages are hidden inside the tunnel region. The scout 1036 messages then do not discover CASP nodes inside the tunneled region 1037 because of the IP encapsulation of the router alert option. 1039 Tunnels similar to those used in micro- and macro-mobility schemes 1040 where tunneling affects the traffic of a single host only (i.e. 1042 where the end-host usually participates in tunnel establishment and 1043 termination) are covered by CASP in the following way: A modification 1044 to routing (based on the establishment of a tunnel for example 1045 because of route optimization in Mobile IP) might require adaptation 1046 of the traffic selector along the path (or at parts). The same is 1047 true when (possibly nested) IPSec tunnels are used along the path to 1048 protect data traffic. Traffic selectors need to reflect the different 1049 traffic classification possibilities at various locations along the 1050 path. A careful selection of traffic selectors might therefore help 1051 not to require adjustments of state established along the path when 1052 changes in routing happen. 1054 14 Protocol Heritage 1056 CASP attempts to borrow concepts and ideas that have worked well in 1057 other application and network-layer signaling protocols. Examples 1058 include: 1060 o The message format and the use of router alert options in 1061 scout messages is similar to RSVP [29]. However, CASP differs 1062 from RSVP in having a clearer layering and avoids the 1063 complexities of implementing components of a transport 1064 protocol [30]. 1066 Multicast support is offered for source-specific multicast 1067 (SSM) [11], without the complexity of reservation styles [31], 1068 receiver diversity and maintaining multiple multicast sink 1069 trees in the signaling protocol. 1071 o The notion of separating delivery and application was first 1072 explored by CSTP [2]. 1074 o The feature negotation approach borrows from RTSP [32] and SIP 1075 [33]. 1077 o The notion of messaging is also explored in BEEP [34]. 1079 15 IANA Considerations 1081 A future version of the document will include IANA considerations for 1082 object types, client protocols and port numbers for the CASP 1083 protocol. 1085 16 CASP Security 1087 This section addresses various security issues of the CASP protocol 1088 with some background information and possible options. Additionally 1089 some threat-specific details are explained which are not yet covered 1090 or not described in detail in [35]. Many of the protection mechanisms 1091 described are based on what was learned when investigating security 1092 mechanisms in RSVP as described in [36]. 1094 The content of this section is organized as follows. The first 1095 paragraph investigates the scout protocol security. The next two 1096 paragraphs focus on securing the transport of signaling messages at 1097 various places in the network and the session (or reservation) 1098 ownership problem. Next a description of the CMS [37] usage for the 1099 client-layer is provided. Finally a miscellaneous issues section 1100 addresses security features which are somewhat independent of the 1101 previous sections and could also be entitled as framework security 1102 topics. Some of these security topics are not directly applicable for 1103 securing the CASP protocol itself but try to highlight the 1104 interaction with other protocols. The CASP protocol is designed not 1105 to rule out interactions with some other protocols or deployment 1106 within some non-standard architectures. 1108 A summary of this fairly detailed section is given in security 1109 considerations section for the impatient reader. 1111 16.1 Scout Messages 1113 Problem-Description: 1115 The task of bootstrapping a node with configuration 1116 information is an important and security relevant task. 1117 CASP relies on a number of mechanisms for discovering the 1118 next CASP-aware peer. As described in Section 9 1119 additionally to learning the identity of the next peer some 1120 capability information is provided. Every of the proposed 1121 protocols for distributing information is therefore 1122 vulnerable to similar attacks. This section however is 1123 mainly focused on the description of threats and the 1124 security of scout messages since the mechanisms is 1125 different to what is used for learning (or distributing) 1126 configuration information in general. A description of the 1127 vulnerabilities created by using other protocols like DHCP, 1128 Router Advertisements, etc. might be included in a future 1129 version of this document. 1131 The main purpose of scout messages is to discover the next 1132 CASP-aware network element with a certain capability along 1133 the path. Since a scout message uses the router alert 1134 option mechanism it follows the data path by using the 1135 destination address of the IP packet as the endpoint 1136 destination address. As such it is not helpful to include a 1137 keyed message digest (or a similar cryptographic protection 1138 based on symmetric keys) already to the outgoing message 1139 since the identity of the receiving node is unknown. Using 1140 public key based cryptography (for example a digital 1141 signature) to protect the outgoing scout message could be 1142 used by an adversary to mount denial of service attacks 1143 against CASP-aware nodes. Nothing prevents an adversary 1144 from transmitting millions of bogus scout messages to a 1145 CASP node and to force heavy cryptographic processing for 1146 verification. Note that it would be possible to include a 1147 digital signature to the response to provide identity 1148 information of the responder in a cryptographic protected 1149 manner. Using such a mechanism could however easily be used 1150 as a denial of service attack. 1152 Scout messages are continuously transmitted from the 1153 initiator towards the destination address to react on route 1154 changes (if no other configuration mechanism is used). 1155 Protecting scout messages which are sent towards the 1156 destination address knowing that they will hit a known CASP 1157 peer security protection is possible. However such a 1158 protection is not particularly useful since the scout reply 1159 messages of interest are those that indicate a path change. 1160 These scout messages hit a new CASP-aware router which 1161 returns among some other information its identity as 1162 described in Section 9 and in 4. 1164 Threat 1: Downgrading Attack: 1166 Security relevant information included in the scout message 1167 for example is the identity of the next CASP-aware network 1168 device, supported security mechanisms (namely IPSec, TLS 1169 and EAP as described in this document) and other 1170 capabilities. In case of IPSec various key mangement 1171 protocols can be supported and also have to be indicated. 1172 Downgrading attacks are therefore easily possible when no 1173 protected negotiation takes place. 1175 Threat 2: Man-in-the-Middle: 1177 An adversary might want to inject a bogus reply message 1178 forcing the scout message initiator to start a transport 1179 layer connection and the corresponding security association 1180 establishment. Figure 3 describes the attack in more 1181 detail. 1183 Figure 3: Man-in-the-Middle Attack 1184 +-----------+ 1185 | adversary | transport layer connection 1186 +--->+ +<----------------+ (4) 1187 transport | +----+------+ | 1188 layer | IPx | | 1189 connection | |scout reply v 1190 (3) | | (IPx) +---+-------+ 1191 v | (2) | Access | 1192 +------+-----+ | /----------->+ Router +-------- 1193 | scout msg +<--+ / scout +-----------+ 1194 | initiator +---------/ request IPr 1195 +------------+ (1) 1196 IPi 1198 This attack assumes that the adversary is able to eavesdrop 1199 the initial scout message sent by the scout message 1200 initiator, for example by a mobile node. A MITM-attack does 1201 not require that the first-hop router is CASP aware. There 1202 is no particular restriction to the placement of CASP-aware 1203 nodes within the network. Furthermore we assume that the 1204 scout reply message by the adversary returns to the scout 1205 message initiator faster than the real response. This 1206 represents some race condition characteristics if the next 1207 CASP aware node is very close (in IP-hop terms) to the 1208 initiator. 1210 As shown in message step (2) in Fig. 3 the adversary 1211 returns a scout reply message with its own IP address as 1212 the next CASP aware node along the path. Without any 1213 additional information the scout message initiator has to 1214 trust this information. Then a transport layer connection 1215 is established with IPx (i.e. with the adversary) in step 1216 (3). The adversary then establishes a transport layer 1217 connection with the "real" next CASP aware node (in Fig. 3 1218 with the Access Router). 1220 As a variant of this attack an adversary not able to 1221 eavesdrop transmitted scout requests could flood a node 1222 with bogus scout reply messages. In the scout message 1223 sender accidentally accepts one of those bogus messages 1224 then a MITM-attack as described in figure 3 is possible. 1226 Threat 3: Bogus Reply: 1228 An other threat which would disturb the protocol behavior 1229 and would serve as a sort of denial of service attack is 1230 the following: An adversary might return a bogus scout 1231 reply message indicating a different identity which is 1232 still legimate CASP node (but not the first CASP node). The 1233 scout message initiator would then establish a transport 1234 layer connection with the wrong node. One of the possible 1235 consequences is that data traffic might not experience 1236 proper QoS treatment (in case that a QoS client layer is 1237 used) since signaling message establish state not along the 1238 data traffic. It would be very difficult for both nodes to 1239 discover this type of attack without any precautions. 1241 An other variant of this attack is the following. An 1242 adversary returns a bogus Scout-reply message to convince a 1243 CASP node to establish a new connection with a different 1244 CASP node although the previous connection is still valid. 1246 Proposed Security Protection: 1248 Providing iron-clad security protection for scout messages 1249 is difficult. Since they provide information to the 1250 initiator of the scout message to which node to start the 1251 establishment of a transport layer and security association 1252 establishment some threats are possible. 1254 - As part of the security association setup process at the 1255 M layer authentication and authorization has to be 1256 provided. Authentication and authorization prevent 1257 identity spoofing and MITM attacks. 1259 - To prevent downgrading attacks the information exchanged 1260 at the scout protocol is repeated later at the messaging 1261 layer to verify the exchanged information. Since 1262 signaling messages have to be protected this mechanism 1263 allows to detect a downgrading attack. It assumes that 1264 the downgraded security mechanisms (because modified by 1265 an adversary) provides the necessary security for 1266 detecting the modification. An adversary would therefore 1267 have to break the chosen security mechanism in realtime 1268 in order not to be discovered. This approach is somewhat 1269 similar to the protocol exchange provided in [38]. 1271 Downgrading to no security protection must not be 1272 possible since various attacks could be mounted against 1273 the CASP signaling protocol even if separate protection 1274 at the client layer via CMS is provided. 1276 - To prevent bogus replies and MITM attacks in addition to 1277 authentication and authorization two cookie values are 1278 used (Cookie(i) and Cookie(r)). 1280 - A scout request message contains a Cookie value 1281 (Cookie(i)) which is a 64-bit random number to match 1282 replies with requests. Including Cookie(i) also in the 1283 reply message prevents adversaries from accidentally 1284 accepting a bogus scout reply message from an 1285 adversary. 1287 - A scout response message contains the second Cookie 1288 value (Cookie(r)) with the same length which servers 1289 functionality similar as used in Mobile IPv6 [39] (for 1290 securing the binding update between the mobile node and 1291 the corresponding node). A Cookie field with variable 1292 length would be required when the Cookie contains 1293 encrypted fields (such as Cookie(i)) instead of a keyed 1294 message digest algorithm. In any case no per-session 1295 state should be stored at the scout message responder 1296 when receiving the initial scout message. In order to 1297 prevent MITM and bogus replay type of attacks the 1298 exchanged information (or some parts of it) might be 1299 included in the computation of a keyed hash or 1300 encrypted with a locally known key. 1302 - Both cookie values are included later in the protected 1303 signaling message exchange. When receiving the Cookie 1304 value a verification at the responder is possible. 1306 If an adversary injects bogus reply messages then a 1307 verification step would immediately fail since the new 1308 CASP responder would detect the attack when verifying 1309 Cookie(r). 1311 Since the Cookie(r) value has to be verified only locally 1312 its structure is mostly implementation specific. One 1313 suggestion for creating this cryptographic cookie would 1314 be to use Cookie(r)=Encrypt(local Cookie(i)) in case 1315 of encryption or key, 1316 Cookie(r)=HMAC-MD5(local ScoutRequestMsg||ScoutReplyMsg) 1317 in case of a keyed integrity algorithm. Note that the 1318 values used inside the cookie have to be repeated later 1319 to support the verification. The time interval for 1320 changing the local host key (local ) is policy 1321 dependent. key 1323 - To prevent the variant of the bogus reply attack whereby 1324 an adversary wants the scout message sender to create a 1325 new transport layer connection to tear down the old but 1326 still valid connection the following counter-measure is 1327 necessary. The establishment of a new connection (in 1328 replacement to an existing one) must be successful before 1329 a tear down of the previous connection takes place. 1331 16.2 Securing the Transport and Messaging Layers 1333 The security protection of signaling messages at the messaging layer 1334 can be classified into authentication, integrity and replay 1335 protection. Providing proper data origin authentication, integrity 1336 and replay protection is required as motivated in [4] and in [35]. As 1337 a difference to the security provided in RSVP [40] the support for 1338 authentication and key establishment protocols should be integrated 1339 at the early beginning of the protocol. 1341 TCP and SCTP are the main protocols for exchanging signaling message 1342 content. It is therefore useful to reuse existing security protocols 1343 to protect the integrity of signaling messages. In case of TCP and 1344 SCTP a good choice is TLS providing both session key establishment 1345 based on unilateral and optionally mutual public key based 1346 authentication as described in [6]. Additionally support for Kerberos 1347 as described in [41] is available although rarely used. This is 1348 primarily because of the dominance of public key based server-to- 1349 client authentication in the web environment. As an alternative IPSec 1350 [42,43] can be used to secure CASP signaling messages (not including 1351 the scout messages) at the network layer. IPSec allows a separation 1352 between the key exchange protocol and the actual protection of data 1353 packets. IPSec AH and IPSec ESP provide protection of IP packets 1354 whereas various key exchange protocols may be used to establish the 1355 required IPSec SAs. IKE [44] is the default key management but also 1356 KINK [45] and in the near future SON-of-IKE ([17], [46]) can be used. 1357 These authentication and key exchange protocols allow some room for 1358 adaptation to particular environments with different trust 1359 relationships. 1361 Establishing security associations for protecting signaling messages 1362 at different parts of the network is however difficult. Hence the 1363 following subsections describe the security issues at each part of 1364 the network. 1366 First-Peer Communication: First-peer communication refers to the 1367 communication between the originator of the signaling 1368 message and the edge router in the attached network. In 1369 most mobility scenarios the signaling messages are 1370 initiated by (or terminate at) the mobile node. The 1371 signaling messages when entering the visiting network (i.e. 1372 access network) are intercepted most likely at the edge. 1374 The protection of first-peer communication is probably the 1375 most difficult for a number of reasons. First there is lack 1376 of trust between the initiator and the first network. This 1377 requires special care for authentication and more 1378 difficulties in session key establishment. Next there is a 1379 need to support a larger number of authentication and 1380 session key establishment protocols. 1382 Different usage scenarios for CASP require support for a 1383 particular authentication mechanism and a smooth 1384 integration into the existing infrastructure. Furthermore 1385 there are both performance limitations that exclude one or 1386 the other authentication and session key establishment 1387 protocol. 1389 In the following text the advantages and disadvantages of 1390 using TLS and IPSec for protecting signaling messages are 1391 described. 1393 When considering possible difficulties listed in the above 1394 paragraph then the problem of securing the signaling 1395 messages can be separated into two parts. The first part is 1396 the actual protection of the messages similar to what is 1397 known from the TLS Record Layer or from IPSec ESP/AH. The 1398 protocols either add a keyed message digest or encrypt the 1399 message and add replay protection (based on sequence 1400 numbers) to it to protect the messages from eavesdropping 1401 (only in case of confidentiality protection) and from 1402 modification. 1404 The TLS Handshake Layer provides session key establishment, 1405 unilateral and optionally mutual authentication. Although 1406 TLS offers client to server authentication as an option we 1407 suggest running EAP [47] on top of TLS whereby the EAP 1408 exchange is protected by TLS to support client to visited 1409 network authentication. Note that the approach taken to 1410 secure CASP is different to the approaches suggested to 1411 protect the EAP message exchange with TLS (see [48] and 1412 [49]). The main motivation for choosing this approach is to 1413 make use of an existing protection mechanisms as provided 1414 by the TLS Record Layer. Issues regarding session resuming 1415 as described in Section 4.2 of [49] are however applicable 1416 also in this context. Additionally the usage of [50] for 1417 including OCSP [51] protocol information within the TLS 1418 protocol for the purpose of certificate validation might 1419 also be useful in this context as described in Section 4.3 1420 of [49]. The decision to protect EAP with TLS was therefore 1421 not done for protection of EAP message payloads or for 1422 providing client identity protection in mobile 1423 environments. Nearly all EAP mechanisms do not require 1424 confidentiality protection of the EAP message exchange 1425 itself. Even though some EAP mechanisms allow the 1426 distribution of a session key there is currently no support 1427 for a protection mechanism at the transport layer similar 1428 to the modular IPSec approach where the key management is 1429 separated from the actual data protection mechanisms. Using 1430 the fresh session key distributed with AAA (based on some 1431 EAP methods) could for example be used to trigger IKE with 1432 pre-shared secret authentication mode. Using the EAP 1433 distributed keys immediately (without running IKE) for 1434 creating IPSec SAs is not possible since information of IKE 1435 Phase II (IPSec SA negotiation) is missing. 1437 When using TLS we believe that a non-public key based 1438 client-to-visited network authentication mechanism is 1439 required since not every client is supposed to support 1440 client certificates. Using mutual public key based 1441 authentication requires a widely deployed PKI. We think 1442 that a requirement for a global PKI would put a large 1443 burden on the deployment of a protocol. 1445 An additional motivation for supporting EAP to support 1446 authentication from the client-to-visited network is that a 1447 previously established session key can be reused and local 1448 authentication to the local AAA server is executed. In 1449 future versions of this document message flows and 1450 suggestions for EAP authentication methods will be given. 1452 Support for IPSec-based protection with IKE or similar to 1453 establish an IPSec SA to protect signaling messages between 1454 the CASP peers requires interaction between the CASP 1455 implementation and the key management daemon. First there 1456 needs to be an interface to trigger the dynamic creation 1457 and modification of IPSec security associations (such as 1458 provided by PF_KEY [52]). Since protection is necessary for 1459 the CASP signaling messages only the IPSec security policy 1460 database should be able to install traffic selectors with a 1461 granularity at protocol type (TCP, SCTP) and specific port 1462 numbers. Additionally there is a need to fetch the 1463 credentials used at the key management protocol for the 1464 purpose of policy based admission control and accounting. 1465 Using TLS these tasks are easy since these APIs are 1466 available and widely used for example comparing the 1467 identity used in a certificate and the URL at a TLS- 1468 supporting web browser. We believe that the protection of 1469 the transport layer and messaging layer and a separate 1470 protection at the client layer for the purpose of "identity 1471 representation" [53] as done in RSVP might not be required 1472 in most scenarios. This is especially true if both 1473 mechanisms terminate at the same endpoint. 1475 Intra-Domain Communication: Protecting signaling messages within 1476 a single administrative domain is simpler because of the 1477 strong trust assumptions, simplified key management and 1478 rare network topology changes. Both TLS and IPSec would 1479 satisfy the requirements for protecting signaling messages 1480 in on a peer-to-peer basis. For key management both pre- 1481 shared secret (IKE, main or aggressive mode with pre-shared 1482 secret authentication), Kerberos (KINK [45], Kerberos 1483 support for TLS [41]) and public key based key management 1484 (IKE, SON-of-IKE, TLS) are available. The variety of key 1485 exchange protocols gives administrators a large degree of 1486 freedom. 1488 Inter-Domain Communication: For inter-domain communication again 1489 TLS and IPSec can be used. The only difference is the more 1490 difficult key management which might demand a public key 1491 infrastructure used between the network operators. 1493 End-to-End Security: At the messaging layer no end-to-end 1494 security (encryption or integrity) of the signaling 1495 messages is provided. This is primarily due to the fact 1496 that intermediate CASP-aware nodes have to read or modify 1497 certain parts of the message. Message objects that need 1498 not to be read or modified by nodes along the path direct 1499 end-to-end communication is likely to be more efficient and 1500 appropriate. If a specific protocol usage requires that 1501 some objects have to be protected in an end-to-end fashion 1502 then the following two approaches are possible: 1504 - The required objects could be exchanged between the 1505 desired parties (i.e. end-to-end) without using CASP at 1506 all. 1508 - If the objects in question have relevance for a 1509 particular client-layer (and therefore for some other 1510 objects along the path) then CMS protection and 1511 encapsulation of objects might be the best choice. 1513 16.3 Session Ownership 1515 By allowing a node to refer to a previously established session state 1516 an identifier is required. This session identifier is independent of 1517 a traffic selector. Apart from different options for generating such 1518 an identifier the question arises how a node proves whether it is 1519 owner of a session state or not. In the following section first a 1520 problem description is given, then different solutions approaches are 1521 discussed and finally a solution is proposed for the CASP protocol. 1523 Problem Description: The CASP protocol is used to establish 1524 distributed state along a path in the network. The number 1525 of nodes storing state might be be larger (for example 30) 1526 and could also vary from time to time (for example in case 1527 of route changes). The session identifier is used to point 1528 to a particular stored state at each router. If an 1529 adversary is able to obtain the session identifier (for 1530 example by eavesdropping) then he might attach himself to 1531 any node along the path to modify existing state 1532 information. Only the participating entities end-hosts and 1533 routers should be able to trigger session state 1534 modifications. Routers must be able to react on route 1535 changes to execute a local repair mechanism. Hence a 1536 protection mechanism should only protect against nodes 1537 which are never intended to participate in the signaling 1538 message exchange. 1540 Some of the described problems are less problematic in 1541 non-mobile environments since the first CASP-aware router 1542 (for example the edge or access router) could easily 1543 associate authentication state with the reservation 1544 identifier. Hence ownership verification is possible. If we 1545 assume a mobility scenario then the movement of a node 1546 makes this verification step much more difficult since each 1547 CASP-aware node along the path could possibly forced to do 1548 this verification. 1550 Figure 4 depicts the session ownership problem for a 1551 mobility case: 1553 Figure 4: Session Ownership Problem 1555 Figure 4 shows that the mobile node establishes state at 1556 CASP nodes along the path. As a result the Access Router1 1557 (AR1) (and other nodes along the path - Router1 (R1), 1558 Router3, Router4, etc.) store a session state including the 1559 session identifier (SIDx). As assumed only the mobile node 1560 and the AR1 (prior to the movement of the mobile node) 1561 share a security association. Signaling message 1562 +--------+ 1563 +-----------------+ Router +----> 1564 | SIDx | 4 | 1565 +---+----+ +--------+ 1566 | Router | SIDx 1567 +------+ 3 +<-----+ 1568 | +---+----+ | 1569 | | 1570 | SIDx | 1571 +---+----+ +---+----+ 1572 | Router | | Router | 1573 | 1 | | 2 | 1574 +---+----+ +---+----+ 1575 | ^ 1576 | SIDx | SIDx 1577 +---+----+ +---+----+ 1578 | Access | | Access | 1579 | Router | | Router | 1580 | 1 | | 2 | 1581 +---+----+ +---+----+ 1582 | ^ 1583 | SIDx | SIDx 1584 +---+----+ +---+-----+ 1585 | Mobile | |Adversary| 1586 | Node | | | 1587 +--------+ +---------+ 1589 communication between the participating entities is secured 1590 based on the peer-to-peer principle. In our example this 1591 means that AR1 has a security association with router R1 1592 and secures signaling message. The session identity is 1593 included in the signaling messages and forwarded along the 1594 path as it serves as a reference to the established state. 1595 Without end-host mobility an existing session state is 1596 simply modified by transmitting a properly protected 1597 signaling message from the mobile node to the AR1 by 1598 additionally including the session identifier. Verification 1599 can be done at AR1 locally. 1601 An adversary who was able to obtain the session identifier 1602 of the mobile node includes the same identifier (SIDx) in a 1603 new signaling message. The message causes state to be 1604 installed at Access Router2 (AR2) and subsequently at 1605 Router2. Finally the signaling message hits Router3 where 1606 an existing state is noticed. Router3 has to assume a route 1607 change took place. The adversary included a the "dead 1608 branch removal" flag in the signaling message the path 1609 between the mobile node and Route3 is removed. 1611 Router3 is unable to decide whether the new signaling 1612 message was sent from an adversary or from the mobile node 1613 (i.e. the real owner) since there is no additional 1614 information that aids in verification. 1616 Some approaches to address the problem: Some possible means for 1617 verification and proofing ownership of a session are given 1618 below. These examples should give the reader background 1619 information what issues have been considered during the 1620 protocol design phase. Verification can be done by 1622 1. using a cryptographic reservation identifier (for 1623 example by using a reverse hash-chain or by 1624 transmitting a digitally signed reservation whereby 1625 the reservation identifier is the hash of the public 1626 key similar to [54]. This scheme would only allow the 1627 initiator of the signaling message to trigger a 1628 modification. Special handling would be required in 1629 cases where route changes happen within the network 1630 (such as a local repair). Only the entity possessing 1631 the key pair is able to initiate authorized signaling 1632 messages. From the described protocol behavior this is 1633 not desired. 1635 2. being able to authenticate a signaling message at each 1636 router along the path. It is then possible to 1637 associate a particular identity with a reservation 1638 identifier. The reservation identifier may even serve 1639 as a pointer to a security association. Without 1640 knowing the correct key belonging to the reservation 1641 identifier no updates are allowed. 1643 3. using an authorization token based approach. With this 1644 approach the network would return an opaque token 1645 (opaque for the mobile node) to the MN with the 1646 initial signaling message. The token would then be 1647 included in a later signaling protocol message after a 1648 handover. 1650 4. relying on Context Transfer which allows reservation 1651 state to be forwarded from one access router to an 1652 other. Using such a scheme the verification of the 1653 reservation identifier can be done at the new access 1654 router immediately. Unfortunately Context Transfer is 1655 applicable only within a single administrative domain. 1656 Reservation merging is however possible at any 1657 location along the path. 1659 5. verifying a reservation request by help of a 1660 centralized entity within an administrative domain 1661 (for example with the help of the PDP). However this 1662 approach is again only applicable at a single 1663 administrative domain. 1665 6. distributing a session key along the signaling path. A 1666 new signaling message then contains a cryptographic 1667 object which allows the verification at an arbitrary 1668 CASP-aware node along the path where signaling state 1669 was established. 1671 Approach taken by CASP: Providing confidentiality protection to 1672 protect the reservation identifier makes it more very 1673 difficult for an adversary to eavesdrop the session 1674 identifier and to reuse it for a subsequent attack. The 1675 required authentication of signaling message originator 1676 Since authentication is required an adversary can 1677 furthermore not hide its identity when starting an attack. 1679 TLS without integrity-only suites and IPSec ESP without 1680 NULL encryption algorithm [55] provides the desired 1681 confidentiality protection. 1683 To summarize we can state that in order to provide proper 1684 security for the reservation ownership problem a solution 1685 has to face many challenges including performance, state 1686 maintenance and replay protection. The above-described 1687 problem of authorization is not restricted to communication 1688 at the edge as described above. The problem basically 1689 occurs anywhere in the network whenever an old path becomes 1690 invalid and a reservation along a new path has to be 1691 established. The merge point (or cross-over router from the 1692 above mobility scenario) has to make sure that only the 1693 legitimate owner of the reservation issued this request. 1694 The difference between network internal and edge 1695 reservation ownership issues are only trust issues. 1697 16.4 Protection of the Client-Layer 1699 In some scenarios the transport-layer hop-by-hop protection (based on 1700 TLS or IPSec) might not be sufficient. For those cases we suggest the 1701 selective protection of objects at the client-layer by using CMS 1702 where such a protection is meaningful. CMS allows objects to be 1703 protected with a digital signature and in case that the public key of 1704 the recipient is known also encryption. The fact that CMS is known 1705 and already used to protect SIP message parts and also applied to 1706 selectively protect Diameter AVPs convinced us to include support for 1707 such a mechanism. As a difference to Diameter [56] proposed 1708 protection where digitally signed AVPs have a P-bit set but are not 1709 included in the CMS-protected object the CASP protocol always 1710 includes protected objects (both digitally signed and encrypted) 1711 inside a CMS object. This avoids conflicts in complex object 1712 signing/encrypting scenarios. 1714 Additionally to the capability to protect objects CMS also allows a 1715 session key to be established based on a key agreement or a key 1716 transport technique. An established session key would allow to 1717 speed-up the protection of objects between the same peers in a later 1718 point in time. 1720 Since CMS objects are known to be large (because of certificates, 1721 CRLs, digital signatures and the large number of optional support 1722 objects) messages containing these CMS objects often exceed the 1723 maximum MTU size leading to fragmentation. By using a transport layer 1724 protocol like TCP and SCTP such a problem is avoided. 1726 It is worth noting that objects of the Client-Layer do not 1727 necessarily have to be added by the signaling originating host. 1728 Instead for example a PDP might also be able to add a CMS protected 1729 authorization token to allow secure delivery of information within a 1730 specific administrative region. 1732 As mentioned above the identity of the receiving node is required in 1733 case of encryption. If this information is not available beforehand 1734 then a discovery phase similar to the one proposed for Diameter [56] 1735 has to be executed. Since this discovery/negotiation procedure seems 1736 to be useful a more detailed description will be included in a future 1737 version of the document. 1739 16.5 Miscellaneous Issues 1741 The following section discusses security issues which are not 1742 immediately applicable for the operation of CASP. However they are 1743 worth discussing in the context of a framework. Hence this section is 1744 meant to provide background information for a CASP deployment. 1746 Authorization:Authorization in a quality of service environment 1747 is required as part of the policy-based admission control 1748 procedure. What information to include in such a step is 1749 however still under discussion. In a corporate network 1750 environment information such as group membership and 1751 special access rights can be used whereas a very generic 1752 mobile environment scenarios only requires the assurance 1753 that a particular user is able to pay for the requested 1754 resources. 1756 Independent of the question which information to distribute 1757 in a particular scenario for a given application (e.g. QoS 1758 signaling protocol, NAT/Firewall-traversal protocol, etc.) 1759 two possible approaches can be used to deliver the required 1760 information to various entities. 1762 The first approach could be labeled "offline". The handling 1763 is similar to what is offered with Kerberos and Attribute- 1764 Certificates. A processing entity is thereby able to 1765 retrieve the authorization information directly from the 1766 credentials received from the user. Authentication and 1767 authorization information are therefore cryptographically 1768 bundled together. An example how to distribute 1769 authorization information within a Kerberos ticket is 1770 described in [57]. 1772 The second approach is called "online". Using this approach 1773 the processing entity would use the identity based on a 1774 successful authentication and queries a repository which 1775 represents the online characteristic. If the desired 1776 information is not cached at the verifying entity then an 1777 online request is required. One important requirement for 1778 this approach to work is a successful mapping between the 1779 identity used for authentication and the entity with which 1780 the information at the repository can be obtained. If the 1781 information at the repository itself is exchanged based on 1782 for example an AAA exchange between the user's home network 1783 and the visiting network then a mismatch between the 1784 identities might be common. Hence care must be taken to 1785 define an appropriate mapping between different identity 1786 formats used by various authentication protocols (for 1787 example: NAI, DN and Kerberos principal name and realm). 1789 Note that the usage of authorization information inside a 1790 Kerberos ticket or with attribute certificates is currently 1791 rarely used in protocols like KINK, TLS or IKE. Hence some 1792 further investigation is required. 1794 Trust Establishment: 1796 Relying on an authentication and key exchange protocol to 1797 mutually authenticate the both endpoints (and to secure 1798 subsequent signaling messages) in a wireless environment is 1799 often not sufficient. It no additional information is 1800 supplied then it often does not provide particular useful 1801 information to the signaling message originator that the 1802 other endpoint is a router with given IP address (or a 1803 FQDN). This is particularly true in a mobile environment 1804 where a mobile node attaches to the network for the first 1805 time. More important in this case is that either a 1806 successful AAA exchange or the service provider's digitally 1807 signed certificate gives assurance that a particular 1808 business relationship is present and known. In case of 1809 public key based authentication a mobile client would be 1810 pre-configured with some CA certificates that allow 1811 verification of the host-spot provider's certificate. In 1812 most cases it is unlikely that the end hosts is able to 1813 verify the certificate of the access network provider 1814 directly. 1816 Non-Repudiation: Non-repudiation of signaling messages is not 1817 provided as part of this protocol. However CMS allows 1818 Client-Layer objects to be counter-signed where such a 1819 procedure is necessary and useful. The main rationality for 1820 excluding support at the lower layer in the CASP protocol 1821 is based on the question of usefulness and an avoided 1822 performance impact. We think that public key cryptography 1823 should be used only in cases where security associations 1824 have to be established. Much faster cryptographic 1825 protection of signaling messages should be based on 1826 symmetric techniques to lower computational requirements 1827 for nodes participating in the signaling message exchange. 1829 Denial of Service: With the design of the protocol we tried to 1830 avoid possible denial of service vulnerabilities to some 1831 extend. Some denial of service attacks are described in the 1832 context of scout messages. Mechanisms to prevent these 1833 attacks is explained in the same paragraph. 1835 When choosing a transport layer protocol for CASP it should 1836 be noted that TCP is more vulnerable to denial of service 1837 attacks (for example TCP SYN flooding) than SCTP as 1838 described in [8] and in [58]. Using IPSec to protect all 1839 upper layer protocols prevents this attack. 1841 Especially key exchange protocols tend to be vulnerable 1842 against DoS attacks. Hence when using CASP and a specific 1843 key exchange protocol it is necessary to consider such a 1844 vulernability. Since CASP is to some extend a build block 1845 which requires fitting it to a particular architecture this 1846 issue needs to be considered. By using TLS the key exchange 1847 protocol is built-in. Using IPSec a number of options need 1848 to be taken into consideration for each of the protocols 1849 like IKE, SON-of-IKE, KINK etc. 1851 Network Topology Hiding: 1853 This Section discusses network topology hiding issues for 1854 CASP when using a record route message forwarding approach. 1855 Similar issues have already been discussed at the SIP 1856 working group. The following picture should elaborate the 1857 idea in more detail. 1859 As described in figure 5 router R3 serves as a trust 1860 boundary which allows the internal routers R1 and R2 of the 1861 administrative domain A to be hidden. For router R4, which 1862 belongs to a different administrative domain, only the edge 1863 router R3 is visible. When a message with a record route 1864 object arrives at router R1 then the router adds its 1865 identity. The same procedure happens at R2. A policy at 1866 router R3 indicates to hide the internal network entities 1867 to the outside world. Hence when the signaling message 1868 arrives at R3 the identities of router R1 and R2 at the 1869 record route object are replaced by an encrypted version. 1870 The key used for encryption is locally known only and the 1871 rekeying time interval is also policy dependent. The entire 1872 encryption process (including algorithms) is an 1873 implementation issue and requires not standardization 1874 effort. This approach allows R3 still to be stateless. 1875 Finally the result of this encryption and the identity of 1876 R3 is forwarded to R4. When R4 routes a signaling message 1877 back (by visiting the routers as indicated in the record 1878 route in the reverse order) then router R3 decrypts the 1879 encrypted routing information and forwards the message back 1880 to R2 and R1. It should be noted that the encrypted 1881 identity information should be labeled as encrypted to 1882 avoid misinterpretations. 1884 Using a stateful approach where router R3 simply stores 1885 state and indicates only its identity to router R4 the same 1886 result is achieved. In this case topology hiding is 1887 provided as part of state storing at the individual 1888 routers. 1890 For diagnostic and query messages a policy might indicate 1891 whether the processing is allowed or not. However in such a 1892 case some problems with network hiding arise. In general 1893 there is a question whether identity hiding in such a case 1894 is worth the reduced functionality of the protocol. Most 1895 network administrators consider a diagnosis and discovery 1896 capability as a very useful tool in their daily work. The 1897 same is true for developers. 1899 For the above-described issues network topology hiding can 1900 be supported as part of a local configuration or policy 1901 decision. A network administrator should decide whether to 1902 support the above-described mechanism by encrypting the 1903 identities. 1905 ----------------------------------------+ +---------------- 1906 | | 1907 | | 1908 +----+ +----+ +----+ | | +--+-+ 1909 ----+ R1 +--------+ R2 +--------+ R3 +--+---+----| R4 +------ 1910 +----+ +----+ +----+ | | +--+-+ 1911 | | 1912 Administrative Domain A | | Admin.Domain B 1913 ----------------------------------------+ +---------------- 1915 Figure 5: Network Topology Hiding 1917 17 Security Considerations 1919 CASP protocol communication is divided into a discovery part (for 1920 example using the scout protocol) and a regular message exchange for 1921 which a transport layer connection is established. Scout messages 1922 allow the discovery of nodes participating in the CASP protocol (if 1923 no other mechanisms is used). These messages experience custom 1924 security protection. The subsequently established transport layer 1925 connection used to transport M (and C) layer messages is either 1926 protected by the TLS Record Layer or by IPSec ESP. These two 1927 protocols support protection of the CASP protocol messages. In case 1928 of TLS the key exchange protocol is built-in whereas several choices 1929 are offered for IPSec (for example KINK, IKE and in the near future 1930 SON-of-IKE). Signaling messages travel between different parts of the 1931 network where different trust assumptions are valid. To reflect this 1932 circumstance we suggest that intra-domain and inter-domain signaling 1933 message communication should be either protected by TLS or by IPSec 1934 depending on the administrator's choice. For mobile environments 1935 protection of the communication between the mobile node and the 1936 first-peer in the access network might be based on TLS for access 1937 network to client authentication and EAP-based authentication for 1938 client to server authentication. This decision is motivated by the 1939 different requirements for user-to-network authentication and the 1940 non-existence of a global PKI. 1942 The above-described security mechanisms operate in a CASP-peer to 1943 CASP-peer manner. Some Client-Layer objects however might require 1944 additional protection. Digitally signed or encrypted Client-Layer 1945 objects can be provided by CMS as successfully used by other 1946 protocols like S/MIME, SIP or Diameter. Authorization tokens or 1947 information which has to be verified within a domain only can make 1948 use of such a selective protection. 1950 Security protection for the session ownership problem is difficult 1951 and requires more investigation. This document describes the problem 1952 and lists a number of possible approaches to tackle the problem. A 1953 first version of the protocol may rely on confidentiality protection 1954 (as provided by most cipher-suites for TLS and IPSec ESP without NULL 1955 encryption) to avoid eavesdroppers to learn the 128-bit random 1956 session identifier. Without knowledge of this session identifier the 1957 described attack is difficult. Note that CASP-aware network elements 1958 along the CASP chain must know the session identifier in order for 1959 the protocol to operate correctly. 1961 18 Open Issues and Future Work 1963 This Section contains some identified future work items: 1965 o The process of discovering CASP-aware nodes is a security 1966 sensitive process. Some references and considerations 1967 regarding security vulnerabilities of proposed discovery 1968 mechanisms for CASP have to be described (in addition to the 1969 scout description). 1971 o To avoid users the requirement for mutual public key based 1972 authentication in TLS for both first-peer as well as last-peer 1973 communication some additional text has to be provided. 1974 Although EAP is proposed for first-peer communication to 1975 supported non-public key based authentication from a user to 1976 the network the roles of client/server are reversed in case 1977 last-peer communication. 1979 o Selective client layer object protection is provided by CMS. 1980 The process of discover/negotiation needs some further 1981 considerations. Additionally the establishment of symmetric 1982 keys for efficiently protecting multiple message exchanges 1983 have to be considered. 1985 o The usage of EAP is proposed in relationship with client- 1986 authentication. Further work is necessary to describe protocol 1987 interactions and message flows based on some selected EAP 1988 mechanisms. 1990 o Interactions with accounting and charging and their 1991 implications for the security framework will be described in 1992 more detail in a separate document. Together with this 1993 document some basic explanations of the trust relationships 1994 should be provided. 1996 o The security section is more detailed than other parts of the 1997 document. It might be therefore suitable to distribute a more 1998 detailed description of the security issues in a separate 1999 security draft. 2001 19 Acknowledgements 2003 We would like to thank (in alphabetical order) Wolfgang Buecker, 2004 Jorge Cuellar, Rainer Falk and Dirk Kroeselberg for their comments to 2005 this draft. Jorge and Dirk provided us with a large number of 2006 comments to improve the security section of this document. Cornel 2007 Pampu contributed to the mobility discussions. 2009 A Message Format Details 2011 For concreteness, we describe a strawman packet format below. 2013 All CASP messages are composed of one or more TLV (type-length-value) 2014 objects. Within each object, elements are aligned on multiples of 2015 their size, to speed processing. All objects have lengths of a 2016 multiple of 32 bits. The length field in the object indicates the 2017 number of 32-bit words. 2019 We describe messages and objects as pseudo-C structs. Elements are 2020 enumerated in transmission order. We use the data types uint8, 2021 uint16, uint32, uint64, uint128 to identify unsigned integers with 8, 2022 16, 32, 64 or 128 bits, respectively. We define the following data 2023 types: 2025 typedef struct { 2026 uint16 msg_type; 2027 uint16 msg_length; 2028 } tl; 2030 typedef struct { 2031 uint16 length; /* actual string length, in bytes */ 2032 uint8 chars[length]; /* UTF-8 */ 2033 } string; 2034 Message types not defined in this document are registered with IANA 2035 (Section 15). 2037 Text strings are coded in the UTF-8 character set encoding [59]. 2038 They are padded to a multiple of 32 bits with zero bytes. 2040 typedef struct { 2041 tl tl = {message type, total length of packet}, 2042 ... objects ... 2043 } casp_message; 2045 typedef struct { 2046 tl tl = {payload}, 2047 ... payload bytes .. 2048 } casp_payload; 2050 typedef struct { 2051 tl tl = {msgid}, 2052 uint64 random; 2053 } msgid; 2055 A.1 Network Addresses 2057 typedef struct { 2058 int8 network; 2059 int8 transport; 2060 int16 port; 2061 uint128 address; 2062 } ip6_address; 2064 typedef struct { 2065 int8 network; 2066 int8 transport; 2067 int16 port; 2068 uint32 address; 2069 } ip4_address; 2071 typedef struct { 2072 uint8 nonce[20] 2073 } address_cookie; 2075 typedef struct { 2076 tl tl = {,}; 2077 union { 2078 ip4_address; 2079 ip6_address; 2080 } address[]; 2081 } req_route; 2083 The address_cookie object contains an encrypted version of an IPv4 or 2084 IPv6 address. It can be used for topology hiding. A node that wants 2085 to obscure the network addresses in a region encrypts all IPv4 or 2086 IPv6 address objects, adding random salt, and then replaces them with 2087 the address_cookie. Upon return, the node decrypts the address 2088 information and routes the request normally. Thus, the egress node of 2089 a protected region is responsible for encrypting and decrypting 2090 address objects. 2092 A.2 Capability Discovery 2094 typedef struct { 2095 tl tl; 2096 uint16 cap[]; 2097 } cap_discovery; 2099 typedef struct { 2100 tl tl; 2101 uint16 cap[]; 2102 } cap_required; 2104 B Authors' Addresses 2106 Henning Schulzrinne 2107 Dept. of Computer Science 2108 Columbia University 2109 1214 Amsterdam Avenue 2110 New York, NY 10027 2111 USA 2112 EMail: schulzrinne@cs.columbia.edu 2114 Hannes Tschofenig 2115 Siemens AG 2116 Otto-Hahn-Ring 6 2117 Munich 81739 2118 Germany 2119 EMail: Hannes.Tschofenig@mchp.siemens.de 2121 Xiaoming Fu 2122 Technical University Berlin 2123 Sekr. FT 5-2, Einsteinufer 25 2124 Berlin 10587 2125 Germany 2126 EMail: fu@ee.tu-berlin.de 2128 Jochen Eisl 2129 Siemens AG 2130 Otto-Hahn-Ring 6 2131 81739 Munich 2132 Germany 2133 EMail: Jochen.Eisl@icn.siemens.de 2135 Robert Hancock 2136 Roke Manor Research 2137 Old Salisbury Lane 2138 Romsey, Hampshire 2139 UK 2140 EMail: robert.hancock@roke.co.uk 2142 C Bibliography 2144 [1] B. Carpenter and S. Brim, "Middleboxes: Taxonomy and issues," RFC 2145 3234, Internet Engineering Task Force, Feb. 2002. 2147 [2] B. Braden and B. Lindell, "A two-level architecture for internet 2148 signaling," Internet Draft, Internet Engineering Task Force, Nov. 2149 2001. Work in progress. 2151 [3] H. Schulzrinne, H. Tschofenig, X. Fu, and J. Eisl, "A quality- 2152 of-service resource allocation client for CASP," Internet Draft, 2153 Internet Engineering Task Force, Sept. 2002. Work in progress. 2155 [4] M. Brunner, "Requirements for QoS signaling protocols," Internet 2156 Draft, Internet Engineering Task Force, July 2002. Work in progress. 2158 [5] B. Hancock et al., "Towards a framework for QoS signaling in the 2159 internet," Internet Draft, Internet Engineering Task Force, Feb. 2160 2002. Work in progress. 2162 [6] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246, 2163 Internet Engineering Task Force, Jan. 1999. 2165 [7] L. Ong and J. Yoakum, "An introduction to the stream control 2166 transmission protocol (SCTP)," RFC 3286, Internet Engineering Task 2167 Force, May 2002. 2169 [8] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. 2170 Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream control 2171 transmission protocol," RFC 2960, Internet Engineering Task Force, 2172 Oct. 2000. 2174 [9] D. Senie, "Network address translator (nat)-friendly application 2175 design guidelines," RFC 3235, Internet Engineering Task Force, Jan. 2176 2002. 2178 [10] P. Calhoun et al., "Diameter base protocol," Internet Draft, 2179 Internet Engineering Task Force, July 2002. Work in progress. 2181 [11] H. Holbrook and B. Cain, "Source-specific multicast for IP," 2182 Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in 2183 progress. 2185 [12] S. Bradner, "Key words for use in RFCs to indicate requirement 2186 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 2188 [13] D. Katz, "IP router alert option," RFC 2113, Internet 2189 Engineering Task Force, Feb. 1997. 2191 [14] C. Partridge and A. Jackson, "IPv6 router alert option," RFC 2192 2711, Internet Engineering Task Force, Oct. 1999. 2194 [15] J. Rajahalme, A. Conta, B. Carpenter, and S. Deering, "IPv6 flow 2195 label specification," Internet Draft, Internet Engineering Task 2196 Force, June 2002. Work in progress. 2198 [16] L. Berger and T. O'Malley, "RSVP extensions for IPSEC data 2199 flows," RFC 2207, Internet Engineering Task Force, Sept. 1997. 2201 [17] D. Harkins, C. Kaufman, et al., "Propsal for the IKEv2 2202 protocol," Internet Draft, Internet Engineering Task Force, Apr. 2203 2002. Work in progress. 2205 [18] J. Manner et al., "Localized RSVP," Internet Draft, Internet 2206 Engineering Task Force, May 2002. Work in progress. 2208 [19] D. Meyer, "Administratively scoped IP multicast," RFC 2365, 2209 Internet Engineering Task Force, July 1998. 2211 [20] J. Moy, "OSPF version 2," RFC 2328, Internet Engineering Task 2212 Force, Apr. 1998. 2214 [21] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service 2215 location protocol, version 2," RFC 2608, Internet Engineering Task 2216 Force, June 1999. 2218 [22] T. Narten, E. Nordmark, and W. Simpson, "Neighbor discovery for 2219 IP version 6 (ipv6)," RFC 2461, Internet Engineering Task Force, Dec. 2220 1998. 2222 [23] R. Droms, "Dynamic host configuration protocol," RFC 2131, 2223 Internet Engineering Task Force, Mar. 1997. 2225 [24] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR) 2226 DNS resource record," RFC 2915, Internet Engineering Task Force, 2227 Sept. 2000. 2229 [25] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 2230 a transport protocol for real-time applications," RFC 1889, Internet 2231 Engineering Task Force, Jan. 1996. 2233 [26] K. McCloghrie, D. Farinacci, and D. Thaler, "IPv4 multicast 2234 routing MIB," RFC 2932, Internet Engineering Task Force, Oct. 2000. 2236 [27] J. Nicholas, "Protocol independent multicast MIB," Internet 2237 Draft, Internet Engineering Task Force, June 2002. Work in progress. 2239 [28] A. Terzis, J. Krawczyk, J. Wroclawski, and L. Zhang, "RSVP 2240 operation over IP tunnels," RFC 2746, Internet Engineering Task 2241 Force, Jan. 2000. 2243 [29] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, 2244 "Resource ReSerVation protocol (RSVP) -- version 1 functional 2245 specification," RFC 2205, Internet Engineering Task Force, Sept. 2246 1997. 2248 [30] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, and S. 2249 Molendini, "RSVP refresh overhead reduction extensions," RFC 2961, 2250 Internet Engineering Task Force, Apr. 2001. 2252 [31] X. Fu, C. Kappler, and H. Tschofenig, "Analysis on RSVP 2253 regarding multicast," Internet Draft, Internet Engineering Task 2254 Force, June 2002. Work in progress. 2256 [32] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming 2257 protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 2258 1998. 2260 [33] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 2261 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 2262 initiation protocol," RFC 3261, Internet Engineering Task Force, June 2263 2002. 2265 [34] M. Rose, "The blocks extensible exchange protocol core," RFC 2266 3080, Internet Engineering Task Force, Mar. 2001. 2268 [35] H. Tschofenig, "NSIS threats," Internet Draft, Internet 2269 Engineering Task Force, July 2002. Work in progress. 2271 [36] H. Tschofenig, "RSVP security properties," Internet Draft, 2272 Internet Engineering Task Force, June 2002. Work in progress. 2274 [37] R. Housley, "Cryptographic message syntax," RFC 2630, Internet 2275 Engineering Task Force, June 1999. 2277 [38] J. Arkko et al., "Security mechanism agreement for SIP 2278 sessions," Internet Draft, Internet Engineering Task Force, July 2279 2002. Work in progress. 2281 [39] D. Johnson, C. Perkins, and J. Arkko, "Mobility support in 2282 IPv6," Internet Draft, Internet Engineering Task Force, July 2002. 2283 Work in progress. 2285 [40] F. Baker, B. Lindell, and M. Talwar, "RSVP cryptographic 2286 authentication," RFC 2747, Internet Engineering Task Force, Jan. 2287 2000. 2289 [41] A. Medvinsky and M. Hur, "Addition of kerberos cipher suites to 2290 transport layer security (TLS)," RFC 2712, Internet Engineering Task 2291 Force, Oct. 1999. 2293 [42] S. Kent and R. Atkinson, "IP authentication header," RFC 2402, 2294 Internet Engineering Task Force, Nov. 1998. 2296 [43] S. Kent and R. Atkinson, "IP encapsulating security payload 2297 (ESP)," RFC 2406, Internet Engineering Task Force, Nov. 1998. 2299 [44] D. Harkins and D. Carrel, "The internet key exchange (IKE)," RFC 2300 2409, Internet Engineering Task Force, Nov. 1998. 2302 [45] M. Thomas et al., "Kerberized internet negotiation of keys 2303 (KINK)," Internet Draft, Internet Engineering Task Force, Nov. 2001. 2305 Work in progress. 2307 [46] W. Aiello, S. Bellovin, et al., "Just fast keying (JFK)," 2308 Internet Draft, Internet Engineering Task Force, July 2002. Work in 2309 progress. 2311 [47] L. Blunk and J. Vollbrecht, "PPP extensible authentication 2312 protocol (EAP)," RFC 2284, Internet Engineering Task Force, Mar. 2313 1998. 2315 [48] P. Funk and S. Blake-Wilson, "EAP tunneled TLS authentication 2316 protocol (EAP-TTLS)," Internet Draft, Internet Engineering Task 2317 Force, Mar. 2002. Work in progress. 2319 [49] H. Andersson, S. Josefsson, G. Zorn, et al., "Protected 2320 extensible authentication protocol (PEAP)," Internet Draft, Internet 2321 Engineering Task Force, Feb. 2002. Work in progress. 2323 [50] S. Blake-Wilson et al., "Transport layer security (TLS) 2324 extensions," Internet Draft, Internet Engineering Task Force, May 2325 2002. Work in progress. 2327 [51] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, 2328 "X.509 internet public key infrastructure online certificate status 2329 protocol - OCSP," RFC 2560, Internet Engineering Task Force, June 2330 1999. 2332 [52] D. McDonald, C. Metz, and B. Phan, "PF_KEY key management API, 2333 version 2," RFC 2367, Internet Engineering Task Force, July 1998. 2335 [53] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, 2336 and R. Hess, "Identity representation for RSVP," RFC 3182, Internet 2337 Engineering Task Force, Oct. 2001. 2339 [54] S. Bradner, A. Mankin, and J. Schiller, "A framework for purpose 2340 built keys (PBK)," Internet Draft, Internet Engineering Task Force, 2341 July 2002. Work in progress. 2343 [55] R. Glenn and S. Kent, "The NULL encryption algorithm and its use 2344 with IPsec," RFC 2410, Internet Engineering Task Force, Nov. 1998. 2346 [56] P. Calhoun, S. Farrell, and W. Bulley, "Diameter CMS security 2347 application," Internet Draft, Internet Engineering Task Force, Mar. 2348 2002. Work in progress. 2350 [57] Microsoft, "Microsoft authorization data specification v. 1.0 2351 for Microsoft Windows 2000 Operating Systems," tech. rep., Microsoft, 2352 Redmond, Washington, Apr. 2000. 2354 [58] L. Coene, "Stream control transmission protocol applicability 2355 statement," RFC 3257, Internet Engineering Task Force, Apr. 2002. 2357 [59] F. Yergeau, "UTF-8, a transformation format of unicode and ISO 2358 10646," RFC 2044, Internet Engineering Task Force, Oct. 1996. 2360 Table of Contents 2362 1 Introduction ........................................ 3 2363 1.1 Protocol Overview ................................... 3 2364 1.2 Protocol Properties ................................. 4 2365 2 Terminology ......................................... 9 2366 3 Definitions ......................................... 9 2367 4 Message Delivery .................................... 9 2368 5 Transport Protocol Usage ............................ 10 2369 6 Message Forwarding .................................. 11 2370 7 Message Format ...................................... 12 2371 8 Capability Negotiation .............................. 16 2372 9 Next-Node Discovery ................................. 17 2373 9.1 Next-in-Path Service ................................ 17 2374 9.2 Next AS Service ..................................... 18 2375 10 Scout Protocol ...................................... 19 2376 11 Route Change and Mobility ........................... 20 2377 12 Multicast Support ................................... 22 2378 13 CASP over Tunnels ................................... 23 2379 14 Protocol Heritage ................................... 24 2380 15 IANA Considerations ................................. 24 2381 16 CASP Security ....................................... 24 2382 16.1 Scout Messages ...................................... 25 2383 16.2 Securing the Transport and Messaging Layers ......... 30 2384 16.3 Session Ownership ................................... 33 2385 16.4 Protection of the Client-Layer ...................... 37 2386 16.5 Miscellaneous Issues ................................ 38 2387 17 Security Considerations ............................. 42 2388 18 Open Issues and Future Work ......................... 43 2389 19 Acknowledgements .................................... 44 2390 A Message Format Details .............................. 44 2391 A.1 Network Addresses ................................... 45 2392 A.2 Capability Discovery ................................ 46 2393 B Authors' Addresses .................................. 46 2394 C Bibliography ........................................ 47