idnits 2.17.1 draft-ietf-tsvwg-rsvp-security-groupkeying-08.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 191: '... receiver MAY initiate an integrity ...' 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 (October 22, 2010) is 4934 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2409' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'RFC4306' is defined on line 796, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-weis-gdoi-mac-tek-01 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 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: April 25, 2011 Cisco Systems 6 October 22, 2010 8 Applicability of Keying Methods for RSVP Security 9 draft-ietf-tsvwg-rsvp-security-groupkeying-08.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 April 25, 2011. 39 Copyright Notice 41 Copyright (c) 2010 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 2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 3 58 3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5 59 3.1. Per interface and per neighbor keys . . . . . . . . . . . 5 60 3.2. Group keys . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 8 62 4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 8 63 4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8 64 4.2.1. Per Neighbor and Per Interface Key Negotiation . . . . 8 65 4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 9 66 5. Specific Cases Supporting Use of Group Keying . . . . . . . . 9 67 5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 9 68 5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 9 69 6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10 70 6.1. General Considerations Using IPsec . . . . . . . . . . . . 10 71 6.2. Comparing AH and the INTEGRITY Object . . . . . . . . . . 11 72 6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 12 73 6.4. Non-Applicability of Transport Mode . . . . . . . . . . . 12 74 6.5. Applicability of Tunnel Mode with Address Preservation . . 13 75 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 13 76 8. Applicability to Other Architectures and Protocols . . . . . . 14 77 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 16 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 81 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 13. Informative References . . . . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction and Problem Statement 87 The Resource reSerVation Protocol [RFC2205] allows hop-by-hop 88 authentication of RSVP neighbors, as specified in [RFC2747]. In this 89 mode, an integrity object is attached to each RSVP message to 90 transmit a keyed message digest. This message digest allows the 91 recipient to verify the identity of the RSVP node that sent the 92 message, and to validate the integrity of the message. Through the 93 inclusion of a sequence number in the scope of the digest, the digest 94 also offers replay protection. 96 [RFC2747] does not dictate how the key for the integrity operation is 97 derived. Currently, most implementations of RSVP use a statically 98 configured key, per interface or per neighbor. However, to manually 99 configure a key per router pair across an entire network is 100 operationally hard, especially when key changes are to be performed 101 on a regular basis. Effectively, many users of RSVP therefore resort 102 to using the same key throughout their RSVP network, and they change 103 it rarely if ever, because of the operational burden. It is however 104 often necessary to regularly change keys due to network operational 105 requirements. 107 This document discusses a variety of keying methods and their 108 applicability to different RSVP deployment environments, for both 109 message integrity and encryption. It is meant as a comparative guide 110 to understand where each RSVP keying method is best deployed, and the 111 limitations of each method. Furthermore, it discusses how RSVP hop 112 by hop authentication is impacted in the presence of non-RSVP nodes, 113 or subverted nodes, in the reservation path. 115 The document "RSVP Security Properties" ([RFC4230]) provides an 116 overview of RSVP security, including RSVP Cryptographic 117 Authentication [RFC2747], but does not discuss key management. It 118 states that "RFC 2205 assumes that security associations are already 119 available". The present document focuses specifically on key 120 management with different key types, including group keys. Therefore 121 this document complements [RFC4230]. 123 2. The RSVP Hop-by-Hop Trust Model 125 Many protocol security mechanisms used in networks require and use 126 per peer authentication. Each hop authenticates its neighbor with a 127 shared key or certificate. This is also the model used for RSVP. 128 Trust in this model is transitive. Each RSVP node trusts explicitly 129 only its RSVP next hop peers, through the message digest contained in 130 the INTEGRITY object. The next hop RSVP speaker in turn trusts its 131 own peers and so on. See also the document "RSVP security 132 properties" [RFC4230] for more background. 134 The keys used for protecting RSVP messages can, in particular, be 135 group keys (for example distributed via GDOI [RFC3547], as discussed 136 in [I-D.weis-gdoi-mac-tek]). If a group key is used, the 137 authentication granularity becomes group membership of devices, not 138 (individual) peer authentication between devices. 140 The trust an RSVP node has to another RSVP node has an explicit and 141 an implicit component. Explicitly the node trusts the other node to 142 maintain the RSVP messages intact or confidential, depending on 143 whether authentication or encryption (or both) is used. This means 144 only that the message has not been altered or seen by another, non- 145 trusted node. Implicitly each node trusts each other node with which 146 it has a trust relationship established via the mechanisms here to 147 adhere to the protocol specifications laid out by the various 148 standards. Note that in any group keying scheme like GDOI a node 149 trusts all the other members of the group (because the authentication 150 is now based on group membership, as noted above). 152 The RSVP protocol can operate in the presence of a non-RSVP router in 153 the path from the sender to the receiver. The non-RSVP hop will 154 ignore the RSVP message and just pass it along. The next RSVP node 155 can then process the RSVP message. For RSVP authentication or 156 encryption to work in this case, the key used for computing the RSVP 157 message digest needs to be shared by the two RSVP neighbors, even if 158 they are not IP neighbors. However, in the presence of non-RSVP 159 hops, while an RSVP node always knows the next IP hop before 160 forwarding an RSVP Message, it does not always know the RSVP next 161 hop. In fact, part of the role of a Path message is precisely to 162 discover the RSVP next hop (and to dynamically re-discover it when it 163 changes, for example because of a routing change). Thus, the 164 presence of non-RSVP hops impacts operation of RSVP authentication or 165 encryption and may influence the selection of keying approaches. 167 Figure 1 illustrates this scenario. R2 in this picture does not 168 participate in RSVP, the other nodes do. In this case, R2 will pass 169 on any RSVP messages unchanged, and will ignore them. 171 ----R3--- 172 / \ 173 sender----R1---R2(*) R4----receiver 174 \ / 175 ----R5--- 176 (*) Non-RSVP hop 178 Figure 1: A non-RSVP Node in the path 180 This creates a challenge for RSVP authentication and encryption. In 181 the presence of a non-RSVP hop, with some RSVP messages such as a 182 PATH message, an RSVP router does not know the RSVP next hop for that 183 message at the time of forwarding it. For example, in Figure 1, R1 184 knows that the next IP hop for a Path message addressed to the 185 receiver is R2, but it does necessarily not know if the RSVP next hop 186 is R3 or R5. 188 This means that per interface and per neighbor keys cannot easily be 189 used in the presence of non-RSVP routers on the path between senders 190 and receivers. Section 4.3 of [RFC2747] states that "... the 191 receiver MAY initiate an integrity handshake with the sender." We 192 note that if this handshake is taking place, it can be used to 193 determine the identity of the next RSVP hop. In this case, non-RSVP 194 hops can be traversed also using per interface or per neighbor keys. 196 Group keying will naturally work in the presence of non-RSVP routers. 197 Referring back to Figure 1, with group keying, R1 would use the group 198 key to protect a Path message addressed to the receiver and forwards 199 it to R2. Being a non-RSVP node, R2 will ignore and forward the Path 200 message to R3 or R5 depending on the current shortest path as 201 determined by routing. Whether it is R3 or R5, the RSVP router that 202 receives the Path message will be able to authenticate it 203 successfully using the group key. 205 3. Applicability of Key Types for RSVP 207 3.1. Per interface and per neighbor keys 209 Most current RSVP authentication implementations support per 210 interface RSVP keys. When the interface is point-to-point (and 211 therefore an RSVP router has only a single RSVP neighbor on each 212 interface), this is equivalent to per neighbor keys in the sense that 213 a different key is used for each neighbor. However, when the 214 interface is multipoint, all RSVP speakers on a given subnet have to 215 share the same key in this model. This makes it unsuitable for 216 deployment scenarios where nodes from different security domains are 217 present on a subnet, for example Internet exchange points. A 218 security domain is defined here as a set of nodes that shares a 219 common RSVP security policy. In such cases, per neighbor keys are 220 required. 222 With per neighbor keys, each RSVP key is bound to an interface plus a 223 neighbor on that interface. It allows for the existence of different 224 security domains on a single interface and subnet. 226 per interface and per neighbor keys can be used within a single 227 security domain. As mentioned above, per interface keys are only 228 applicable when all the nodes reachable on the specific interface 229 belong to the same security domain. 231 These key types can also be used between security domains, since they 232 are specific to a particular interface or neighbor. Again, interface 233 level keys can be deployed safely only when all the reachable 234 neighbors on the interface belong to the same security domain. 236 Both monotonically increasing sequence number (e.g., the INTEGRITY 237 object simple sequence numbers [RFC2747], or the ESP and AH anti- 238 replay service [RFC4301] sequence numbers) and time based anti-replay 239 methods (e.g., the INTEGRITY sequence numbers based on a clock 240 [RFC2747]) can be used with per neighbor and per interface keys. 242 As discussed in the previous section, per neighbor and per interface 243 keys can not be used in the presence of non-RSVP hops. 245 3.2. Group keys 247 In the case of group keys, all members of a group of RSVP nodes share 248 the same key. This implies that a node uses the same key regardless 249 of the next RSVP hop that will process the message (within the group 250 of nodes sharing the particular key). It also implies that a node 251 will use the same key on the receiving as on the sending side (when 252 exchanging RSVP messages within the group). 254 Group keys apply naturally to intra-domain RSVP authentication, where 255 all RSVP nodes are part of the same security domain and implicitly 256 trust each other. Using group keys, they extend this trust to the 257 group key server. This is represented in Figure 2. 259 ......GKS1............. 260 : : : : : 261 : : : : : 262 source--R1--R2--R3-----destination 263 | | 264 |<-----domain 1----------------->| 266 Figure 2: Group Key Server within a single security domain 268 A single group key cannot normally be used to cover multiple security 269 domains, because by definition the different domains do not trust 270 each other. They would therefore not be willing to trust the same 271 group key server. For a single group key to be used in several 272 security domains, there is a need for a single group key server, 273 which is trusted by both sides. While this is theoretically 274 possible, in practice it is unlikely that there is a single such 275 entity trusted by both domains. Figure 3 illustrates this setup. 277 ...............GKS1.................... 278 : : : : : : : : 279 : : : : : : : : 280 source--R1--R2--R3--------R4--R5--R6--destination 281 | | | | 282 |<-----domain 1--->| |<-------domain 2----->| 284 Figure 3: A Single Group Key Server across security domains 286 A more practical approach for RSVP operation across security domains, 287 is to use a separate group key server for each security domain, and 288 to use per interface or per neighbor keys between the two domains. 289 Figure 4 shows this setup. 291 ....GKS1...... ....GKS2......... 292 : : : : : : : : 293 : : : : : : : : 294 source--R1--R2--R3--------R4--R5--R6--destination 295 | | | | 296 |<-----domain 1--->| |<-------domain 2----->| 298 Figure 4: A group Key Server per security domain 300 As discussed in Section 2, group keying can be used in the presence 301 of non-RSVP hops. 303 Because a group key may be used to verify messages from different 304 peers, monotonically increasing sequence number methods are not 305 appropriate. Time based anti-replay methods (e.g., the INTEGITY 306 sequence numbers based on a clock [RFC2747]) can be used with group 307 keys. 309 4. Key Provisioning Methods for RSVP 311 4.1. Static Key Provisioning 313 Static keys are preconfigured, either manually, or through a network 314 management system. The simplest way to implement RSVP authentication 315 is to use static keys. Static keying can be used with per interface 316 keys, per neighbor keys or group keys. 318 The provisioning of static keys requires either manual operator 319 intervention on each node, or a network management system performing 320 the same task. Time synchronization of static key provisioning and 321 changes is critical, to avoid inconsistent keys within a security 322 domain. 324 Static key provisioning is therefore not an ideal model in a large 325 network. 327 Often, the number of interconnection points across two domains where 328 RSVP is allowed to transit is relatively small and well controlled. 329 Also, the different domains may not be in a position to use an 330 infrastructure trusted by both domains to update keys on both sides. 331 Thus, statically provisioned keys may be applicable to inter-domain 332 RSVP authentication. 334 Since it is not feasible to carry out a key change at the exact same 335 time in communicating RSVP nodes, some grace period needs to be 336 implemented during which an RSVP node will accept both the old and 337 the new key. Otherwise, RSVP operation would suffer interruptions. 338 (Note that also with dynamic keying approaches there can be a grace 339 period where two keys are valid at the same time; however, the grace 340 period in manual keying tends to be significantly longer than with 341 dynamic key rollover schemes.) 343 4.2. Dynamic Keying 345 4.2.1. Per Neighbor and Per Interface Key Negotiation 347 To avoid the problem of manual key provisioning and updates in static 348 key deployments, key negotiation between RSVP neighbors could be used 349 to derive either per interface or per neighbor keys. 351 4.2.2. Dynamic Group Key Distribution 353 With this approach, group keys are dynamically distributed among a 354 set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes 355 a mechanism to distribute group keys to a group of RSVP speakers, 356 using GDOI [RFC3547]. In this solution, a key server authenticates 357 each of the RSVP nodes independently, and then distributes a group 358 key to the group as part of an encrypted and integrity protected key 359 agreement protocol. The authentication in this model can be based on 360 public key mechanisms, thereby avoiding the need for static key 361 provisioning. 363 5. Specific Cases Supporting Use of Group Keying 365 5.1. RSVP Notify Messages 367 [RFC3473] introduces the Notify message and allows such messages to 368 be sent in a non-hop-by-hop fashion. As discussed in the Security 369 Considerations section of [RFC3473], this can interfere with RSVP's 370 hop-by-hop integrity and authentication model. [RFC3473] describes 371 how standard IPsec based integrity and authentication can be used to 372 protect Notify messages. We observe that, alternatively, in some 373 environments, group keying may allow use of regular RSVP 374 authentication ([RFC2747]) for protection of non-hop-by-hop Notify 375 messages. 377 For example, RSVP Notify messages commonly used for traffic 378 engineering in MPLS networks are non-hop-by-hop messages. Such 379 messages may be sent from an ingress node directly to an egress node. 380 Group keying in such a case avoids the establishment of node-to-node 381 keying when node-to-node keying is not otherwise used. 383 5.2. RSVP-TE and GMPLS 385 Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast 386 Reroute [RFC4090] deserves additional considerations. 388 With the facility backup method of Fast Reroute, a backup tunnel from 389 the Point of Local Repair (PLR) to the Merge Point (MP) is used to 390 protect Label Switched Paths (protected LSPs) against the failure of 391 a facility (e.g., a router) located between the PLR and the MP. 392 During the failure of the facility, the PLR redirects a protected LSP 393 inside the backup tunnel and as a result, the PLR and MP then need to 394 exchange RSVP control messages between each other (e.g., for the 395 maintenance of the protected LSP). Some of the RSVP messages between 396 the PLR and MP are sent over the backup tunnel (e.g., a Path message 397 from PLR to MP) while some are directly addressed to the RSVP node 398 (e.g., a Resv message from MP to PLR). During the rerouted period, 399 the PLR and the MP effectively become RSVP neighbors, while they may 400 not be directly connected to each other and thus do not behave as 401 RSVP neighbors in the absence of failure. This point is raised in 402 the Security Considerations section of [RFC4090] that says: "Note 403 that the facility backup method requires that a PLR and its selected 404 merge point trust RSVP messages received from each other." We 405 observe that such environments may benefit from group keying. A 406 group key can be used among a set of routers enabled for Fast Reroute 407 thereby easily ensuring that PLR and MP authenticate messages from 408 each other can be authenticated, without requiring prior specific 409 configuration of keys, or activation of key update mechanism, for 410 every possible pair of PLR and MP. 412 Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS 413 boundaries (see [RFC4216]), the considerations presented above in 414 section 3.1 and 3.2 apply, such that per interface or per neighbor 415 keys can be used between two RSVP neighbors in different ASes 416 (independently of the keying method used by the RSVP router to talk 417 to the RSVP routers in the same AS). 419 [RFC4875] specifies protocol extensions for support of Point-to- 420 Multipoint (P2MP) RSVP-TE. In its Security Considerations section, 421 [RFC4875] points out that RSVP message integrity mechanisms for hop- 422 by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling. 423 In turn, we observe that the analyses in this document of keying 424 methods apply equally to P2MP RSVP-TE for the hop-by-hop signaling. 426 [RFC4206] defines LSP Hierarchy with GMPLS TE and uses non-hop-by-hop 427 signaling. Because it reuses LSP Hierarchy procedures for some of 428 its operations, P2MP RSVP-TE also uses non-hop-by-hop signaling. 429 Both LSP hierarchy and P2MP RSVP-TE rely on the security mechanisms 430 defined in [RFC3473] and [RFC4206] for non hop-by-hop RSVP-TE 431 signaling. We note that the observation in Section 3.1 of this 432 document about use of group keying for protection of non-hop-by-hop 433 messages apply to protection of non-hop-by-hop signaling for LSP 434 Hierarchy and P2MP RSVP- TE. 436 6. Applicability of IPsec for RSVP 438 6.1. General Considerations Using IPsec 440 The discussions about the various keying methods in this document are 441 also applicable when using IPsec [RFC4301] to protect RSVP. Note 442 that [RFC2747] states in section 1.2 that IPsec is not an optimal 443 choice to protect RSVP. The key argument is that an IPsec SA and an 444 RSVP SA are not based on the same parameters. Nevertheless, IPsec 445 can be used to protect RSVP. Note that the SPD traffic selectors for 446 related RSVP flows will not be constant. In some cases, the source 447 and destination addresses are end hosts, and sometimes they are RSVP 448 routers. Therefore, traffic selectors in the SPD should specify ANY 449 for the source address and destination addresses, and specify IP 450 protocol 46 (RSVP). 452 The document "The Multicast Group Security Architecture" [RFC3740] 453 defines in detail a "Group Security Association" (GSA). This 454 definition is also applicable in the context discussed here, and 455 allows the use of IPsec for RSVP. The existing GDOI standard 456 [RFC3547] manages group security associations, which can be used by 457 IPsec. An example GDOI policy would be to encrypt or authenticate 458 all packets of the RSVP protocol itself (IP protocol 46). A router 459 implementing GDOI and the AH and/or ESP protocols is therefore able 460 to implement this policy. 462 Because the traffic selectors for an SA cannot be predicted, SA 463 lookup should use only the SPI (or SPI plus protocol). 465 6.2. Comparing AH and the INTEGRITY Object 467 The INTEGRITY object defined by [RFC2747] provides integrity 468 protection for RSVP also in a group keying context, as discussed 469 above. AH [RFC4302] is an alternative method to provide integrity 470 protection for RSVP packets. 472 The RSVP INTEGRITY object protects the entire RSVP message, but does 473 not protect the IP header of the packet nor the IP options (in IPv4) 474 or extension headers (in IPv6). 476 AH tunnel mode (transport mode is not applicable, see section 6.4) 477 protects the entire original IP packet, including the IP header of 478 the original IP packet ("inner header"), IP options or extension 479 headers, plus the entire RSVP packet. It also protects the immutable 480 fields of the outer header. 482 The difference between the two schemes in terms of covered fields is 483 therefore whether the IP header and IP options or extension headers 484 of the original IP packet are protected (as is the case with AH) or 485 not (as is the case with the INTEGRITY object). Also, AH covers the 486 immutable fields of the outer header. 488 As described in the next section, IPsec tunnel mode can not be 489 applied for RSVP traffic in the presence of non-RSVP nodes; therefore 490 the security associations in both cases, AH and INTEGRITY object, are 491 between the same RSVP neighbors. From a keying point of view both 492 approaches are therefore comparable. 494 6.3. Applicability of Tunnel Mode 496 IPsec tunnel mode encapsulates the original packet, prepending a new 497 IP header plus an ESP or AH sub-header. The entire original packet 498 plus the ESP/AH sub-header is secured. In the case of ESP the new, 499 outer IP header however is not cryptographically secured in this 500 process. 502 Protecting RSVP packets with IPsec tunnel mode works with any of the 503 above described keying methods (interface, neighbor or group based), 504 as long as there are no non-RSVP nodes on the path (however, see 505 group keying considerations below). Note that for RSVP messages to 506 be visible and considered at each hop, such a tunnel would not cross 507 routers, but each RSVP node would establish a tunnel with each of its 508 peers, effectively leading to link protection. 510 In the presence of a non-RSVP hop, tunnel mode cannot be applied, 511 because a router upstream from a non-RSVP hop does not know the next 512 RSVP hop, and can thus not apply the correct tunnel header. This is 513 independent of the key type used. 515 The use of group keying with ESP tunnel mode where a security gateway 516 places a peer security gateway address as the destination of the ESP 517 packet has consequences. In particular, if a man-in-the-middle 518 attacker re-directs the ESP-protected reservation to a different 519 security gateway, the receiving security gateway cannot detect that 520 the destination address was changed. However, it has received and 521 will act upon or route a RSVP reservation that will be be routed 522 along an unintended path. Because RSVP routers encountering the RSVP 523 packet path will not be aware that this is an unintended path, they 524 will act upon it and the resulting RSVP state along both the intended 525 path and unintended path will both be incorrect. Therefore group 526 keying should not be used with ESP tunnel mode except with address 527 preservation (see Section 6.5). 529 6.4. Non-Applicability of Transport Mode 531 IPsec transport mode, as defined in [RFC4303] is not suitable for 532 securing RSVP Path messages, since those messages preserve the 533 original source and destination. [RFC4303] states explicitly that 534 "the use of transport mode by an intermediate system (e.g., a 535 security gateway) is permitted only when applied to packets whose 536 source address (for outbound packets) or destination address (for 537 inbound packets) is an address belonging to the intermediate system 538 itself." This would not be the case for RSVP Path messages. 540 6.5. Applicability of Tunnel Mode with Address Preservation 542 When the identity of the next-hop RSVP peer is not known, it is not 543 possible to use a tunnel-endpoint destination address in the Tunnel 544 Mode outer IP header. The document "Multicast Extensions to the 545 Security Architecture for the Internet Protocol" [RFC5374] defines in 546 section 3.1 a new tunnel mode: Tunnel mode with address preservation. 547 This mode copies the destination and optionally the source address 548 from the inner header to the outer header. Therefore the 549 encapsulated packet will have the same destination address as the 550 original packet, and be normally subject to the same routing 551 decisions. While [RFC5374] is focusing on multicast environments, 552 tunnel mode with address preservation can be used also to protect 553 unicast traffic in conjunction with group keying. Note that in this 554 tunnel mode the RSVP speakers act as security gateways, because they 555 maintain the original end system addresses of the RSVP packets in the 556 outer tunnel mode IP header. This addressing scheme is used by RSVP 557 to ensure that the packets continue along the routed path toward the 558 destination end host. 560 Tunnel mode with address preservation, in conjunction with group 561 keying, allows the use of AH or ESP for protection of RSVP even in 562 cases where non-RSVP nodes have to be traversed. This is because it 563 allows routing of the IPsec protected packet through the non-RSVP 564 nodes in the same way as if it was not IPsec protected. 566 When used with group keying, tunnel mode with address preservation 567 can be used to mitigate re-direction attacks where a man-in-the- 568 middle modifies the destination of the outer IP header of the tunnel 569 mode packet. The inbound processing rules for tunnel mode with 570 address preservation (Section 5.2 of [RFC5374]) require that the 571 receiver verify that the addresses in the outer IP header and the 572 inner IP header are consistent. Therefore, the attack should be 573 detected and RSVP reservations will not proceed along an unintended 574 path. 576 7. End Host Considerations 578 Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches] 579 are used, RSVP signaling is controlled by end systems and not 580 routers. As discussed in [RFC4230], RSVP allows both user-based 581 security and host-based security. User-based authentication aims at 582 "providing policy based admission control mechanism based on user 583 identities or application." To identify the user or the application, 584 a policy element called AUTH_DATA, which is contained in the 585 POLICY_DATA object, is created by the RSVP daemon at the user's host 586 and transmitted inside the RSVP message. This way, a user may 587 authenticate to the Policy Decision Point (or directly to the first 588 hop router). Host-based security relies on the same mechanisms as 589 between routers (i.e., the INTEGRITY object) as specified in 590 [RFC2747]. For host-based security, per interface or per neighbor 591 keys may be used, however, key management with statically provisioned 592 keys can be difficult in a large scale deployment, as described in 593 section 4. In principle an end host can also be part of a group key 594 scheme, such as GDOI. If the end systems are part of the same 595 security domain as the network itself, group keying can be extended 596 to include the end systems. If the end systems and the network are 597 in different zones of trust, group keying cannot be used. 599 8. Applicability to Other Architectures and Protocols 601 While, so far, this document discusses only RSVP security assuming 602 the traditional RSVP model as defined by [RFC2205] and [RFC2747], the 603 analysis is also applicable to other RSVP deployment models as well 604 as to similar protocols: 606 o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This 607 scheme defines aggregation of individual RSVP reservations, and 608 discusses use of RSVP authentication for the signaling messages. 609 Group keying is applicable to this scheme, particularly when 610 automatic Deaggregator discovery is used, since in that case, the 611 Aggregator does not know ahead of time which Deaggregator will 612 intercept the initial end-to-end RSVP Path message. 613 o Generic Aggregate Resource ReSerVation Protocol (RSVP) 614 Reservations [RFC4860]: This document also discusses aggregation 615 of individual RSVP reservations. Here again, group keying applies 616 and is mentioned in the Security Considerations section. 617 o Aggregation of Resource ReSerVation Protocol (RSVP) Reservations 618 over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): This scheme also 619 defines a form of aggregation of RSVP reservation but this time 620 over MPLS TE Tunnels. Similarly, group keying may be used in such 621 an environment. 622 o Pre-Congestion Notification (PCN): [I-D.ietf-pcn-architecture] 623 defines an architecture for flow admission and termination based 624 on aggregated pre-congestion information. One deployment model 625 for this architecture is based on IntServ over DiffServ: the 626 DiffServ region is PCN-enabled, RSVP signalling is used end-to-end 627 but the PCN-domain is a single RSVP hop, i.e. only the PCN- 628 boundary-nodes process RSVP messages. In this scenario, RSVP 629 authentication may be required among PCN-boundary-nodes and the 630 considerations about keying approaches discussed earlier in this 631 document apply. In particular, group keying may facilitate 632 operations since the ingress PCN-boundary-node does not 633 necessarily know ahead of time which Egress PCN-boundary-node will 634 intercept and process the initial end-to-end Path message. Note 635 that from the viewpoint of securing end-to-end RSVP, there are a 636 lot of similarities in scenarios involving RSVP Aggregation over 637 aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP 638 Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP 639 (Aggregation) over PCN ingress-egress aggregates. 641 9. Summary 643 The following table summarizes the various approaches for RSVP 644 keying, and their applicability to various RSVP scenarios. In 645 particular, such keying can be used for RSVP authentication (e.g., 646 using the RSVP INTEGRITY object or AH) and/ or for RSVP encryption 647 (e.g., using ESP in tunnel mode). 649 +-------------------------------+-----------------+-----------------+ 650 | | per | Group keys | 651 | | neighbor/per | | 652 | | interface keys | | 653 +-------------------------------+-----------------+-----------------+ 654 | Works intra-domain | Yes | Yes | 655 | Works inter-domain | Yes | No | 656 | Works over non-RSVP hops | No | Yes (1) | 657 | Dynamic keying | Yes (IKE) | Yes (e.g., | 658 | | | GDOI) | 659 +-------------------------------+-----------------+-----------------+ 661 Table 1: Overview of keying approaches and their applicability 663 (1): RSVP integrity with group keys works over non-RSVP nodes; RSVP 664 encryption with ESP and RSVP authentication with AH work over non- 665 RSVP nodes in 'Tunnel Mode with Address Preservation'; RSVP 666 encryption with ESP & RSVP authentication with AH do not work over 667 non-RSVP nodes in 'Tunnel Mode'. 669 We also make the following observations: 671 o All key types can be used statically, or with dynamic key 672 negotiation. This impacts the manageability of the solution, but 673 not the applicability itself. 674 o For encryption of RSVP messages, IPsec ESP in tunnel mode can be 675 used. 676 o There are some special cases in RSVP, like non-RSVP hosts, the 677 "Notify" message (as discussed in Section 5.1), the various RSVP 678 deployment models discussed in Section 8 and MPLS Traffic 679 Engineering and GMPLS discussed in section 5.2 , which would 680 benefit from a group keying approach. 682 10. Security Considerations 684 This entire document discusses RSVP security; this section describes 685 a specific security considerations relating to subverted RSVP nodes. 687 10.1. Subverted Nodes 689 A subverted node is defined here as an untrusted node, for example 690 because an intruder has gained control over it. Since RSVP 691 authentication is hop-by-hop and not end-to-end, a subverted node in 692 the path breaks the chain of trust. This is to a large extent 693 independent of the type of keying used. 695 For interface or per neighbor keying, the subverted node can now 696 introduce fake messages to its neighbors. This can be used in a 697 variety of ways, for example by changing the receiver address in the 698 Path message, or by generating fake Path messages. This allows path 699 states to be created on every RSVP router along any arbitrary path 700 through the RSVP domain. That in itself could result in a form of 701 Denial of Service by allowing exhaustion of some router resources 702 (e.g. memory). The subverted node could also generate fake Resv 703 messages upstream corresponding to valid Path states. In doing so, 704 the subverted node can reserve excessive amounts of bandwidth thereby 705 possibly performing a denial of service attack. 707 Group keying allows the additional abuse of sending fake RSVP 708 messages to any node in the RSVP domain, not just adjacent RSVP 709 nodes. However, in practice this can be achieved to a large extent 710 also with per neighbor or interface keys, as discussed above. 711 Therefore the impact of subverted nodes on the path is comparable for 712 all keying schemes discussed here (per interface, per neighbor, group 713 keys). 715 11. Acknowledgements 717 The authors would like to thank everybody who provided feedback on 718 this document. Specific thanks to Bob Briscoe, Hannes Tschofenig, 719 Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg. 721 12. IANA Considerations 723 There are no IANA considerations within this document. This section 724 can be removed if this document is published as an RFC. 726 13. Informative References 728 [I-D.ietf-pcn-architecture] 729 Eardley, P., "Pre-Congestion Notification (PCN) 730 Architecture", draft-ietf-pcn-architecture-11 (work in 731 progress), April 2009. 733 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 734 Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP 735 Proxy Approaches", 736 draft-ietf-tsvwg-rsvp-proxy-approaches-09 (work in 737 progress), March 2010. 739 [I-D.weis-gdoi-mac-tek] 740 Weis, B. and S. Rowles, "GDOI Generic Message 741 Authentication Code Policy", draft-weis-gdoi-mac-tek-01 742 (work in progress), June 2010. 744 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 745 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 746 Functional Specification", RFC 2205, September 1997. 748 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 749 (IKE)", RFC 2409, November 1998. 751 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 752 Authentication", RFC 2747, January 2000. 754 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 755 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 756 RFC 3175, September 2001. 758 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 759 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 760 Tunnels", RFC 3209, December 2001. 762 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 763 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 764 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 766 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 767 Group Domain of Interpretation", RFC 3547, July 2003. 769 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 770 Architecture", RFC 3740, March 2004. 772 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 773 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 774 May 2005. 776 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 777 Hierarchy with Generalized Multi-Protocol Label Switching 778 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 780 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 781 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 782 November 2005. 784 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 785 Properties", RFC 4230, December 2005. 787 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 788 Internet Protocol", RFC 4301, December 2005. 790 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 791 December 2005. 793 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 794 RFC 4303, December 2005. 796 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 797 RFC 4306, December 2005. 799 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 800 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 801 RFC 4804, February 2007. 803 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 804 Davenport, "Generic Aggregate Resource ReSerVation 805 Protocol (RSVP) Reservations", RFC 4860, May 2007. 807 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 808 "Extensions to Resource Reservation Protocol - Traffic 809 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 810 Switched Paths (LSPs)", RFC 4875, May 2007. 812 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 813 Extensions to the Security Architecture for the Internet 814 Protocol", RFC 5374, November 2008. 816 Authors' Addresses 818 Michael H. Behringer 819 Cisco Systems 820 Village d'Entreprises Green Side 821 400, Avenue Roumanille, Batiment T 3 822 Biot - Sophia Antipolis 06410 823 France 825 Email: mbehring@cisco.com 826 URI: http://www.cisco.com 828 Francois Le Faucheur 829 Cisco Systems 830 Village d'Entreprises Green Side 831 400, Avenue Roumanille, Batiment T 3 832 Biot - Sophia Antipolis 06410 833 France 835 Email: flefauch@cisco.com 836 URI: http://www.cisco.com 838 Brian Weis 839 Cisco Systems 840 170 W. Tasman Drive 841 San Jose, California 95134-1706 842 USA 844 Email: bew@cisco.com 845 URI: http://www.cisco.com