idnits 2.17.1 draft-ietf-tsvwg-rsvp-security-groupkeying-07.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 200: '... 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 (September 23, 2010) is 4957 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2409' is defined on line 851, but no explicit reference was found in the text == Unused Reference: 'RFC4306' is defined on line 899, 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: 2 errors (**), 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: March 27, 2011 Cisco Systems 6 September 23, 2010 8 Applicability of Keying Methods for RSVP Security 9 draft-ietf-tsvwg-rsvp-security-groupkeying-07.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 27, 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. Changes to Previous Version . . . . . . . . . . . . . . . . . 16 82 12.1. changes from behringer-00 to behringer-01 . . . . . . . . 17 83 12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 17 84 12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 17 85 12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 17 86 12.5. changes from ietf-02 to ietf-03 . . . . . . . . . . . . . 17 87 12.6. changes from ietf-03 to ietf-04 . . . . . . . . . . . . . 18 88 12.7. changes from ietf-04 to ietf-05 . . . . . . . . . . . . . 18 89 12.8. changes from ietf-05 to ietf-06 . . . . . . . . . . . . . 18 90 12.9. changes from ietf-06 to ietf-07 . . . . . . . . . . . . . 18 91 13. Informative References . . . . . . . . . . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Introduction and Problem Statement 96 The Resource reSerVation Protocol [RFC2205] allows hop-by-hop 97 authentication of RSVP neighbors, as specified in [RFC2747]. In this 98 mode, an integrity object is attached to each RSVP message to 99 transmit a keyed message digest. This message digest allows the 100 recipient to verify the identity of the RSVP node that sent the 101 message, and to validate the integrity of the message. Through the 102 inclusion of a sequence number in the scope of the digest, the digest 103 also offers replay protection. 105 [RFC2747] does not dictate how the key for the integrity operation is 106 derived. Currently, most implementations of RSVP use a statically 107 configured key, per interface or per neighbor. However, to manually 108 configure a key per router pair across an entire network is 109 operationally hard, especially when key changes are to be performed 110 on a regular basis. Effectively, many users of RSVP therefore resort 111 to using the same key throughout their RSVP network, and they change 112 it rarely if ever, because of the operational burden. It is however 113 often necessary to regularly change keys due to network operational 114 requirements. 116 This document discusses a variety of keying methods and their 117 applicability to different RSVP deployment environments, for both 118 message integrity and encryption. It is meant as a comparative guide 119 to understand where each RSVP keying method is best deployed, and the 120 limitations of each method. Furthermore, it discusses how RSVP hop 121 by hop authentication is impacted in the presence of non-RSVP nodes, 122 or subverted nodes, in the reservation path. 124 The document "RSVP Security Properties" ([RFC4230]) provides an 125 overview of RSVP security, including RSVP Cryptographic 126 Authentication [RFC2747], but does not discuss key management. It 127 states that "RFC 2205 assumes that security associations are already 128 available". The present document focuses specifically on key 129 management with different key types, including group keys. Therefore 130 this document complements [RFC4230]. 132 2. The RSVP Hop-by-Hop Trust Model 134 Many protocol security mechanisms used in networks require and use 135 per peer authentication. Each hop authenticates its neighbor with a 136 shared key or certificate. This is also the model used for RSVP. 137 Trust in this model is transitive. Each RSVP node trusts explicitly 138 only its RSVP next hop peers, through the message digest contained in 139 the INTEGRITY object. The next hop RSVP speaker in turn trusts its 140 own peers and so on. See also the document "RSVP security 141 properties" [RFC4230] for more background. 143 The keys used for protecting RSVP messages can, in particular, be 144 group keys (for example distributed via GDOI [RFC3547], as discussed 145 in [I-D.weis-gdoi-mac-tek]). If a group key is used, the 146 authentication granularity becomes group membership of devices, not 147 (individual) peer authentication between devices. 149 The trust an RSVP node has to another RSVP node has an explicit and 150 an implicit component. Explicitly the node trusts the other node to 151 maintain the RSVP messages intact or confidential, depending on 152 whether authentication or encryption (or both) is used. This means 153 only that the message has not been altered or seen by another, non- 154 trusted node. Implicitly each node trusts each other node with which 155 it has a trust relationship established via the mechanisms here to 156 adhere to the protocol specifications laid out by the various 157 standards. Note that in any group keying scheme like GDOI a node 158 trusts all the other members of the group (because the authentication 159 is now based on group membership, as noted above). 161 The RSVP protocol can operate in the presence of a non-RSVP router in 162 the path from the sender to the receiver. The non-RSVP hop will 163 ignore the RSVP message and just pass it along. The next RSVP node 164 can then process the RSVP message. For RSVP authentication or 165 encryption to work in this case, the key used for computing the RSVP 166 message digest needs to be shared by the two RSVP neighbors, even if 167 they are not IP neighbors. However, in the presence of non-RSVP 168 hops, while an RSVP node always knows the next IP hop before 169 forwarding an RSVP Message, it does not always know the RSVP next 170 hop. In fact, part of the role of a Path message is precisely to 171 discover the RSVP next hop (and to dynamically re-discover it when it 172 changes, for example because of a routing change). Thus, the 173 presence of non-RSVP hops impacts operation of RSVP authentication or 174 encryption and may influence the selection of keying approaches. 176 Figure 1 illustrates this scenario. R2 in this picture does not 177 participate in RSVP, the other nodes do. In this case, R2 will pass 178 on any RSVP messages unchanged, and will ignore them. 180 ----R3--- 181 / \ 182 sender----R1---R2(*) R4----receiver 183 \ / 184 ----R5--- 185 (*) Non-RSVP hop 187 Figure 1: A non-RSVP Node in the path 189 This creates a challenge for RSVP authentication and encryption. In 190 the presence of a non-RSVP hop, with some RSVP messages such as a 191 PATH message, an RSVP router does not know the RSVP next hop for that 192 message at the time of forwarding it. For example, in Figure 1, R1 193 knows that the next IP hop for a Path message addressed to the 194 receiver is R2, but it does necessarily not know if the RSVP next hop 195 is R3 or R5. 197 This means that per interface and per neighbor keys cannot easily be 198 used in the presence of non-RSVP routers on the path between senders 199 and receivers. Section 4.3 of [RFC2747] states that "... the 200 receiver MAY initiate an integrity handshake with the sender." We 201 note that if this handshake is taking place, it can be used to 202 determine the identity of the next RSVP hop. In this case, non-RSVP 203 hops can be traversed also using per interface or per neighbor keys. 205 Group keying will naturally work in the presence of non-RSVP routers. 206 Referring back to Figure 1, with group keying, R1 would use the group 207 key to protect a Path message addressed to the receiver and forwards 208 it to R2. Being a non-RSVP node, R2 will ignore and forward the Path 209 message to R3 or R5 depending on the current shortest path as 210 determined by routing. Whether it is R3 or R5, the RSVP router that 211 receives the Path message will be able to authenticate it 212 successfully using the group key. 214 3. Applicability of Key Types for RSVP 216 3.1. Per interface and per neighbor keys 218 Most current RSVP authentication implementations support per 219 interface RSVP keys. When the interface is point-to-point (and 220 therefore an RSVP router has only a single RSVP neighbor on each 221 interface), this is equivalent to per neighbor keys in the sense that 222 a different key is used for each neighbor. However, when the 223 interface is multipoint, all RSVP speakers on a given subnet have to 224 share the same key in this model. This makes it unsuitable for 225 deployment scenarios where nodes from different security domains are 226 present on a subnet, for example Internet exchange points. A 227 security domain is defined here as a set of nodes that shares a 228 common RSVP security policy. In such cases, per neighbor keys are 229 required. 231 With per neighbor keys, each RSVP key is bound to an interface plus a 232 neighbor on that interface. It allows for the existence of different 233 security domains on a single interface and subnet. 235 per interface and per neighbor keys can be used within a single 236 security domain. As mentioned above, per interface keys are only 237 applicable when all the nodes reachable on the specific interface 238 belong to the same security domain. 240 These key types can also be used between security domains, since they 241 are specific to a particular interface or neighbor. Again, interface 242 level keys can be deployed safely only when all the reachable 243 neighbors on the interface belong to the same security domain. 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. Using group keys, they extend this trust to the 266 group key server. This is represented in Figure 2. 268 ......GKS1............. 269 : : : : : 270 : : : : : 271 source--R1--R2--R3-----destination 272 | | 273 |<-----domain 1----------------->| 275 Figure 2: Group Key Server within a single security domain 277 A single group key cannot normally be used to cover multiple security 278 domains, because by definition the different domains do not trust 279 each other. They would therefore not be willing to trust the same 280 group key server. For a single group key to be used in several 281 security domains, there is a need for a single group key server, 282 which is trusted by both sides. While this is theoretically 283 possible, in practice it is unlikely that there is a single such 284 entity trusted by both domains. Figure 3 illustrates this setup. 286 ...............GKS1.................... 287 : : : : : : : : 288 : : : : : : : : 289 source--R1--R2--R3--------R4--R5--R6--destination 290 | | | | 291 |<-----domain 1--->| |<-------domain 2----->| 293 Figure 3: A Single Group Key Server across security domains 295 A more practical approach for RSVP operation across security domains, 296 is to use a separate group key server for each security domain, and 297 to use per interface or per neighbor keys between the two domains. 298 Figure 4 shows this setup. 300 ....GKS1...... ....GKS2......... 301 : : : : : : : : 302 : : : : : : : : 303 source--R1--R2--R3--------R4--R5--R6--destination 304 | | | | 305 |<-----domain 1--->| |<-------domain 2----->| 307 Figure 4: A group Key Server per security domain 309 As discussed in Section 2, group keying can be used in the presence 310 of non-RSVP hops. 312 Because a group key may be used to verify messages from different 313 peers, monotonically increasing sequence number methods are not 314 appropriate. Time based anti-replay methods (e.g., the INTEGITY 315 sequence numbers based on a clock [RFC2747]) can be used with group 316 keys. 318 4. Key Provisioning Methods for RSVP 320 4.1. Static Key Provisioning 322 Static keys are preconfigured, either manually, or through a network 323 management system. The simplest way to implement RSVP authentication 324 is to use static keys. Static keying can be used with per interface 325 keys, per neighbor keys or group keys. 327 The provisioning of static keys requires either manual operator 328 intervention on each node, or a network management system performing 329 the same task. Time synchronization of static key provisioning and 330 changes is critical, to avoid inconsistent keys within a security 331 domain. 333 Static key provisioning is therefore not an ideal model in a large 334 network. 336 Often, the number of interconnection points across two domains where 337 RSVP is allowed to transit is relatively small and well controlled. 338 Also, the different domains may not be in a position to use an 339 infrastructure trusted by both domains to update keys on both sides. 340 Thus, statically provisioned keys may be applicable to inter-domain 341 RSVP authentication. 343 Since it is not feasible to carry out a key change at the exact same 344 time in communicating RSVP nodes, some grace period needs to be 345 implemented during which an RSVP node will accept both the old and 346 the new key. Otherwise, RSVP operation would suffer interruptions. 347 (Note that also with dynamic keying approaches there can be a grace 348 period where two keys are valid at the same time; however, the grace 349 period in manual keying tends to be significantly longer than with 350 dynamic key rollover schemes.) 352 4.2. Dynamic Keying 354 4.2.1. Per Neighbor and Per Interface Key Negotiation 356 To avoid the problem of manual key provisioning and updates in static 357 key deployments, key negotiation between RSVP neighbors could be used 358 to derive either per interface or per neighbor keys. 360 4.2.2. Dynamic Group Key Distribution 362 With this approach, group keys are dynamically distributed among a 363 set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes 364 a mechanism to distribute group keys to a group of RSVP speakers, 365 using GDOI [RFC3547]. In this solution, a key server authenticates 366 each of the RSVP nodes independently, and then distributes a group 367 key to the group as part of an encrypted and integrity protected key 368 agreement protocol. The authentication in this model can be based on 369 public key mechanisms, thereby avoiding the need for static key 370 provisioning. 372 5. Specific Cases Supporting Use of Group Keying 374 5.1. RSVP Notify Messages 376 [RFC3473] introduces the Notify message and allows such messages to 377 be sent in a non-hop-by-hop fashion. As discussed in the Security 378 Considerations section of [RFC3473], this can interfere with RSVP's 379 hop-by-hop integrity and authentication model. [RFC3473] describes 380 how standard IPsec based integrity and authentication can be used to 381 protect Notify messages. We observe that, alternatively, in some 382 environments, group keying may allow use of regular RSVP 383 authentication ([RFC2747]) for protection of non-hop-by-hop Notify 384 messages. 386 For example, RSVP Notify messages commonly used for traffic 387 engineering in MPLS networks are non-hop-by-hop messages. Such 388 messages may be sent from an ingress node directly to an egress node. 389 Group keying in such a case avoids the establishment of node-to-node 390 keying when node-to-node keying is not otherwise used. 392 5.2. RSVP-TE and GMPLS 394 Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast 395 Reroute [RFC4090] deserves additional considerations. 397 With the facility backup method of Fast Reroute, a backup tunnel from 398 the Point of Local Repair (PLR) to the Merge Point (MP) is used to 399 protect Label Switched Paths (protected LSPs) against the failure of 400 a facility (e.g., a router) located between the PLR and the MP. 401 During the failure of the facility, the PLR redirects a protected LSP 402 inside the backup tunnel and as a result, the PLR and MP then need to 403 exchange RSVP control messages between each other (e.g., for the 404 maintenance of the protected LSP). Some of the RSVP messages between 405 the PLR and MP are sent over the backup tunnel (e.g., a Path message 406 from PLR to MP) while some are directly addressed to the RSVP node 407 (e.g., a Resv message from MP to PLR). During the rerouted period, 408 the PLR and the MP effectively become RSVP neighbors, while they may 409 not be directly connected to each other and thus do not behave as 410 RSVP neighbors in the absence of failure. This point is raised in 411 the Security Considerations section of [RFC4090] that says: "Note 412 that the facility backup method requires that a PLR and its selected 413 merge point trust RSVP messages received from each other." We 414 observe that such environments may benefit from group keying. A 415 group key can be used among a set of routers enabled for Fast Reroute 416 thereby easily ensuring that PLR and MP authenticate messages from 417 each other can be authenticated, without requiring prior specific 418 configuration of keys, or activation of key update mechanism, for 419 every possible pair of PLR and MP. 421 Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS 422 boundaries (see [RFC4216]), the considerations presented above in 423 section 3.1 and 3.2 apply, such that per interface or per neighbor 424 keys can be used between two RSVP neighbors in different ASes 425 (independently of the keying method used by the RSVP router to talk 426 to the RSVP routers in the same AS). 428 [RFC4875] specifies protocol extensions for support of Point-to- 429 Multipoint (P2MP) RSVP-TE. In its Security Considerations section, 430 [RFC4875] points out that RSVP message integrity mechanisms for hop- 431 by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling. 432 In turn, we observe that the analyses in this document of keying 433 methods apply equally to P2MP RSVP-TE for the hop-by-hop signaling. 435 [RFC4206] defines LSP Hierarchy with GMPLS TE and uses non-hop-by-hop 436 signaling. Because it reuses LSP Hierarchy procedures for some of 437 its operations, P2MP RSVP-TE also uses non-hop-by-hop signaling. 438 Both LSP hierarchy and P2MP RSVP-TE rely on the security mechanisms 439 defined in [RFC3473] and [RFC4206] for non hop-by-hop RSVP-TE 440 signaling. We note that the observation in Section 3.1 of this 441 document about use of group keying for protection of non-hop-by-hop 442 messages apply to protection of non-hop-by-hop signaling for LSP 443 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. Note 451 that [RFC2747] states in section 1.2 that IPsec is not an optimal 452 choice to protect RSVP. The key argument is that an IPsec SA and an 453 RSVP SA are not based on the same parameters. Nevertheless, IPsec 454 can be used to protect RSVP. Note that the SPD traffic selectors for 455 related RSVP flows will not be constant. In some cases, the source 456 and destination addresses are end hosts, and sometimes they are RSVP 457 routers. Therefore, traffic selectors in the SPD should specify ANY 458 for the source address and destination addresses, and specify IP 459 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 [RFC3547] manages group security associations, which can be used by 466 IPsec. An example GDOI policy would be to encrypt or authenticate 467 all packets of the RSVP protocol itself (IP protocol 46). A router 468 implementing GDOI and the AH and/or ESP protocols is therefore able 469 to implement this policy. 471 Because the traffic selectors for an SA cannot be predicted, SA 472 lookup should use only the SPI (or SPI plus protocol). 474 6.2. Comparing AH and the INTEGRITY Object 476 The INTEGRITY object defined by [RFC2747] provides integrity 477 protection for RSVP also in a group keying context, as discussed 478 above. AH [RFC4302] is an alternative method to provide integrity 479 protection for RSVP packets. 481 The RSVP INTEGRITY object protects the entire RSVP message, but does 482 not protect the IP header of the packet nor the IP options (in IPv4) 483 or extension headers (in IPv6). 485 AH tunnel mode (transport mode is not applicable, see section 6.4) 486 protects the entire original IP packet, including the IP header of 487 the original IP packet ("inner header"), IP options or extension 488 headers, plus the entire RSVP packet. It also protects the immutable 489 fields of the outer header. 491 The difference between the two schemes in terms of covered fields is 492 therefore whether the IP header and IP options or extension headers 493 of the original IP packet are protected (as is the case with AH) or 494 not (as is the case with the INTEGRITY object). Also, AH covers the 495 immutable fields of the outer header. 497 As described in the next section, IPsec tunnel mode can not be 498 applied for RSVP traffic in the presence of non-RSVP nodes; therefore 499 the security associations in both cases, AH and INTEGRITY object, are 500 between the same RSVP neighbors. From a keying point of view both 501 approaches are therefore comparable. 503 6.3. Applicability of Tunnel Mode 505 IPsec tunnel mode encapsulates the original packet, prepending a new 506 IP header plus an ESP or AH sub-header. The entire original packet 507 plus the ESP/AH sub-header is secured. In the case of ESP the new, 508 outer IP header however is not cryptographically secured in this 509 process. 511 Protecting RSVP packets with IPsec tunnel mode works with any of the 512 above described keying methods (interface, neighbor or group based), 513 as long as there are no non-RSVP nodes on the path (however, see 514 group keying considerations below). Note that for RSVP messages to 515 be visible and considered at each hop, such a tunnel would not cross 516 routers, but each RSVP node would establish a tunnel with each of its 517 peers, effectively leading to link protection. 519 In the presence of a non-RSVP hop, tunnel mode cannot be applied, 520 because a router upstream from a non-RSVP hop does not know the next 521 RSVP hop, and can thus not apply the correct tunnel header. This is 522 independent of the key type used. 524 The use of group keying with ESP tunnel mode where a security gateway 525 places a peer security gateway address as the destination of the ESP 526 packet has consequences. In particular, if a man-in-the-middle 527 attacker re-directs the ESP-protected reservation to a different 528 security gateway, the receiving security gateway cannot detect that 529 the destination address was changed. However, it has received and 530 will act upon or route a RSVP reservation that will be be routed 531 along an unintended path. Because RSVP routers encountering the RSVP 532 packet path will not be aware that this is an unintended path, they 533 will act upon it and the resulting RSVP state along both the intended 534 path and unintended path will both be incorrect. Therefore group 535 keying should not be used with ESP tunnel mode except with address 536 preservation (see Section 6.5). 538 6.4. Non-Applicability of Transport Mode 540 IPsec transport mode, as defined in [RFC4303] is not suitable for 541 securing RSVP Path messages, since those messages preserve the 542 original source and destination. [RFC4303] states explicitly that 543 "the use of transport mode by an intermediate system (e.g., a 544 security gateway) is permitted only when applied to packets whose 545 source address (for outbound packets) or destination address (for 546 inbound packets) is an address belonging to the intermediate system 547 itself." This would not be the case for RSVP Path messages. 549 6.5. Applicability of Tunnel Mode with Address Preservation 551 When the identity of the next-hop RSVP peer is not known, it is not 552 possible to use a tunnel-endpoint destination address in the Tunnel 553 Mode outer IP header. The document "Multicast Extensions to the 554 Security Architecture for the Internet Protocol" [RFC5374] defines in 555 section 3.1 a new tunnel mode: Tunnel mode with address preservation. 556 This mode copies the destination and optionally the source address 557 from the inner header to the outer header. Therefore the 558 encapsulated packet will have the same destination address as the 559 original packet, and be normally subject to the same routing 560 decisions. While [RFC5374] is focusing on multicast environments, 561 tunnel mode with address preservation can be used also to protect 562 unicast traffic in conjunction with group keying. Note that in this 563 tunnel mode the RSVP speakers act as security gateways, because they 564 maintain the original end system addresses of the RSVP packets in the 565 outer tunnel mode IP header. This addressing scheme is used by RSVP 566 to ensure that the packets continue along the routed path toward the 567 destination end host. 569 Tunnel mode with address preservation, in conjunction with group 570 keying, allows the use of AH or ESP for protection of RSVP even in 571 cases where non-RSVP nodes have to be traversed. This is because it 572 allows routing of the IPsec protected packet through the non-RSVP 573 nodes in the same way as if it was not IPsec protected. 575 When used with group keying, tunnel mode with address preservation 576 can be used to mitigate re-direction attacks where a man-in-the- 577 middle modifies the destination of the outer IP header of the tunnel 578 mode packet. The inbound processing rules for tunnel mode with 579 address preservation (Section 5.2 of [RFC5374]) require that the 580 receiver verify that the addresses in the outer IP header and the 581 inner IP header are consistent. Therefore, the attack should be 582 detected and RSVP reservations will not proceed along an unintended 583 path. 585 7. End Host Considerations 587 Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches] 588 are used, RSVP signaling is controlled by end systems and not 589 routers. As discussed in [RFC4230], RSVP allows both user-based 590 security and host-based security. User-based authentication aims at 591 "providing policy based admission control mechanism based on user 592 identities or application." To identify the user or the application, 593 a policy element called AUTH_DATA, which is contained in the 594 POLICY_DATA object, is created by the RSVP daemon at the user's host 595 and transmitted inside the RSVP message. This way, a user may 596 authenticate to the Policy Decision Point (or directly to the first 597 hop router). Host-based security relies on the same mechanisms as 598 between routers (i.e., the INTEGRITY object) as specified in 599 [RFC2747]. For host-based security, per interface or per neighbor 600 keys may be used, however, key management with statically provisioned 601 keys can be difficult in a large scale deployment, as described in 602 section 4. In principle an end host can also be part of a group key 603 scheme, such as GDOI. If the end systems are part of the same 604 security domain as the network itself, group keying can be extended 605 to include the end systems. If the end systems and the network are 606 in different zones of trust, group keying cannot be used. 608 8. Applicability to Other Architectures and Protocols 610 While, so far, this document discusses only RSVP security assuming 611 the traditional RSVP model as defined by [RFC2205] and [RFC2747], the 612 analysis is also applicable to other RSVP deployment models as well 613 as to similar protocols: 615 o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This 616 scheme defines aggregation of individual RSVP reservations, and 617 discusses use of RSVP authentication for the signaling messages. 618 Group keying is applicable to this scheme, particularly when 619 automatic Deaggregator discovery is used, since in that case, the 620 Aggregator does not know ahead of time which Deaggregator will 621 intercept the initial end-to-end RSVP Path message. 622 o Generic Aggregate Resource ReSerVation Protocol (RSVP) 623 Reservations [RFC4860]: This document also discusses aggregation 624 of individual RSVP reservations. Here again, group keying applies 625 and is mentioned in the Security Considerations section. 626 o Aggregation of Resource ReSerVation Protocol (RSVP) Reservations 627 over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): This scheme also 628 defines a form of aggregation of RSVP reservation but this time 629 over MPLS TE Tunnels. Similarly, group keying may be used in such 630 an environment. 631 o Pre-Congestion Notification (PCN): [I-D.ietf-pcn-architecture] 632 defines an architecture for flow admission and termination based 633 on aggregated pre-congestion information. One deployment model 634 for this architecture is based on IntServ over DiffServ: the 635 DiffServ region is PCN-enabled, RSVP signalling is used end-to-end 636 but the PCN-domain is a single RSVP hop, i.e. only the PCN- 637 boundary-nodes process RSVP messages. In this scenario, RSVP 638 authentication may be required among PCN-boundary-nodes and the 639 considerations about keying approaches discussed earlier in this 640 document apply. In particular, group keying may facilitate 641 operations since the ingress PCN-boundary-node does not 642 necessarily know ahead of time which Egress PCN-boundary-node will 643 intercept and process the initial end-to-end Path message. Note 644 that from the viewpoint of securing end-to-end RSVP, there are a 645 lot of similarities in scenarios involving RSVP Aggregation over 646 aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP 647 Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP 648 (Aggregation) over PCN ingress-egress aggregates. 650 9. Summary 652 The following table summarizes the various approaches for RSVP 653 keying, and their applicability to various RSVP scenarios. In 654 particular, such keying can be used for RSVP authentication (e.g., 655 using the RSVP INTEGRITY object or AH) and/ or for RSVP encryption 656 (e.g., using ESP in tunnel mode). 658 +-------------------------------+-----------------+-----------------+ 659 | | per | Group keys | 660 | | neighbor/per | | 661 | | interface keys | | 662 +-------------------------------+-----------------+-----------------+ 663 | Works intra-domain | Yes | Yes | 664 | Works inter-domain | Yes | No | 665 | Works over non-RSVP hops | No | Yes (1) | 666 | Dynamic keying | Yes (IKE) | Yes (e.g., | 667 | | | GDOI) | 668 +-------------------------------+-----------------+-----------------+ 670 Table 1: Overview of keying approaches and their applicability 672 (1): RSVP integrity with group keys works over non-RSVP nodes; RSVP 673 encryption with ESP and RSVP authentication with AH work over non- 674 RSVP nodes in 'Tunnel Mode with Address Preservation'; RSVP 675 encryption with ESP & RSVP authentication with AH do not work over 676 non-RSVP nodes in 'Tunnel Mode'. 678 We also make the following observations: 680 o All key types can be used statically, or with dynamic key 681 negotiation. This impacts the manageability of the solution, but 682 not the applicability itself. 683 o For encryption of RSVP messages, IPsec ESP in tunnel mode can be 684 used. 685 o There are some special cases in RSVP, like non-RSVP hosts, the 686 "Notify" message (as discussed in Section 5.1), the various RSVP 687 deployment models discussed in Section 8 and MPLS Traffic 688 Engineering and GMPLS discussed in section 5.2 , which would 689 benefit from a group keying approach. 691 10. Security Considerations 693 This entire document discusses RSVP security; this section describes 694 a specific security considerations relating to subverted RSVP nodes. 696 10.1. Subverted Nodes 698 A subverted node is defined here as an untrusted node, for example 699 because an intruder has gained control over it. Since RSVP 700 authentication is hop-by-hop and not end-to-end, a subverted node in 701 the path breaks the chain of trust. This is to a large extent 702 independent of the type of keying used. 704 For interface or per neighbor keying, the subverted node can now 705 introduce fake messages to its neighbors. This can be used in a 706 variety of ways, for example by changing the receiver address in the 707 Path message, or by generating fake Path messages. This allows path 708 states to be created on every RSVP router along any arbitrary path 709 through the RSVP domain. That in itself could result in a form of 710 Denial of Service by allowing exhaustion of some router resources 711 (e.g. memory). The subverted node could also generate fake Resv 712 messages upstream corresponding to valid Path states. In doing so, 713 the subverted node can reserve excessive amounts of bandwidth thereby 714 possibly performing a denial of service attack. 716 Group keying allows the additional abuse of sending fake RSVP 717 messages to any node in the RSVP domain, not just adjacent RSVP 718 nodes. However, in practice this can be achieved to a large extent 719 also with per neighbor or interface keys, as discussed above. 720 Therefore the impact of subverted nodes on the path is comparable for 721 all keying schemes discussed here (per interface, per neighbor, group 722 keys). 724 11. Acknowledgements 726 The authors would like to thank everybody who provided feedback on 727 this document. Specific thanks to Bob Briscoe, Hannes Tschofenig, 728 Brian Weis, Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg. 730 12. Changes to Previous Version 732 This section provides a change log. It will be removed in the final 733 document: 735 12.1. changes from behringer-00 to behringer-01 737 o New section "Applicability to Other Architectures and Protocols": 738 Goal is to clarify the scope of this document: The idea presented 739 here is also applicable to other architectures 740 (PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc. 741 o Clarified the scope of this document versus RFC4230 (in the 742 introduction, last paragraph). 743 o Added a section on "End Host Considerations". 744 o Expanded section 5.5 (RSVP Encryption) to clarify that GDOI 745 contains all necessary mechanisms to do RSVP encrpytion. 746 o Tried to clarify the "trust to do what?" question raised by Bob 747 Briscoe in a mail on 26 Jul 2007. See the section on trust model. 748 o Lots of small editorial changes (references, typos, figures, etc). 749 o Added an Acknowledgements section. 751 12.2. changes from behringer-01 to ietf-00 753 o various edits to make it clearer that draft-weis-gdoi-for-rsvp is 754 an example of how dynamic group keying could be achieved for RSVP 755 and not necessarily the recommended solution 757 12.3. changes from ietf-00 to ietf-01 759 o Significant re-structuring of the entire document, to improve the 760 flow, and provide more consistency in various sections. 761 o Moved the "Subverted RSVP nodes" discussion into the security 762 considerations section. 763 o Added a "summary" section. 764 o Complete re-write of the old section 5.5 (RSVP encryption), and 765 "promotion" to a separate section. 766 o Changed reference ID.weis-gdoi-for-rsvp to the new draft ID.weis- 767 gdoi-mac-tek 768 o in several places, explicitly mentioned "encryption" for RSVP (in 769 parallel to authentication). 770 o Various minor edits. 772 12.4. changes from ietf-01 to ietf-02 774 o Re-wrote and re-structured the section on IPsec (section 6). 775 o Re-wrote the section on RSVP-TE and GMPLS (section 5.2). 776 o Various editorial changes. 778 12.5. changes from ietf-02 to ietf-03 780 o Extension of section 6.3 (Using IPsec AH), to address comments 781 received from Ran Atkinson. Included a comparison of what AH 782 protects vs what the INTEGRITY object protects. 784 o Added section 6.5 on "tunnel mode with address preservation. 785 o Some minor edits. 787 12.6. changes from ietf-03 to ietf-04 789 o Added below table 1 in note (1) that "RSVP encryption with ESP and 790 RSVP authentication with AH work over non-RSVP nodes in 'Tunnel 791 Mode with Address Preservation'" 793 12.7. changes from ietf-04 to ietf-05 795 o Clarified in section 6.3 that IPsec AH also secures the immutable 796 fields of the outer header (comment from Bob Briscoe) 797 o Simplified in section 2 the comment that trust in group keying 798 extends to all members of the group (deleted the words on 799 "explicit and implicit"). (comment from Brian Weis) 800 o A number of corrections, re-wordings and clarifications in 801 response to Kenneth Carlberg's email from 2 June 2009 803 12.8. changes from ietf-05 to ietf-06 805 This version addresses extensive comments from Stephen Kent in the 806 SecDir review (see email from Gorry on 15 Jan 2010). Specifically: 807 o Many editorial changes, and small corrections. 808 o Deleted reference to RFC3562, since it is not applicable in this 809 context. 810 o Clarification in section 2 that the handshake specified in RFC2747 811 allows to determine the identity of the next RSVP hop in the 812 presence of non-RSVP hops. 813 o Cleared up inconsistent wording on "trust group" and "security 814 domain", and defined the latter. (Section 3) 815 o Added a paragraph on the applicability of sequence numbers in 816 section 3.1 and 3.2. 817 o Defined static key provisioning. (Section 4.1) 818 o Clarified wording in 6.1 on the use of GDOI. 819 o Added in section 6.6 some clarification to the use of tunnel mode 820 with address preservation. 822 12.9. changes from ietf-06 to ietf-07 824 This version addressed the last WGLC, and incorporates a few comments 825 from Bob Briscoe, mostly editorial. The main change is the re- 826 insertion of a potential man-in-the-middle attack with group keying, 827 which was accidentally deleted. Affected sections are 6.3 and 6.5. 829 13. Informative References 831 [I-D.ietf-pcn-architecture] 832 Eardley, P., "Pre-Congestion Notification (PCN) 833 Architecture", draft-ietf-pcn-architecture-11 (work in 834 progress), April 2009. 836 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 837 Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP 838 Proxy Approaches", 839 draft-ietf-tsvwg-rsvp-proxy-approaches-09 (work in 840 progress), March 2010. 842 [I-D.weis-gdoi-mac-tek] 843 Weis, B. and S. Rowles, "GDOI Generic Message 844 Authentication Code Policy", draft-weis-gdoi-mac-tek-01 845 (work in progress), June 2010. 847 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 848 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 849 Functional Specification", RFC 2205, September 1997. 851 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 852 (IKE)", RFC 2409, November 1998. 854 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 855 Authentication", RFC 2747, January 2000. 857 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 858 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 859 RFC 3175, September 2001. 861 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 862 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 863 Tunnels", RFC 3209, December 2001. 865 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 866 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 867 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 869 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 870 Group Domain of Interpretation", RFC 3547, July 2003. 872 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 873 Architecture", RFC 3740, March 2004. 875 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 876 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 877 May 2005. 879 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 880 Hierarchy with Generalized Multi-Protocol Label Switching 881 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 883 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 884 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 885 November 2005. 887 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 888 Properties", RFC 4230, December 2005. 890 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 891 Internet Protocol", RFC 4301, December 2005. 893 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 894 December 2005. 896 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 897 RFC 4303, December 2005. 899 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 900 RFC 4306, December 2005. 902 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 903 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 904 RFC 4804, February 2007. 906 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 907 Davenport, "Generic Aggregate Resource ReSerVation 908 Protocol (RSVP) Reservations", RFC 4860, May 2007. 910 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 911 "Extensions to Resource Reservation Protocol - Traffic 912 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 913 Switched Paths (LSPs)", RFC 4875, May 2007. 915 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 916 Extensions to the Security Architecture for the Internet 917 Protocol", RFC 5374, November 2008. 919 Authors' Addresses 921 Michael H. Behringer 922 Cisco Systems 923 Village d'Entreprises Green Side 924 400, Avenue Roumanille, Batiment T 3 925 Biot - Sophia Antipolis 06410 926 France 928 Email: mbehring@cisco.com 929 URI: http://www.cisco.com 931 Francois Le Faucheur 932 Cisco Systems 933 Village d'Entreprises Green Side 934 400, Avenue Roumanille, Batiment T 3 935 Biot - Sophia Antipolis 06410 936 France 938 Email: flefauch@cisco.com 939 URI: http://www.cisco.com 941 Brian Weis 942 Cisco Systems 943 170 W. Tasman Drive 944 San Jose, California 95134-1706 945 USA 947 Email: bew@cisco.com 948 URI: http://www.cisco.com