idnits 2.17.1 draft-ietf-tsvwg-rsvp-security-groupkeying-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 202: '... Section 4.3 of [RFC2747] states that "... the receiver MAY initiate...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 9, 2011) is 4606 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-weis-gdoi-mac-tek-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Behringer 3 Internet-Draft F. Le Faucheur 4 Intended status: Informational B. Weis 5 Expires: March 12, 2012 Cisco Systems 6 September 9, 2011 8 Applicability of Keying Methods for RSVP Security 9 draft-ietf-tsvwg-rsvp-security-groupkeying-11.txt 11 Abstract 13 The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity 14 protection of RSVP neighbors. This requires messages to be 15 cryptographically protected using a shared secret between 16 participating nodes. This document compares group keying for RSVP 17 with per neighbor or per interface keying, and discusses the 18 associated key provisioning methods as well as applicability and 19 limitations of these approaches. The document also discusses 20 applicability of encrypting RSVP messages. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 12, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 4 59 3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5 60 3.1. Per interface and per neighbor keys . . . . . . . . . . . 5 61 3.2. Group keys . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 8 63 4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 8 64 4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8 65 4.2.1. Per Neighbor and Per Interface Key Negotiation . . . . 8 66 4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 9 67 5. Specific Cases Supporting Use of Group Keying . . . . . . . . 9 68 5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 9 69 5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 9 70 6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10 71 6.1. General Considerations Using IPsec . . . . . . . . . . . . 10 72 6.2. Comparing AH and the INTEGRITY Object . . . . . . . . . . 11 73 6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 12 74 6.4. Non-Applicability of Transport Mode . . . . . . . . . . . 12 75 6.5. Applicability of Tunnel Mode with Address Preservation . . 13 76 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 13 77 8. Applicability to Other Architectures and Protocols . . . . . . 14 78 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 16 81 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 13. Informative References . . . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction and Problem Statement 88 The Resource reSerVation Protocol [RFC2205] allows hop-by-hop 89 authentication of RSVP neighbors, as specified in [RFC2747]. In this 90 mode, an integrity object is attached to each RSVP message to 91 transmit a keyed message digest. This message digest allows the 92 recipient to verify the identity of the RSVP node that sent the 93 message, and to validate the integrity of the message. Through the 94 inclusion of a sequence number in the scope of the digest, the digest 95 also offers replay protection. 97 [RFC2747] does not dictate how the key for the integrity operation is 98 derived. Currently, most implementations of RSVP use a statically 99 configured key, per interface or per neighbor. However, to manually 100 configure a key per router pair across an entire network is 101 operationally hard, especially when key changes are to be performed 102 on a regular basis. Effectively, many users of RSVP therefore resort 103 to using the same key throughout their RSVP network, and they change 104 it rarely if ever, because of the operational burden. It is however 105 often necessary to change keys due to network operational 106 requirements (e.g., change of operational staff). 108 This document discusses a variety of keying methods and their 109 applicability to different RSVP deployment environments, for both 110 message integrity and encryption. It is meant as a comparative guide 111 to understand where each RSVP keying method is best deployed, and the 112 limitations of each method. Furthermore, it discusses how RSVP hop 113 by hop authentication is impacted in the presence of non-RSVP nodes, 114 or subverted nodes, in the reservation path. 116 The document "RSVP Security Properties" ([RFC4230]) provides an 117 overview of RSVP security, including RSVP Cryptographic 118 Authentication [RFC2747], but does not discuss key management. It 119 states that "RFC 2205 assumes that security associations are already 120 available". The present document focuses specifically on key 121 management with different key types, including group keys. Therefore 122 this document complements [RFC4230]. 124 1.1. Terminology 126 A security domain is defined in this document as two or more nodes 127 that share a common RSVP security policy. 129 When a key is mentioned in this document, it is a symmetric key. A 130 symmetric key best meets the operational requirements of RSVP 131 deployments, and is the only type of key currently explicitly 132 supported for protecting RSVP messages. 134 2. The RSVP Hop-by-Hop Trust Model 136 Many protocol security mechanisms used in networks require and use 137 per peer authentication. Each hop authenticates messages from its 138 neighbor with a shared key or certificate. This is also the model 139 used for RSVP. Trust in this model is transitive. Each RSVP node 140 trusts explicitly only its RSVP next hop peers, through the message 141 digest contained in the INTEGRITY object. The next hop RSVP speaker 142 in turn trusts its own peers and so on. See also the document "RSVP 143 security properties" [RFC4230] for more background. 145 The keys used for protecting RSVP messages can, in particular, be 146 group keys (for example distributed via the Group Domain of 147 Interpretations (GDOI) [I-D.ietf-msec-gdoi-update], as discussed in 148 [I-D.weis-gdoi-mac-tek]). If a group key is used, the authentication 149 granularity becomes group membership of devices, not (individual) 150 peer authentication between devices. 152 The trust an RSVP node has to another RSVP node within a common 153 security domain has an explicit and an implicit component. 154 Explicitly the node trusts the other node to maintain the RSVP 155 messages intact or confidential, depending on whether authentication 156 or encryption (or both) is used. This means only that the message 157 has not been altered or seen by another, non-trusted node. 158 Implicitly each node trusts the other node to maintain the level of 159 protection specified within that security domain. In any group 160 keying scheme like GDOI a node trusts all the other members of the 161 group (because the authentication is now based on group membership, 162 as noted above). 164 The RSVP protocol can operate in the presence of a non-RSVP router in 165 the path from the sender to the receiver. The non-RSVP hop will 166 ignore the RSVP message and just pass it along. The next RSVP node 167 can then process the RSVP message. For RSVP authentication or 168 encryption to work in this case, the key used for computing the RSVP 169 message digest needs to be shared by the two RSVP neighbors, even if 170 they are not IP neighbors. In the presence of non-RSVP hops, while 171 an RSVP node always knows the next IP hop before forwarding an RSVP 172 Message, it does not always know the RSVP next hop. In fact, part of 173 the role of a Path message is precisely to discover the RSVP next hop 174 (and to dynamically re-discover it when it changes, for example 175 because of a routing change). Thus, the presence of non-RSVP hops 176 impacts operation of RSVP authentication or encryption and may 177 influence the selection of keying approaches. 179 Figure 1 illustrates this scenario. R2 in this picture does not 180 participate in RSVP, the other nodes do. In this case, R2 will pass 181 on any RSVP messages unchanged, and will ignore them. 183 ----R3--- 184 / \ 185 sender----R1---R2(*) R4----receiver 186 \ / 187 ----R5--- 188 (*) Non-RSVP hop 190 Figure 1: A non-RSVP Node in the path 192 This creates a challenge for RSVP authentication and encryption. In 193 the presence of a non-RSVP hop, with some RSVP messages such as a 194 PATH message, an RSVP router does not know the RSVP next hop for that 195 message at the time of forwarding it. For example, in Figure 1, R1 196 knows that the next IP hop for a Path message addressed to the 197 receiver is R2, but it does necessarily not know if the RSVP next hop 198 is R3 or R5. This means that per interface and per neighbor keys 199 cannot easily be used in the presence of non-RSVP routers on the path 200 between senders and receivers. 202 Section 4.3 of [RFC2747] states that "... the receiver MAY initiate 203 an integrity handshake with the sender." If this handshake is taking 204 place, it can be used to determine the identity of the next RSVP hop. 205 In this case, non-RSVP hops can be traversed also using per interface 206 or per neighbor keys. 208 Group keying will naturally work in the presence of non-RSVP routers. 209 Referring back to Figure 1, with group keying, R1 would use the group 210 key to protect a Path message addressed to the receiver and forwards 211 it to R2. Being a non-RSVP node, R2 will ignore and forward the Path 212 message to R3 or R5 depending on the current shortest path as 213 determined by routing. Whether it is R3 or R5, the RSVP router that 214 receives the Path message will be able to authenticate the message 215 successfully using the group key. 217 3. Applicability of Key Types for RSVP 219 3.1. Per interface and per neighbor keys 221 Most current RSVP authentication implementations support per 222 interface RSVP keys. When the interface is point-to-point (and 223 therefore an RSVP router has only a single RSVP neighbor on each 224 interface), this is equivalent to per neighbor keys in the sense that 225 a different key is used for each neighbor. In the point-to-point 226 case, the security domain is simply between the router and its 227 neighbor. However, when the interface is multipoint, all RSVP 228 speakers on a given subnet have to belong to the same security domain 229 and share the same key in this model. This makes it unsuitable for 230 deployment scenarios where nodes from different security domains are 231 present on a subnet, for example Internet exchange points. In such 232 cases, per neighbor keys are required and the security domain is 233 between the router and its neighbor. 235 With per neighbor keys, each RSVP key is bound to an interface plus a 236 neighbor on that interface. It allows for the existence of different 237 security domains on a single interface and subnet. 239 Per interface and per neighbor keys can be used within a single 240 security domain. 242 These key types can also be used between security domains, since they 243 are specific to a particular interface or neighbor. 245 Both monotonically increasing sequence number (e.g., the INTEGRITY 246 object simple sequence numbers [RFC2747], or the ESP and AH anti- 247 replay service [RFC4301] sequence numbers) and time based anti-replay 248 methods (e.g., the INTEGRITY sequence numbers based on a clock 249 [RFC2747]) can be used with per neighbor and per interface keys. 251 As discussed in the previous section, per neighbor and per interface 252 keys can not be used in the presence of non-RSVP hops. 254 3.2. Group keys 256 In the case of group keys, all members of a group of RSVP nodes share 257 the same key. This implies that a node uses the same key regardless 258 of the next RSVP hop that will process the message (within the group 259 of nodes sharing the particular key). It also implies that a node 260 will use the same key on the receiving as on the sending side (when 261 exchanging RSVP messages within the group). 263 Group keys apply naturally to intra-domain RSVP authentication, where 264 all RSVP nodes are part of the same security domain and implicitly 265 trust each other. The nodes also extended trust to a group key 266 server (GKS), which administers group membership and provides group 267 keys. This is represented in Figure 2. 269 ......GKS1............. 270 : : : : : 271 : : : : : 272 source--R1--R2--R3-----destination 273 | | 274 |<-----domain 1----------------->| 276 Figure 2: Group Key Server within a single security domain 278 A single group key cannot normally be used to cover multiple security 279 domains, because by definition the different domains do not trust 280 each other. They would therefore not be willing to trust the same 281 group key server. For a single group key to be used in several 282 security domains, there is a need for a single group key server, 283 which is trusted by both sides. While this is theoretically 284 possible, in practice it is unlikely that there is a single such 285 entity trusted by both domains. Figure 3 illustrates this setup. 287 ...............GKS1.................... 288 : : : : : : : : 289 : : : : : : : : 290 source--R1--R2--R3--------R4--R5--R6--destination 291 | | | | 292 |<-----domain 1--->| |<-------domain 2----->| 294 Figure 3: A Single Group Key Server across security domains 296 A more practical approach for RSVP operation across security domains, 297 is to use a separate group key server for each security domain, and 298 to use per interface or per neighbor keys between the two domains 299 (thus comprising a third security domain). Figure 4 shows this 300 setup. 302 ....GKS1...... ....GKS2......... 303 : : : : : : : : 304 : : : : : : : : 305 source--R1--R2--R3--------R4--R5--R6--destination 306 | | | | 307 |<-----domain 1--->| |<-------domain 2----->| 308 |<-->| 309 domain 3 311 Figure 4: A group Key Server per security domain 313 As discussed in Section 2, group keying can be used in the presence 314 of non-RSVP hops. 316 Because a group key may be used to verify messages from different 317 peers, monotonically increasing sequence number methods are not 318 appropriate. Time based anti-replay methods (e.g., the INTEGRITY 319 sequence numbers based on a clock [RFC2747]) can be used with group 320 keys. 322 4. Key Provisioning Methods for RSVP 324 4.1. Static Key Provisioning 326 Static keys are preconfigured, either manually, or through a network 327 management system. The simplest way to implement RSVP authentication 328 is to use static keys. Static keying can be used with per interface 329 keys, per neighbor keys or group keys. 331 The provisioning of static keys requires either manual operator 332 intervention on each node, or a network management system performing 333 the same task. Time synchronization of static key provisioning and 334 changes is critical, to avoid inconsistent keys within a security 335 domain. 337 Static key provisioning is therefore not an ideal model in a large 338 network. 340 Often, the number of interconnection points across two domains where 341 RSVP is allowed to transit is relatively small and well controlled. 342 Also, the different domains may not be in a position to use an 343 infrastructure trusted by both domains to update keys on both sides. 344 Thus, statically provisioned keys may be applicable to inter-domain 345 RSVP authentication. 347 Since it is not feasible to carry out a key change at the exact same 348 time in communicating RSVP nodes, some grace period needs to be 349 implemented during which an RSVP node will accept both the old and 350 the new key. Otherwise, RSVP operation would suffer interruptions. 351 (Also with dynamic keying approaches there can be a grace period 352 where two keys are valid at the same time; however, the grace period 353 in manual keying tends to be significantly longer than with dynamic 354 key rollover schemes.) 356 4.2. Dynamic Keying 358 4.2.1. Per Neighbor and Per Interface Key Negotiation 360 To avoid the problem of manual key provisioning and updates in static 361 key deployments, key negotiation between RSVP neighbors could be used 362 to derive either per interface or per neighbor keys. 364 4.2.2. Dynamic Group Key Distribution 366 With this approach, group keys are dynamically distributed among a 367 set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes 368 a mechanism to distribute group keys to a group of RSVP speakers, 369 using GDOI [I-D.ietf-msec-gdoi-update]. In this solution, each RSVP 370 node requests a group key from a key server as part of an encrypted 371 and integrity protected key agreement protocol. Once the key server 372 has authenticated and authorized the RSVP nodes it distributes a 373 group key to the group member. The authentication in this model can 374 be based on public key mechanisms, thereby avoiding the need for 375 static key provisioning. 377 5. Specific Cases Supporting Use of Group Keying 379 5.1. RSVP Notify Messages 381 [RFC3473] introduces the Notify message and allows such messages to 382 be sent in a non-hop-by-hop fashion. As discussed in the Security 383 Considerations section of [RFC3473], this can interfere with RSVP's 384 hop-by-hop integrity and authentication model. [RFC3473] describes 385 how standard IPsec based integrity and authentication can be used to 386 protect Notify messages. 388 Group keying may allow use of regular RSVP authentication ([RFC2747]) 389 for protection of non-hop-by-hop Notify messages. For example, RSVP 390 Notify messages commonly used for traffic engineering in MPLS 391 networks are non-hop-by-hop messages. Such messages may be sent from 392 an ingress node directly to an egress node. Group keying in such a 393 case avoids the establishment of node-to-node keying when node-to- 394 node keying is not otherwise used. 396 5.2. RSVP-TE and GMPLS 398 Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast 399 Reroute [RFC4090] deserves additional considerations. 401 With the facility backup method of Fast Reroute, a backup tunnel from 402 the Point of Local Repair (PLR) to the Merge Point (MP) is used to 403 protect Label Switched Paths (protected LSPs) against the failure of 404 a facility (e.g., a router) located between the PLR and the MP. 405 During the failure of the facility, the PLR redirects a protected LSP 406 inside the backup tunnel and as a result, the PLR and MP then need to 407 exchange RSVP control messages between each other (e.g., for the 408 maintenance of the protected LSP). Some of the RSVP messages between 409 the PLR and MP are sent over the backup tunnel (e.g., a Path message 410 from PLR to MP) while some are directly addressed to the RSVP node 411 (e.g., a Resv message from MP to PLR). During the rerouted period, 412 the PLR and the MP effectively become RSVP neighbors, while they may 413 not be directly connected to each other and thus do not behave as 414 RSVP neighbors in the absence of failure. This point is raised in 415 the Security Considerations section of [RFC4090] that says: "Note 416 that the facility backup method requires that a PLR and its selected 417 merge point trust RSVP messages received from each other." Such 418 environments may benefit from group keying. A group key can be used 419 among a set of routers enabled for Fast Reroute thereby easily 420 ensuring that PLR and MP authenticate messages from each other can be 421 authenticated, without requiring prior specific configuration of 422 keys, or activation of key update mechanism, for every possible pair 423 of PLR and MP. 425 Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS 426 boundaries (see [RFC4216]), the considerations presented above in 427 section 3.1 and 3.2 apply, such that per interface or per neighbor 428 keys can be used between two RSVP neighbors in different ASes 429 (independently of the keying method used by the RSVP router to talk 430 to the RSVP routers in the same AS). 432 [RFC4875] specifies protocol extensions for support of Point-to- 433 Multipoint (P2MP) RSVP-TE. RSVP message integrity mechanisms for 434 hop-by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE 435 signaling (see [RFC4875] Security Considerations) . 437 [RFC4206] defines LSP Hierarchy with GMPLS TE and uses non-hop-by-hop 438 signaling. Because it reuses LSP Hierarchy procedures for some of 439 its operations, P2MP RSVP-TE also uses non-hop-by-hop signaling. 440 Both LSP hierarchy and P2MP RSVP-TE rely on the security mechanisms 441 defined in [RFC3473] and [RFC4206] for non hop-by-hop RSVP-TE 442 signaling. Group keying can simplify protection of non-hop-by-hop 443 signaling for LSP Hierarchy and P2MP RSVP-TE. 445 6. Applicability of IPsec for RSVP 447 6.1. General Considerations Using IPsec 449 The discussions about the various keying methods in this document are 450 also applicable when using IPsec [RFC4301] to protect RSVP. 451 [RFC2747] states in section 1.2 that IPsec is not an optimal choice 452 to protect RSVP. The key argument is that an IPsec SA and an RSVP SA 453 are not based on the same parameters. Nevertheless, IPsec can be 454 used to protect RSVP. The Security Policy Database (SPD) traffic 455 selectors for related RSVP flows will not be constant. In some 456 cases, the source and destination addresses are end hosts, and 457 sometimes they are RSVP routers. Therefore, traffic selectors in the 458 SPD are expected to specify ANY for the source address and 459 destination addresses, and specify IP protocol 46 (RSVP). 461 The document "The Multicast Group Security Architecture" [RFC3740] 462 defines in detail a "Group Security Association" (GSA). This 463 definition is also applicable in the context discussed here, and 464 allows the use of IPsec for RSVP. The existing GDOI standard 465 [I-D.ietf-msec-gdoi-update] manages group security associations, 466 which can be used by IPsec. An example GDOI policy would be to 467 encrypt or authenticate all packets of the RSVP protocol itself (IP 468 protocol 46). A router implementing GDOI and the AH and/or ESP 469 protocols is therefore able to implement this policy. 471 Because the traffic selectors for an SA cannot be predicted, SA 472 lookup is expected to use only the Security Parameters Index (SPI) 473 (or SPI plus protocol). 475 6.2. Comparing AH and the INTEGRITY Object 477 The INTEGRITY object defined by [RFC2747] provides integrity 478 protection for RSVP also in a group keying context, as discussed 479 above. AH [RFC4302] is an alternative method to provide integrity 480 protection for RSVP packets. 482 The RSVP INTEGRITY object protects the entire RSVP message, but does 483 not protect the IP header of the packet nor the IP options (in IPv4) 484 or extension headers (in IPv6). 486 AH tunnel mode (transport mode is not applicable, see section 6.4) 487 protects the entire original IP packet, including the IP header of 488 the original IP packet ("inner header"), IP options or extension 489 headers, plus the entire RSVP packet. It also protects the immutable 490 fields of the outer header. 492 The difference between the two schemes in terms of covered fields is 493 therefore whether the IP header and IP options or extension headers 494 of the original IP packet are protected (as is the case with AH) or 495 not (as is the case with the INTEGRITY object). Also, AH covers the 496 immutable fields of the outer header. 498 As described in the next section, IPsec tunnel mode can not be 499 applied for RSVP traffic in the presence of non-RSVP nodes; therefore 500 the security associations in both cases, AH and INTEGRITY object, are 501 between the same RSVP neighbors. From a keying point of view both 502 approaches are therefore comparable. 504 6.3. Applicability of Tunnel Mode 506 IPsec tunnel mode encapsulates the original packet, prepending a new 507 IP header plus an ESP or AH sub-header. The entire original packet 508 plus the ESP/AH sub-header is secured. In the case of ESP the new, 509 outer IP header however is not cryptographically secured in this 510 process. 512 Protecting RSVP packets with IPsec tunnel mode works with any of the 513 above described keying methods (interface, neighbor or group based), 514 as long as there are no non-RSVP nodes on the path (however, see 515 group keying considerations below). For RSVP messages to be visible 516 and considered at each hop, such a tunnel would not cross routers, 517 but each RSVP node would establish a tunnel with each of its peers, 518 effectively leading to link protection. 520 In the presence of a non-RSVP hop, tunnel mode cannot be applied, 521 because a router upstream from a non-RSVP hop does not know the next 522 RSVP hop, and can thus not apply the correct tunnel header. The same 523 situation applies to a host attached to the network by a non-RSVP 524 enabled first hop. This is independent of the key type used. 526 The use of group keying with ESP tunnel mode where a security gateway 527 places a peer security gateway address as the destination of the ESP 528 packet has consequences. In particular, if a man-in-the-middle 529 attacker re-directs the ESP-protected reservation to a different 530 security gateway, the receiving security gateway cannot detect that 531 the destination address was changed. However, it has received and 532 will act upon or route a RSVP reservation that will be routed along 533 an unintended path. Because RSVP routers encountering the RSVP 534 packet path will not be aware that this is an unintended path, they 535 will act upon it and the resulting RSVP state along both the intended 536 path and unintended path will both be incorrect. Therefore group 537 keying is recommended not be used with ESP tunnel mode except with 538 address preservation (see Section 6.5). 540 6.4. Non-Applicability of Transport Mode 542 IPsec transport mode, as defined in [RFC4303] is not suitable for 543 securing RSVP Path messages, since those messages preserve the 544 original source and destination. [RFC4303] states explicitly that 545 "the use of transport mode by an intermediate system (e.g., a 546 security gateway) is permitted only when applied to packets whose 547 source address (for outbound packets) or destination address (for 548 inbound packets) is an address belonging to the intermediate system 549 itself." This would not be the case for RSVP Path messages. 551 6.5. Applicability of Tunnel Mode with Address Preservation 553 When the identity of the next-hop RSVP peer is not known, it is not 554 possible to use a tunnel-endpoint destination address in the Tunnel 555 Mode outer IP header. The document "Multicast Extensions to the 556 Security Architecture for the Internet Protocol" [RFC5374] defines in 557 section 3.1 a new tunnel mode: Tunnel mode with address preservation. 558 This mode copies the destination and optionally the source address 559 from the inner header to the outer header. Therefore the 560 encapsulated packet will have the same destination address as the 561 original packet, and be normally subject to the same routing 562 decisions. While [RFC5374] is focusing on multicast environments, 563 tunnel mode with address preservation can be used also to protect 564 unicast traffic in conjunction with group keying. In this tunnel 565 mode the RSVP speakers act as security gateways, because they 566 maintain the original end system addresses of the RSVP packets in the 567 outer tunnel mode IP header. This addressing scheme is used by RSVP 568 to ensure that the packets continue along the routed path toward the 569 destination end host. 571 Tunnel mode with address preservation, in conjunction with group 572 keying, allows the use of AH or ESP for protection of RSVP even in 573 cases where non-RSVP nodes have to be traversed. This is because it 574 allows routing of the IPsec protected packet through the non-RSVP 575 nodes in the same way as if it was not IPsec protected. 577 When used with group keying, tunnel mode with address preservation 578 can be used to mitigate re-direction attacks where a man-in-the- 579 middle modifies the destination of the outer IP header of the tunnel 580 mode packet. The inbound processing rules for tunnel mode with 581 address preservation (Section 5.2 of [RFC5374]) require that the 582 receiver verify that the addresses in the outer IP header and the 583 inner IP header are consistent. Therefore, the attack can be 584 detected and RSVP reservations will not proceed along an unintended 585 path. 587 7. End Host Considerations 589 Unless RSVP Proxy entities ([RFC5945] are used, RSVP signaling is 590 controlled by end systems and not routers. As discussed in 591 [RFC4230], RSVP allows both user-based security and host-based 592 security. User-based authentication aims at "providing policy based 593 admission control mechanism based on user identities or application." 594 To identify the user or the application, a policy element called 595 AUTH_DATA, which is contained in the POLICY_DATA object, is created 596 by the RSVP daemon at the user's host and transmitted inside the RSVP 597 message. This way, a user may authenticate to the Policy Decision 598 Point (or directly to the first hop router). Host-based security 599 relies on the same mechanisms as between routers (i.e., the INTEGRITY 600 object) as specified in [RFC2747]. For host-based security, per 601 interface or per neighbor keys may be used, however, key management 602 with statically provisioned keys can be difficult in a large scale 603 deployment, as described in section 4. In principle an end host can 604 also be part of a group key scheme, such as GDOI. If the end systems 605 are part of the same security domain as the RSVP hops in the network, 606 group keying can be extended to include the end systems. If the end 607 systems and the network are in different zones of trust, group keying 608 cannot be used. 610 8. Applicability to Other Architectures and Protocols 612 While, so far, this document discusses only RSVP security assuming 613 the traditional RSVP model as defined by [RFC2205] and [RFC2747], the 614 analysis is also applicable to other RSVP deployment models as well 615 as to similar protocols: 617 o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This 618 scheme defines aggregation of individual RSVP reservations, and 619 discusses use of RSVP authentication for the signaling messages. 620 Group keying is applicable to this scheme, particularly when 621 automatic Deaggregator discovery is used, since in that case, the 622 Aggregator does not know ahead of time which Deaggregator will 623 intercept the initial end-to-end RSVP Path message. 624 o Generic Aggregate Resource ReSerVation Protocol (RSVP) 625 Reservations [RFC4860]: This document also discusses aggregation 626 of individual RSVP reservations. Here again, group keying applies 627 and is mentioned in the Security Considerations section. 628 o Aggregation of Resource ReSerVation Protocol (RSVP) Reservations 629 over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): This scheme also 630 defines a form of aggregation of RSVP reservation but this time 631 over MPLS TE Tunnels. Similarly, group keying may be used in such 632 an environment. 633 o Pre-Congestion Notification (PCN): [RFC5559] defines an 634 architecture for flow admission and termination based on 635 aggregated pre-congestion information. One deployment model for 636 this architecture is based on IntServ over DiffServ: the DiffServ 637 region is PCN-enabled, RSVP signalling is used end-to-end but the 638 PCN-domain is a single RSVP hop, i.e. only the PCN- boundary-nodes 639 process RSVP messages. In this scenario, RSVP authentication may 640 be required among PCN-boundary-nodes and the considerations about 641 keying approaches discussed earlier in this document apply. In 642 particular, group keying may facilitate operations since the 643 ingress PCN-boundary-node does not necessarily know ahead of time 644 which Egress PCN-boundary-node will intercept and process the 645 initial end-to-end Path message. From the viewpoint of securing 646 end-to-end RSVP in this scenario (from the end host to the ingress 647 edge PCN node, to the egress PCN node, to the other end host), 648 there are a lot of similarities in scenarios involving RSVP 649 Aggregation over aggregate RSVP reservations ([RFC3175], 650 [RFC4860]), RSVP Aggregation over MPLS-TE tunnels ([RFC4804]), and 651 RSVP (Aggregation) over PCN ingress-egress aggregates. 653 9. Summary 655 The following table summarizes the various approaches for RSVP 656 keying, and their applicability to various RSVP scenarios. In 657 particular, such keying can be used for RSVP authentication (e.g., 658 using the RSVP INTEGRITY object or AH) and/ or for RSVP encryption 659 (e.g., using ESP in tunnel mode). 661 +-------------------------------+-----------------+-----------------+ 662 | | per | Group keys | 663 | | neighbor/per | | 664 | | interface keys | | 665 +-------------------------------+-----------------+-----------------+ 666 | Works intra-domain | Yes | Yes | 667 | Works inter-domain | Yes | No | 668 | Works over non-RSVP hops | No | Yes (1) | 669 | Dynamic keying | Yes (IKE) | Yes (e.g., | 670 | | | GDOI) | 671 +-------------------------------+-----------------+-----------------+ 673 Table 1: Overview of keying approaches and their applicability 675 (1): RSVP integrity with group keys works over non-RSVP nodes; RSVP 676 encryption with ESP and RSVP authentication with AH work over non- 677 RSVP nodes in 'Tunnel Mode with Address Preservation'; RSVP 678 encryption with ESP & RSVP authentication with AH do not work over 679 non-RSVP nodes in 'Tunnel Mode'. 681 We also make the following observations: 683 o All key types can be used statically, or with dynamic key 684 negotiation. This impacts the manageability of the solution, but 685 not the applicability itself. 686 o For encryption of RSVP messages, IPsec ESP in tunnel mode can be 687 used. 688 o There are some special cases in RSVP, like non-RSVP hosts, the 689 "Notify" message (as discussed in Section 5.1), the various RSVP 690 deployment models discussed in Section 8 and MPLS Traffic 691 Engineering and GMPLS discussed in section 5.2 , which would 692 benefit from a group keying approach. 694 10. Security Considerations 696 This entire document discusses RSVP security; this section describes 697 a specific security considerations relating to subverted RSVP nodes. 699 10.1. Subverted Nodes 701 An undetected subverted node, for example one that an intruder has 702 gained control over, it is still implicitly a trusted node. However 703 it is a threat to the security of RSVP. Since RSVP authentication is 704 hop-by-hop and not end-to-end, a subverted node in the path breaks 705 the chain of trust. This is to a large extent independent of the 706 type of keying used. 708 For interface or per neighbor keying, the subverted node can now 709 introduce fake messages to its neighbors. This can be used in a 710 variety of ways, for example by changing the receiver address in the 711 Path message, or by generating fake Path messages. This allows path 712 states to be created on every RSVP router along any arbitrary path 713 through the RSVP domain. That in itself could result in a form of 714 Denial of Service by allowing exhaustion of some router resources 715 (e.g. memory). The subverted node could also generate fake Resv 716 messages upstream corresponding to valid Path states. In doing so, 717 the subverted node can reserve excessive amounts of bandwidth thereby 718 possibly performing a denial of service attack. 720 Group keying allows the additional abuse of sending fake RSVP 721 messages to any node in the RSVP domain, not just adjacent RSVP 722 nodes. However, in practice this can be achieved to a large extent 723 also with per neighbor or interface keys, as discussed above. 724 Therefore the impact of subverted nodes on the path is comparable for 725 all keying schemes discussed here (per interface, per neighbor, group 726 keys). 728 11. Acknowledgements 730 The authors would like to thank everybody who provided feedback on 731 this document. Specific thanks to Bob Briscoe, Hannes Tschofenig, 732 Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg. 734 12. IANA Considerations 736 There are no IANA considerations within this document. This section 737 can be removed if this document is published as an RFC. 739 13. Informative References 741 [I-D.ietf-msec-gdoi-update] 742 Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 743 of Interpretation", draft-ietf-msec-gdoi-update-11 (work 744 in progress), August 2011. 746 [I-D.weis-gdoi-mac-tek] 747 Weis, B. and S. Rowles, "GDOI Generic Message 748 Authentication Code Policy", draft-weis-gdoi-mac-tek-02 749 (work in progress), March 2011. 751 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 752 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 753 Functional Specification", RFC 2205, September 1997. 755 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 756 Authentication", RFC 2747, January 2000. 758 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 759 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 760 RFC 3175, September 2001. 762 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 763 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 764 Tunnels", RFC 3209, December 2001. 766 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 767 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 768 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 770 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 771 Architecture", RFC 3740, March 2004. 773 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 774 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 775 May 2005. 777 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 778 Hierarchy with Generalized Multi-Protocol Label Switching 779 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 781 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 782 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 783 November 2005. 785 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 786 Properties", RFC 4230, December 2005. 788 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 789 Internet Protocol", RFC 4301, December 2005. 791 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 792 December 2005. 794 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 795 RFC 4303, December 2005. 797 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 798 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 799 RFC 4804, February 2007. 801 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 802 Davenport, "Generic Aggregate Resource ReSerVation 803 Protocol (RSVP) Reservations", RFC 4860, May 2007. 805 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 806 "Extensions to Resource Reservation Protocol - Traffic 807 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 808 Switched Paths (LSPs)", RFC 4875, May 2007. 810 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 811 Extensions to the Security Architecture for the Internet 812 Protocol", RFC 5374, November 2008. 814 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 815 Architecture", RFC 5559, June 2009. 817 [RFC5945] Le Faucheur, F., Manner, J., Wing, D., and A. Guillou, 818 "Resource Reservation Protocol (RSVP) Proxy Approaches", 819 RFC 5945, October 2010. 821 Authors' Addresses 823 Michael H. Behringer 824 Cisco Systems 825 Village d'Entreprises Green Side 826 400, Avenue Roumanille, Batiment T 3 827 Biot - Sophia Antipolis 06410 828 France 830 Email: mbehring@cisco.com 831 URI: http://www.cisco.com 833 Francois Le Faucheur 834 Cisco Systems 835 Village d'Entreprises Green Side 836 400, Avenue Roumanille, Batiment T 3 837 Biot - Sophia Antipolis 06410 838 France 840 Email: flefauch@cisco.com 841 URI: http://www.cisco.com 843 Brian Weis 844 Cisco Systems 845 170 W. Tasman Drive 846 San Jose, California 95134-1706 847 USA 849 Email: bew@cisco.com 850 URI: http://www.cisco.com