idnits 2.17.1 draft-ietf-tsvwg-rsvp-security-groupkeying-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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.) 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 (June 4, 2009) is 5439 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-rsvp-proxy-approaches-07 == Outdated reference: A later version (-03) exists of draft-weis-gdoi-mac-tek-00 -- 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 (~~), 3 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 Cisco Systems Inc 5 Expires: December 6, 2009 June 4, 2009 7 Applicability of Keying Methods for RSVP Security 8 draft-ietf-tsvwg-rsvp-security-groupkeying-05.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 6, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 The Resource reSerVation Protocol (RSVP) allows hop-by-hop 47 authentication of RSVP neighbors. This requires messages to be 48 cryptographically signed using a shared secret between participating 49 nodes. This document compares group keying for RSVP with per 50 neighbor or per interface keying, and discusses the associated key 51 provisioning methods as well as applicability and limitations of 52 these approaches. The present document also discusses applicability 53 of group keying to RSVP encryption. 55 Table of Contents 57 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 58 2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 3 59 3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5 60 3.1. Interface and neighbor based keys . . . . . . . . . . . . 5 61 3.2. Group keys . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 7 63 4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 7 64 4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8 65 4.2.1. Neighbor and Interface Based Key Negotiation . . . . . 8 66 4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 8 67 5. Specific Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 8 69 5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 8 70 6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10 71 6.1. General Considerations Using IPsec . . . . . . . . . . . . 10 72 6.2. Using IPsec ESP . . . . . . . . . . . . . . . . . . . . . 10 73 6.3. Using IPsec AH . . . . . . . . . . . . . . . . . . . . . . 11 74 6.4. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 11 75 6.5. Applicability of Transport Mode . . . . . . . . . . . . . 12 76 6.6. Applicability of Tunnel Mode with Address Preservation . . 12 77 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 12 78 8. Applicability to Other Architectures and Protocols . . . . . . 13 79 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 10.1. Subverted RSVP Nodes . . . . . . . . . . . . . . . . . . . 15 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 12. Changes to Previous Version . . . . . . . . . . . . . . . . . 15 84 12.1. changes from behringer-00 to behringer-01 . . . . . . . . 16 85 12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 16 86 12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 16 87 12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 16 88 12.5. changes from ietf-02 to ietf-03 . . . . . . . . . . . . . 16 89 12.6. changes from ietf-03 to ietf-04 . . . . . . . . . . . . . 17 90 12.7. changes from ietf-04 to ietf-05 . . . . . . . . . . . . . 17 91 13. Informative References . . . . . . . . . . . . . . . . . . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 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 authenticity 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 key per router pair across an entire network is 109 operationally hard, especially for key changes. Effectively, many 110 users of RSVP therefore resort to the same key throughout their RSVP 111 network, and change it rarely if ever, because of the operational 112 burden. [RFC3562] however recommends regular key changes, at least 113 every 90 days. 115 The present document discusses the various keying methods and their 116 applicability to different RSVP deployment environments, for both 117 message integrity and encryption. It does not recommend any 118 particular method or protocol (e.g., RSVP authentication versus IPsec 119 AH), but is meant as a comparative guideline to understand where each 120 RSVP keying method is best deployed, and its limitations. 121 Furthermore, it discusses how RSVP hop by hop authentication is 122 impacted in the presence of non-RSVP nodes, or subverted nodes, in 123 the reservation path. 125 The document "RSVP Security Properties" ([RFC4230]) provides an 126 overview of RSVP security, including RSVP Cryptographic 127 Authentication [RFC2747], but does not discuss key management. It 128 states that "RFC 2205 assumes that security associations are already 129 available". The present document focuses specifically on key 130 management with different key types, including group keys. Therefore 131 this document complements [RFC4230]. 133 2. The RSVP Hop-by-Hop Trust Model 135 Many protocol security mechanisms used in networks require and use 136 per peer authentication. Each hop authenticates its neighbor with a 137 shared key or certificate. This is also the model used for RSVP. 138 Trust in this model is transitive. Each RSVP node trusts explicitly 139 only its RSVP next hop peers, through the message digest contained in 140 the INTEGRITY object. The next hop RSVP speaker in turn trusts its 141 own peers and so on. See also the document "RSVP security 142 properties" [RFC4230] for more background. 144 The keys used for generating the RSVP messages can, in particular, be 145 group keys (for example distributed via GDOI [RFC3547], as discussed 146 in [I-D.weis-gdoi-mac-tek]). 148 The trust an RSVP node has to another RSVP node has an explicit and 149 an implicit component. Explicitly the node trusts the other node to 150 maintain the RSVP messages intact or confidential, depending on 151 whether authentication or encryption (or both) is used. This means 152 only that the message has not been altered or seen by another, non- 153 trusted node. Implicitly each node trusts each other node with which 154 it has a trust relationship established via the mechanisms here to 155 adhere to the protocol specifications laid out by the various 156 standards. Note that in any group keying scheme like GDOI a node 157 trusts all the other members of the group. 159 The RSVP protocol can operate in the presence of a non-RSVP router in 160 the path from the sender to the receiver. The non-RSVP hop will 161 ignore the RSVP message and just pass it along. The next RSVP node 162 can then process the RSVP message. For RSVP authentication or 163 encryption to work in this case, the key used for computing the RSVP 164 message digest needs to be shared by the two RSVP neighbors, even if 165 they are not IP neighbors. However, in the presence of non-RSVP 166 hops, while an RSVP node always knows the next IP hop before 167 forwarding an RSVP Message, it does not always know the RSVP next 168 hop. In fact, part of the role of a Path message is precisely to 169 discover the RSVP next hop (and to dynamically re-discover it when it 170 changes, for example because of a routing change). Thus, the 171 presence of non-RSVP hops impacts operation of RSVP authentication or 172 encryption and may influence the selection of keying approaches. 174 Figure 1 illustrates this scenario. R2 in this picture does not 175 participate in RSVP, the other nodes do. In this case, R2 will pass 176 on any RSVP messages unchanged, and will ignore them. 178 ----R3--- 179 / \ 180 sender----R1---R2(*) R4----receiver 181 \ / 182 ----R5--- 183 (*) Non-RSVP hop 185 Figure 1: A non-RSVP Node in the path 187 This creates a challenge for RSVP authentication and encryption. In 188 the presence of a non-RSVP hop, with some RSVP messages such as a 189 PATH message, an RSVP router does not know the RSVP next hop for that 190 message at the time of forwarding it. For example, in Figure 1, R1 191 knows that the next IP hop for a Path message addressed to the 192 receiver is R2, but it does necessarily not know if the RSVP next hop 193 is R3 or R5. 195 This means that per interface and per neighbor keys cannot easily be 196 used in the presence of non-RSVP routers on the path between senders 197 and receivers. 199 By contrast, group keying will naturally work in the presence of non- 200 RSVP routers. Referring back to Figure 1, with group keying, R1 201 would use the group key to sign a Path message addressed to the 202 receiver and forwards it to R2. Being a non-RSVP node, R2 will 203 ignore and forward the Path message to R3 or R5 depending on the 204 current shortest path as determined by routing. Whether it is R3 or 205 R5, the RSVP router that receives the Path message will be able to 206 authenticate it successfully with the group key. 208 3. Applicability of Key Types for RSVP 210 3.1. Interface and neighbor based keys 212 Most current RSVP authentication implementations support interface 213 based RSVP keys. When the interface is point-to-point (and therefore 214 an RSVP router only has a single RSVP neighbor on each interface), 215 this is equivalent to neighbor based keys in the sense that a 216 different key is used for each neighbor. However, when the interface 217 is multipoint, all RSVP speakers on a given subnet have to share the 218 same key in this model, which makes it unsuitable for deployment 219 scenarios where different trust groups share a subnet, for example 220 Internet exchange points. In such a case, neighbor based keys are 221 required. 223 With neighbor based keys, an RSVP key is bound to an interface plus a 224 neighbor on that interface. It allows the distinction of different 225 trust groups on a single interface and subnet. (Assuming that 226 layer-2 security is correctly implemented to prevent layer-2 227 attacks.) 229 Per interface and per neighbor keys can be used within a single 230 security domain. As mentioned above, per interface keys are only 231 applicable when all the nodes reachable on the specific interface 232 belong to the same security domain. 234 These key types can also be used between security domains, since they 235 are specific to a particular interface or neighbor. Again, interface 236 level keys can only be deployed safely when all the reachable 237 neighbors on the interface belong to the same security domain. 239 As discussed in the previous section, per neighbor and per interface 240 keys can not be used in the presence of non-RSVP hops. 242 3.2. Group keys 244 Here, all members of a group of RSVP nodes share the same key. This 245 implies that a node uses the same key regardless of the next RSVP hop 246 that will process the message (within the group of nodes sharing the 247 particular key). It also implies that a node will use the same key 248 on the receiving as on the sending side (when exchanging RSVP 249 messages within the group). 251 Group keys apply naturally to intra-domain RSVP authentication, since 252 all RSVP nodes implicitly trust each other. Using group keys, they 253 extend this trust to the group key server. This is represented in 254 Figure 2. 256 ......GKS1............. 257 : : : : : 258 : : : : : 259 source--R1--R2--R3-----destination 260 | | 261 |<-----domain 1----------------->| 263 Figure 2: Group Key Server within a single security domain 265 A single group key cannot normally be used to cover multiple security 266 domains, because by definition the different domains do not trust 267 each other. They would therefore not be willing to trust the same 268 group key server. For a single group key to be used in several 269 security domains, there is a need for a single group key server, 270 which is trusted by both sides. While this is theoretically 271 possible, in practice it is unlikely that there is a single such 272 entity trusted by both domains. Figure 3 illustrates this setup. 274 ...............GKS1.................... 275 : : : : : : : : 276 : : : : : : : : 277 source--R1--R2--R3--------R4--R5--R6--destination 278 | | | | 279 |<-----domain 1--->| |<-------domain 2----->| 281 Figure 3: A Single Group Key Server across security domains 283 A more practical approach for RSVP operation across security domains, 284 is to use a separate group key server for each security domain, and 285 to use per interface or per neighbor authentication between the two 286 domains. Figure 4 shows this set-up. 288 ....GKS1...... ....GKS2......... 289 : : : : : : : : 290 : : : : : : : : 291 source--R1--R2--R3--------R4--R5--R6--destination 292 | | | | 293 |<-----domain 1--->| |<-------domain 2----->| 295 Figure 4: A group Key Server per security domain 297 As discussed in section 2, group keying can be used in the presence 298 of non-RSVP hops. 300 4. Key Provisioning Methods for RSVP 302 4.1. Static Key Provisioning 304 The simplest way to implement RSVP authentication is to use static, 305 preconfigured keys. Static keying can be used with interface based 306 keys, neighbor based keys or group keys. 308 However, such static key provisioning is expensive on the operational 309 side, since no secure automated mechanism can be used, and initial 310 provisioning as well as key updates require configuration. This 311 method is therefore mostly useful for small deployments, where key 312 changes can be carried out manually, or for deployments with 313 automated configuration tools which support key changes. 315 Static key provisioning is therefore not an ideal model in a large 316 network. 318 Often, the number of interconnection points across two domains where 319 RSVP is allowed to transit is relatively small and well controlled. 320 Also, the different domains may not be in a position to use an 321 infrastructure trusted by both domains to update keys on both sides. 322 Thus, manually configured keys may be applicable to inter-domain RSVP 323 authentication. 325 Since it is not feasible to carry out the key change at the exact 326 same time on both sides, some grace period needs to be implemented 327 during which an RSVP node will accept both the old and the new key. 328 Otherwise, RSVP operation would suffer interruptions. (Note that 329 also with dynamic keying approaches there can be a grace period where 330 two keys are valid at the same time; however, the grace period in 331 manual keying tends to be significantly longer than with dynamic key 332 rollover schemes.) 334 4.2. Dynamic Keying 336 4.2.1. Neighbor and Interface Based Key Negotiation 338 To avoid the problem of manual key provisioning and updates in static 339 key deployments, key negotiation between RSVP neighbors could be used 340 to derive either interface or neighbor based keys. However, existing 341 key negotiation protocols such as IKEv1 [RFC2409] or IKEv2 [RFC4306] 342 may not be appropriate in all environments because of the relative 343 complexity of the protocols and related operations. 345 4.2.2. Dynamic Group Key Distribution 347 With this approach, group keys are dynamically distributed among a 348 set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes 349 a mechanism to distribute group keys to a group of RSVP speakers, 350 using GDOI [RFC3547]. In this solution, a key server authenticates 351 each of the RSVP nodes independently, and then distributes a group 352 key to the entire group. 354 5. Specific Cases 356 5.1. RSVP Notify Messages 358 [RFC3473] introduces the Notify message and allows such Notify 359 messages to be sent in a non-hop-by-hop fashion. As discussed in the 360 Security Considerations section of [RFC3473], this can interfere with 361 RSVP's hop-by-hop integrity and authentication model. [RFC3473] 362 describes how standard IPsec based integrity and authentication can 363 be used to protect Notify messages. We observe that, alternatively, 364 in some environments, group keying may allow use of regular RSVP 365 authentication ([RFC2747]) for protection of non-hop-by-hop Notify 366 messages. For example, this may be applicable to controlled 367 environments where nodes invoking notification requests are known to 368 belong to the same key group as nodes generating Notify messages. 370 5.2. RSVP-TE and GMPLS 372 Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast 373 Reroute [RFC4090] deserves additional considerations. 375 With the facility backup method of Fast Reroute, a backup tunnel from 376 the Point of Local Repair (PLR) to the Merge Point (MP) is used to 377 protect Label Switched Paths (protected LSPs) against the failure of 378 a facility (e.g. a router) located between the PLR and the MP. 379 During the failure of the facility, the PLR redirects a protected LSP 380 inside the backup tunnel and as a result, the PLR and MP then need to 381 exchange RSVP control messages between each other (e.g. for the 382 maintenance of the protected LSP). Some of the RSVP messages between 383 the PLR and MP are sent over the backup tunnel (e.g. a Path message 384 from PLR to MP) while some are directly addressed to the RSVP node 385 (e.g. a Resv message from MP to PLR). During the rerouted period, 386 the PLR and the MP effectively become RSVP neighbors, while they may 387 not be directly connected to each other and thus do not behave as 388 RSVP neighbors in the absence of failure. This point is raised in 389 the Security Considerations section of [RFC4090] that says: "Note 390 that the facility backup method requires that a PLR and its selected 391 merge point trust RSVP messages received from each other." We 392 observe that such environments may benefit from group keying: a group 393 key can be used among a set of routers enabled for Fast Reroute 394 thereby easily ensuring that a PLR and MP authenticate messages from 395 each other, without requiring prior specific configuration of keys, 396 or activation of key update mechanism, for every possible pair of PLR 397 and MP. 399 Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS 400 boundaries (see [RFC4216]), the considerations presented above in 401 section 3.1 and 3.2 apply such that per interface or per neighbor 402 keys can be used between two RSVP neighbors in different ASes 403 (independently of the keying method used by the RSVP router to talk 404 to the RSVP routers in the same AS). 406 [RFC4875] specifies protocol extensions for support of Point-to- 407 Multipoint (P2MP) RSVP-TE. In its security considerations section, 408 [RFC4875] points out that RSVP message integrity mechanisms for hop- 409 by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling. 410 In turn, we observe that the considerations in this document on 411 keying methods apply equally to P2MP RSVP-TE for the hop-by-hop 412 signaling. 414 [RFC4206] defines LSP Hierarchy with GMPLS TE and uses non-hop-by-hop 415 signaling. Because it reuses LSP Hierarchy procedures for some of 416 its operations, P2MP RSVP-TE also uses non-hop-by-hop signaling. 417 Both LSP hierarchy and P2MP RSVP-TE rely on the security mechanisms 418 defined in [RFC3473] and [RFC4206] for non hop-by-hop RSVP-TE 419 signaling. We note that the observation in section 3.1 of this 420 document about use of group keying for protection of non-hop-by-hop 421 messages apply to protection of non-hop-by-hop signaling for LSP 422 Hierarchy and P2MP RSVP- TE. 424 6. Applicability of IPsec for RSVP 426 6.1. General Considerations Using IPsec 428 The discussions about the various keying methods in this document are 429 also applicable when using IPsec to protect RSVP. Note that 430 [RFC2747] states in section 1.2 that IPsec is not an optimal choice 431 to protect RSVP. The key argument is that an IPsec SA and an RSVP SA 432 are not based on the same parameters. However, when using group 433 keying, IPsec can be used to protect RSVP. The potential issues and 434 solutions using group keying are: 436 o [RFC2747] specifies in section 4.2, bullet 3, that both the key 437 identifier and the sending system address are used to uniquely 438 determine the key. In a group keying scenario it would be 439 necessary to either store a list of senders to do this, or to not 440 use the sending system address to determine the key. Both methods 441 are valid, and one of the two approaches must be chosen. The pros 442 and cons are beyond the scope of this document. 443 o Anti-replay protection in a group keying scenario requires some 444 changes to the way [RFC2747] defines anti-replay. Possible 445 solutions are discussed in detail in [I-D.weis-gdoi-mac-tek]). 446 For example, when using counter-based methods with various senders 447 in a single SA, the same counter may be received more than once, 448 this conflicts with [RFC2747], which states that each counter 449 value may only be accepted once. Time based approaches are a 450 solution for group keying scenarios. 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] contains all relevant policy options to secure RSVP with 457 IPsec, and no extensions are necessary. An example GDOI policy would 458 be to encrypt all packets of the RSVP protocol itself (IP protocol 459 46). A router implementing GDOI and IPsec protocols is therefore 460 able to implement RSVP encryption. 462 6.2. Using IPsec ESP 464 In both tunnel mode and transport mode, ESP does not protect the 465 header (in tunnel mode the outer header). This is an issue with 466 group keying when using ESP to secure the RSVP packets: the packet 467 header could be modified by a man-in-the-middle attack, replacing the 468 destination address with another RSVP router in the network. This 469 router will receive the packet, use the group key to decrypt the 470 encapsulated packet, and then act on the RSVP packet. This way an 471 attacker cannot create new reservations or affect existing ones, but 472 he can "re-direct" reservations to parts of the network off the 473 actual reservation path, thereby potentially denying resources to 474 other applications on that part of the network. 476 6.3. Using IPsec AH 478 The INTEGRITY object defined by [RFC2747] provides integrity 479 protection for RSVP also in a group keying context, as discussed 480 above. IPsec AH [RFC4302] is an alternative method to provide 481 integrity protection for RSVP packets. 483 The RSVP INTEGRITY object protects the entire RSVP message, but does 484 not protect the IP header of the packet nor the IP options (in IPv4) 485 or extension headers (in IPv6). 487 IPsec AH tunnel mode (transport mode is not appliable, see section 488 6.5) protects the entire original IP packet, including the IP header 489 of the original IP packet ("inner header"), IP options or extension 490 headers, plus the entire RSVP packet. It also protects the immutable 491 fields of the outer header. 493 The difference between the two schemes in terms of covered fields is 494 therefore whether the IP header and IP options or extension headers 495 of the original IP packet are protected (as is the case with AH) or 496 not (as is the case with the INTEGRITY object). Also, IPsec AH 497 covers the immutable fields of the outer header. 499 As described in the next section, IPsec tunnel mode can not be 500 applied for RSVP traffic in the presence of non-RSVP nodes; therefore 501 the security associations in both cases, AH and INTEGRITY object, are 502 between the same RSVP neighbors. From a keying point of view both 503 approaches are therefore comparable. This document focuses on keying 504 approaches only; a general security comparison of these approaches is 505 outside the scope of this document. 507 6.4. Applicability of Tunnel Mode 509 IPsec tunnel mode encapsulates the original packet, prepending a new 510 IP tunnel header plus an ESP or AH sub-header. The entire original 511 packet plus the ESP/AH subheader is secured. In the case of ESP the 512 new, outer IP header however is not cryptographically secured in this 513 process. This leads to the problem described in Section 6.2. AH 514 tunnel mode also secures the outer header, and is therefore not 515 subject to these man-in-the-middle attacks. 517 Protecting RSVP packets with IPsec tunnel mode works with any of the 518 above described keying methods (interface, neighbor or group based), 519 as long as there are no non-RSVP nodes on the path. Note that for 520 RSVP messages to be visible and considered at each hop, such a tunnel 521 would not cross routers, but each RSVP node would establish a tunnel 522 with each of its peers, effectively leading to link protection. 524 In the presence of a non-RSVP hop, tunnel mode can not be applied, 525 because a router upstream a non-RSVP hop does not know the next RSVP 526 hop, and can thus not apply the correct tunnel header. This is 527 independent of the key type used. 529 6.5. 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.6. Applicability of Tunnel Mode with Address Preservation 542 The document "Multicast Extensions to the Security Architecture for 543 the Internet Protocol" [RFC5374] defines in section 3.1 a new tunnel 544 mode: Tunnel mode with address preservation. This mode copies the 545 destination and optionally the source address from the inner header 546 to the outer header. Therefore the encapsulated packet will have the 547 same destination address as the original packet, and be normally 548 subject to the same routing decisions. While [RFC5374] is focusing 549 on multicast environments, tunnel mode with address preservation can 550 be used also to protect unicast traffic in conjunction with group 551 keying. 553 Tunnel mode with address preservation, in conjunction with group 554 keying, allows the use of IPsec AH or ESP for protection of RSVP even 555 in cases where non-RSVP nodes have to be traversed. This is because 556 it allows routing of the IPsec protected packet through the non-RSVP 557 nodes in the same way as if it was not IPsec protected. 559 7. End Host Considerations 561 Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches] 562 are used, RSVP signaling is controlled by end systems and not 563 routers. As discussed in [RFC4230], RSVP allows both user-based 564 security and host-based security. User-based authentication aims at 565 "providing policy based admission control mechanism based on user 566 identities or application." To identify the user or the application, 567 a policy element called AUTH_DATA, which is contained in the 568 POLICY_DATA object, is created by the RSVP daemon at the user's host 569 and transmitted inside the RSVP message. This way, a user may 570 authenticate to the Policy Decision Point (or directly to the first 571 hop router). Host-based security relies on the same mechanisms as 572 between routers (i.e. INTEGRITY object) as specified in [RFC2747]. 573 For host-based security, interface or neighbor based keys may be 574 used, however, key management with pre-shared keys can be difficult 575 in a large scale deployment, as described in section 4. In principle 576 an end host can also be part of a group key scheme, such as GDOI. If 577 the end systems are part of the same zone of trust as the network 578 itself, group keying can be extended to include the end systems. If 579 the end systems and the network are in different zones of trust, 580 group keying cannot be used. 582 8. Applicability to Other Architectures and Protocols 584 While, so far, this document only discusses RSVP security assuming 585 the traditional RSVP model as defined by [RFC2205] and [RFC2747], the 586 analysis is also applicable to other RSVP deployment models as well 587 as to similar protocols: 589 o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This 590 scheme defines aggregation of individual RSVP reservations, and 591 discusses use of RSVP authentication for the signaling messages. 592 Group keying is applicable to this scheme, particularly when 593 automatic Deaggregator discovery is used, since in that case, the 594 Aggregator does not know ahead of time which Deaggregator will 595 intercept the initial end-to-end RSVP Path message. 596 o Generic Aggregate Resource ReSerVation Protocol (RSVP) 597 Reservations [RFC4860]: This document also discusses aggregation 598 of individual RSVP reservations. Here again, group keying applies 599 and is mentioned in the Security Considerations section. 600 o Aggregation of Resource ReSerVation Protocol (RSVP) Reservations 601 over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): This scheme also 602 defines a form of aggregation of RSVP reservation but this time 603 over MPLS TE Tunnels. Similarly, group keying may be used in such 604 an environment. 605 o Pre-Congestion Notification (PCN): [I-D.ietf-pcn-architecture] 606 defines an architecture for flow admission and termination based 607 on aggregated pre-congestion information. One deployment model 608 for this architecture is based on IntServ over DiffServ: the 609 DiffServ region is PCN-enabled, RSVP signalling is used end-to-end 610 but the PCN-domain is a single RSVP hop, i.e. only the PCN- 611 boundary-nodes process RSVP messages. In this scenario, RSVP 612 authentication may be required among PCN-boundary-nodes and the 613 considerations about keying approaches discussed earlier in this 614 document apply. In particular, group keying may facilitate 615 operations since the ingress PCN-boundary-node does not 616 necessarily know ahead of time which Egress PCN-boundary-node will 617 intercept and process the initial end-to-end Path message. Note 618 that from the viewpoint of securing end-to-end RSVP, there are a 619 lot of similarities in scenarios involving RSVP Aggregation over 620 aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP 621 Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP 622 (Aggregation) over PCN ingress-egress aggregates. 624 9. Summary 626 The following table summarizes the various approaches for RSVP 627 keying, and their applicability to various RSVP scenarios. In 628 particular, such keying can be used for RSVP authentication (e.g., 629 using the RSVP INTEGRITY object or IPsec AH) and/ or for RSVP 630 encryption (e.g., using IPsec ESP in tunnel mode). 632 +-----------------------------+--------------------+----------------+ 633 | | Neighbor/interface | Group keys | 634 | | based keys | | 635 +-----------------------------+--------------------+----------------+ 636 | Works intra-domain | Yes | Yes | 637 | Works inter-domain | Yes | No | 638 | Works over non-RSVP hops | No | Yes (1) | 639 | Dynamic keying | Yes (IKE) | Yes (eg GDOI) | 640 +-----------------------------+--------------------+----------------+ 642 Table 1: Overview of keying approaches and their applicability 644 (1): RSVP integrity with group keys works over non-RSVP nodes; RSVP 645 encryption with ESP and RSVP authentication with AH work over non- 646 RSVP nodes in 'Tunnel Mode with Address Preservation'; RSVP 647 encryption with ESP & RSVP authentication with AH do not work over 648 non-RSVP nodes in 'Tunnel Mode'. 650 We also make the following observations: 652 o All key types can be used statically, or with dynamic key 653 negotiation. This impacts the managability of the solution, but 654 not the applicability itself. 655 o For encryption of RSVP messages IPsec ESP in tunnel mode can be 656 used. There is however a security concern, see Section 6.2. 657 o There are some special cases in RSVP, like non-RSVP hosts, the 658 "Notify" message (as discussed in section 5.1), the various RSVP 659 deployment models discussed in Section 8 and MPLS Traffic 660 Engineering and GMPLS discussed in section 5.2 , which would 661 benefit from a group keying approach. 663 10. Security Considerations 665 This entire document discusses RSVP security; this section describes 666 a specific security considerations relating to subverted RSVP nodes 668 10.1. Subverted RSVP Nodes 670 A subverted node is defined here as an untrusted node, for example 671 because an intruder has gained control over it. Since RSVP 672 authentication is hop-by-hop and not end-to-end, a subverted node in 673 the path breaks the chain of trust. This is to a large extent 674 independent of the type of keying used. 676 For interface or per-neighbor keying, the subverted node can now 677 introduce fake messages to its neighbors. This can be used in a 678 variety of ways, for example by changing the receiver address in the 679 Path message, or by generating fake Path messages. This allows path 680 states to be created on every RSVP router along any arbitrary path 681 through the RSVP domain. That in itself could result in a form of 682 Denial of Service by allowing exhaustion of some router resources 683 (e.g. memory). The subverted node could also generate fake Resv 684 messages upstream corresponding to valid Path states. In doing so, 685 the subverted node can reserve excessive amounts of bandwidth thereby 686 possibly performing a denial of service attack. 688 Group keying allows the additional abuse of sending fake RSVP 689 messages to any node in the RSVP domain, not just adjacent RSVP 690 nodes. However, in practice this can be achieved to a large extent 691 also with per neighbor or interface keys, as discussed above. 692 Therefore the impact of subverted nodes on the path is comparable for 693 all keying schemes discussed here (per-interface, per-neighbor, group 694 keys). 696 11. Acknowledgements 698 The authors would like to thank everybody who provided feedback on 699 this document. Specific thanks to Bob Briscoe, Hannes Tschofenig, 700 Brian Weis, Ran Atkinson and Kenneth G. Carlberg. 702 12. Changes to Previous Version 704 This section provides a change log. It will be removed in the final 705 document: 707 12.1. changes from behringer-00 to behringer-01 709 o New section "Applicability to Other Architectures and Protocols": 710 Goal is to clarify the scope of this document: The idea presented 711 here is also applicable to other architectures 712 (PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc. 713 o Clarified the scope of this document versus RFC4230 (in the 714 introduction, last paragraph). 715 o Added a section on "End Host Considerations". 716 o Expanded section 5.5 (RSVP Encryption) to clarify that GDOI 717 contains all necessary mechanisms to do RSVP encrpytion. 718 o Tried to clarify the "trust to do what?" question raised by Bob 719 Briscoe in a mail on 26 Jul 2007. See the section on trust model. 720 o Lots of small editorial changes (references, typos, figures, etc). 721 o Added an Acknowledgements section. 723 12.2. changes from behringer-01 to ietf-00 725 o various edits to make it clearer that draft-weis-gdoi-for-rsvp is 726 an example of how dynamic group keying could be achieved for RSVP 727 and not necessarily the recommended solution 729 12.3. changes from ietf-00 to ietf-01 731 o Significant re-structuring of the entire document, to improve the 732 flow, and provide more consistency in various sections. 733 o Moved the "Subverted RSVP nodes" discussion into the security 734 considerations section. 735 o Added a "summary" section. 736 o Complete re-write of the old section 5.5 (RSVP encryption), and 737 "promotion" to a separate section. 738 o Changed reference ID.weis-gdoi-for-rsvp to the new draft ID.weis- 739 gdoi-mac-tek 740 o in several places, explicitly mentioned "encryption" for RSVP (in 741 parallel to authentication). 742 o Various minor edits. 744 12.4. changes from ietf-01 to ietf-02 746 o Re-wrote and re-structured the section on IPsec (section 6). 747 o Re-wrote the section on RSVP-TE and GMPLS (section 5.2). 748 o Various editorial changes. 750 12.5. changes from ietf-02 to ietf-03 752 o Extension of section 6.3 (Using IPsec AH), to address comments 753 received from Ran Atkinson. Included a comparison of what AH 754 protects vs what the INTEGRITY object protects. 756 o Added section 6.5 on "tunnel mode with address preservation. 757 o Some minor edits. 759 12.6. changes from ietf-03 to ietf-04 761 o Added below table 1 in note (1) that "RSVP encryption with ESP and 762 RSVP authentication with AH work over non-RSVP nodes in 'Tunnel 763 Mode with Address Preservation'" 765 12.7. changes from ietf-04 to ietf-05 767 o Clarified in section 6.3 that IPsec AH also secures the immutable 768 fields of the outer header (comment from Bob Briscoe) 769 o Simplified in section 2 the comment that trust in group keying 770 extends to all members of the group (deleted the words on 771 "explicit and implicit"). (comment from Brian Weis) 772 o A number of corrections, re-wordings and clarifications in 773 response to Kenneth Carlberg's email from 2 June 2009 775 13. Informative References 777 [I-D.ietf-pcn-architecture] 778 Eardley, P., "Pre-Congestion Notification (PCN) 779 Architecture", draft-ietf-pcn-architecture-11 (work in 780 progress), April 2009. 782 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 783 Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP 784 Proxy Approaches", 785 draft-ietf-tsvwg-rsvp-proxy-approaches-07 (work in 786 progress), May 2009. 788 [I-D.weis-gdoi-mac-tek] 789 Weis, B. and S. Rowles, "GDOI Generic Message 790 Authentication Code Policy", draft-weis-gdoi-mac-tek-00 791 (work in progress), July 2008. 793 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 794 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 795 Functional Specification", RFC 2205, September 1997. 797 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 798 (IKE)", RFC 2409, November 1998. 800 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 801 Authentication", RFC 2747, January 2000. 803 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 804 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 805 RFC 3175, September 2001. 807 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 808 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 809 Tunnels", RFC 3209, December 2001. 811 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 812 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 813 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 815 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 816 Group Domain of Interpretation", RFC 3547, July 2003. 818 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 819 Signature Option", RFC 3562, July 2003. 821 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 822 Architecture", RFC 3740, March 2004. 824 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 825 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 826 May 2005. 828 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 829 Hierarchy with Generalized Multi-Protocol Label Switching 830 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 832 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 833 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 834 November 2005. 836 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 837 Properties", RFC 4230, December 2005. 839 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 840 December 2005. 842 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 843 RFC 4303, December 2005. 845 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 846 RFC 4306, December 2005. 848 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 849 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 850 RFC 4804, February 2007. 852 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 853 Davenport, "Generic Aggregate Resource ReSerVation 854 Protocol (RSVP) Reservations", RFC 4860, May 2007. 856 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 857 "Extensions to Resource Reservation Protocol - Traffic 858 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 859 Switched Paths (LSPs)", RFC 4875, May 2007. 861 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 862 Extensions to the Security Architecture for the Internet 863 Protocol", RFC 5374, November 2008. 865 Authors' Addresses 867 Michael H. Behringer 868 Cisco Systems Inc 869 Village d'Entreprises Green Side 870 400, Avenue Roumanille, Batiment T 3 871 Biot - Sophia Antipolis 06410 872 France 874 Email: mbehring@cisco.com 875 URI: http://www.cisco.com 877 Francois Le Faucheur 878 Cisco Systems Inc 879 Village d'Entreprises Green Side 880 400, Avenue Roumanille, Batiment T 3 881 Biot - Sophia Antipolis 06410 882 France 884 Email: flefauch@cisco.com 885 URI: http://www.cisco.com