idnits 2.17.1 draft-ietf-tsvwg-rsvp-security-groupkeying-03.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 (March 5, 2009) is 5532 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-pcn-architecture-09 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-rsvp-proxy-approaches-06 == 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 (~~), 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 Cisco Systems Inc 5 Expires: September 6, 2009 March 5, 2009 7 Applicability of Keying Methods for RSVP Security 8 draft-ietf-tsvwg-rsvp-security-groupkeying-03.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 September 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 . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . 15 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 13. Informative References . . . . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 92 1. Introduction and Problem Statement 94 The Resource reSerVation Protocol [RFC2205] allows hop-by-hop 95 authentication of RSVP neighbors, as specified in [RFC2747]. In this 96 mode, an integrity object is attached to each RSVP message to 97 transmit a keyed message digest. This message digest allows the 98 recipient to verify the authenticity of the RSVP node that sent the 99 message, and to validate the integrity of the message. Through the 100 inclusion of a sequence number in the scope of the digest, the digest 101 also offers replay protection. 103 [RFC2747] does not dictate how the key for the integrity operation is 104 derived. Currently, most implementations of RSVP use a statically 105 configured key, per interface or per neighbor. However, to manually 106 configure key per router pair across an entire network is 107 operationally hard, especially for key changes. Effectively, many 108 users of RSVP therefore resort to the same key throughout their RSVP 109 network, and change it rarely if ever, because of the operational 110 burden. [RFC3562] however recommends regular key changes, at least 111 every 90 days. 113 The present document discusses the various keying methods and their 114 applicability to different RSVP deployment environments, for both 115 message integrity and encryption. It does not recommend any 116 particular method or protocol (e.g., RSVP authentication versus IPsec 117 AH), but is meant as a comparative guideline to understand where each 118 RSVP keying method is best deployed, and its limitations. 119 Furthermore, it discusses how RSVP hop by hop authentication is 120 impacted in the presence of non-RSVP nodes, or subverted nodes, in 121 the reservation path. 123 The document "RSVP Security Properties" ([RFC4230]) provides an 124 overview of RSVP security, including RSVP Cryptographic 125 Authentication [RFC2747], but does not discuss key management. It 126 states that "RFC 2205 assumes that security associations are already 127 available". The present document focuses specifically on key 128 management with different key types, including group keys. Therefore 129 this document complements [RFC4230]. 131 2. The RSVP Hop-by-Hop Trust Model 133 Many protocol security mechanisms used in networks require and use 134 per peer authentication. Each hop authenticates its neighbor with a 135 shared key or certificate. This is also the model used for RSVP. 136 Trust in this model is transitive. Each RSVP node trusts explicitly 137 only its RSVP next hop peers, through the message digest contained in 138 the INTEGRITY object. The next hop RSVP speaker in turn trusts its 139 own peers and so on. See also the document "RSVP security 140 properties" [RFC4230] for more background. 142 The keys used for generating the RSVP messages can, in particular, be 143 group keys (for example distributed via GDOI [RFC3547], as discussed 144 in [I-D.weis-gdoi-mac-tek]). 146 The trust an RSVP node has to another RSVP node has an explicit and 147 an implicit component. Explicitly the node trusts the other node to 148 maintain the RSVP messages intact or confidential, depending on 149 whether authentication or encryption (or both) is used. This means 150 only that the message has not been altered or seen by another, non- 151 trusted node. Implicitly each node trusts each other node with which 152 it has a trust relationship established via the mechanisms here to 153 adhere to the protocol specifications laid out by the various 154 standards. Note that in any group keying scheme like GDOI a node 155 trusts explicitly as well as implicitly all the other members of the 156 group. 158 The RSVP protocol can operate in the presence of a non-RSVP router in 159 the path from the sender to the receiver. The non-RSVP hop will 160 ignore the RSVP message and just pass it along. The next RSVP node 161 can then process the RSVP message. For RSVP authentication or 162 encryption to work in this case, the key used for computing the RSVP 163 message digest needs to be shared by the two RSVP neighbors, even if 164 they are not IP neighbors. However, in the presence of non-RSVP 165 hops, while an RSVP node always knows the next IP hop before 166 forwarding an RSVP Message, it does not always know the RSVP next 167 hop. In fact, part of the role of a Path message is precisely to 168 discover the RSVP next hop (and to dynamically re-discover it when it 169 changes, for example because of a routing change). Thus, the 170 presence of non-RSVP hops impacts operation of RSVP authentication or 171 encryption and may influence the selection of keying approaches. 173 Figure 1 illustrates this scenario. R2 in this picture does not 174 participate in RSVP, the other nodes do. In this case, R2 will pass 175 on any RSVP messages unchanged, and will ignore them. 177 ----R3--- 178 / \ 179 sender----R1---R2(*) R4----receiver 180 \ / 181 ----R5--- 182 (*) Non-RSVP hop 184 Figure 1: A non-RSVP Node in the path 186 This creates a challenge for RSVP authentication and encryption. In 187 the presence of a non-RSVP hop, with some RSVP messages such as a 188 PATH message, an RSVP router does not know the RSVP next hop for that 189 message at the time of forwarding it. For example, in Figure 1, R1 190 knows that the next IP hop for a Path message addressed to the 191 receiver is R2, but it does necessarily not know if the RSVP next hop 192 is R3 or R5. 194 This means that per interface and per neighbor keys cannot easily be 195 used in the presence of non-RSVP routers on the path between senders 196 and receivers. 198 By contrast, group keying will naturally work in the presence of non- 199 RSVP routers. Referring back to Figure 1, with group keying, R1 200 would use the group key to sign a Path message addressed to the 201 receiver and forwards it to R2. Being a non-RSVP node, R2 and will 202 ignore and forward the Path message to R3 or R5 depending on the 203 current shortest path as determined by routing. Whether it is R3 or 204 R5, the RSVP router that receives the Path message will be able to 205 authenticate it successfully with the group key. 207 3. Applicability of Key Types for RSVP 209 3.1. Interface and neighbor based keys 211 Most current RSVP authentication implementations support interface 212 based RSVP keys. When the interface is point-to-point (and therefore 213 an RSVP router only has a single RSVP neighbor on each interface), 214 this is equivalent to neighbor based keys in the sense that a 215 different key is used for each neighbor. However, when the interface 216 is multipoint, all RSVP speakers on a given subnet have to share the 217 same key in this model, which makes it unsuitable for deployment 218 scenarios where different trust groups share a subnet, for example 219 Internet exchange points. In such a case, neighbor based keys are 220 required. 222 With neighbor based keys, an RSVP key is bound to an interface plus a 223 neighbor on that interface. It allows the distinction of different 224 trust groups on a single subnet. (Assuming that layer-2 security is 225 correctly implemented to prevent layer-2 attacks.) 227 Per interface and per neighbor keys can be used within a single 228 security domain. As mentioned above, per interface keys are only 229 applicable when all the nodes reachable on the specific interface 230 belong to the same security domain. 232 These key types can also be used between security domains, since they 233 are specific to a particular interface or neighbor. Again, interface 234 level keys can only be deployed safely when all the reachable 235 neighbors on the interface belong to the same security domain. 237 As discussed in the previous section, per neighbor and per interface 238 keys can not be used in the presence of non-RSVP hops. 240 3.2. Group keys 242 Here, all members of a group of RSVP nodes share the same key. This 243 implies that a node uses the same key regardless of the next RSVP hop 244 that will process the message (within the group of nodes sharing the 245 particular key). It also implies that a node will use the same key 246 on the receiving as on the sending side (when exchanging RSVP 247 messages within the group). 249 Group keys apply naturally to intra-domain RSVP authentication, since 250 all RSVP nodes implicitly trust each other. Using group keys, they 251 extend this trust to the group key server. This is represented in 252 Figure 2. 254 ......GKS1............. 255 : : : : : 256 : : : : : 257 source--R1--R2--R3-----destination 258 | | 259 |<-----domain 1----------------->| 261 Figure 2: Group Key Server within a single security domain 263 A single group key cannot normally be used to cover multiple security 264 domains however, because by definition the different domains do not 265 trust each other and would not be willing to trust the same group key 266 server. For a single group key to be used in several security 267 domains, there is a need for a single group key server, which is 268 trusted by both sides. While this is theoretically possible, in 269 practice it is unlikely that there is a single such entity trusted by 270 both domains. Figure 3 illustrates this setup. 272 ...............GKS1.................... 273 : : : : : : : : 274 : : : : : : : : 275 source--R1--R2--R3--------R4--R5--R6--destination 276 | | | | 277 |<-----domain 1--->| |<-------domain 2----->| 279 Figure 3: A Single Group Key Server across security domains 281 A more practical approach for RSVP operation across security domains, 282 is to use a separate group key server for each security domain, and 283 to use per interface or per neighbor authentication between the two 284 domains. Figure 4 shows this set-up. 286 ....GKS1...... ....GKS2......... 287 : : : : : : : : 288 : : : : : : : : 289 source--R1--R2--R3--------R4--R5--R6--destination 290 | | | | 291 |<-----domain 1--->| |<-------domain 2----->| 293 Figure 4: A group Key Server per security domain 295 As discussed in section 2, group keying can be used in the presence 296 of non-RSVP hops. 298 4. Key Provisioning Methods for RSVP 300 4.1. Static Key Provisioning 302 The simplest way to implement RSVP authentication is to use static, 303 preconfigured keys. Static keying can be used with interface based 304 keys, neighbor based keys or group keys. 306 However, such static key provisioning is expensive on the operational 307 side, since no secure automated mechanism can be used, and initial 308 provisioning as well as key updates require configuration. This 309 method is therefore mostly useful for small deployments, where key 310 changes can be carried out manually, or for deployments with 311 automated configuration tools which support key changes. 313 Static key provisioning is therefore not an ideal model in a large 314 network. 316 Often, the number of interconnection points across two domains where 317 RSVP is allowed to transit is relatively small and well controlled. 318 Also, the different domains may not be in a position to use an 319 infrastructure trusted by both domains to update keys on both sides. 320 Thus, manually configured keys may be applicable to inter-domain RSVP 321 authentication. 323 Since it is not feasible to carry out the key change at the exact 324 same time on both sides, some grace period needs to be implemented 325 during which an RSVP node will accept both the old and the new key. 326 Otherwise, RSVP operation would suffer interruptions. (Note that 327 also with dynamic keying approaches there can be a grace period where 328 two keys are valid at the same time; however, the grace period in 329 manual keying tends to be significantly longer than with dynamic key 330 rollover schemes.) 332 4.2. Dynamic Keying 334 4.2.1. Neighbor and Interface Based Key Negotiation 336 To avoid the problem of manual key provisioning and updates in static 337 key deployments, key negotiation between RSVP neighbors could be used 338 to derive either interface or neighbor based keys. However, existing 339 key negotiation protocols such as IKEv1 [RFC2409] or IKEv2 [RFC4306] 340 may not be appropriate in all environments because of the relative 341 complexity of the protocols and related operations. 343 4.2.2. Dynamic Group Key Distribution 345 With this approach, group keys are dynamically distributed among a 346 set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes 347 a mechanism to distribute group keys to a group of RSVP speakers, 348 using GDOI [RFC3547]. In this solution, a key server authenticates 349 each of the RSVP nodes independently, and then distributes a group 350 key to the entire group. 352 5. Specific Cases 354 5.1. RSVP Notify Messages 356 [RFC3473] introduces the Notify message and allows such Notify 357 messages to be sent in a non-hop-by-hop fashion. As discussed in the 358 Security Considerations section of [RFC3473], this can interfere with 359 RSVP's hop-by-hop integrity and authentication model. [RFC3473] 360 describes how standard IPsec based integrity and authentication can 361 be used to protect Notify messages. We observe that, alternatively, 362 in some environments, group keying may allow use of regular RSVP 363 authentication ([RFC2747]) for protection of non-hop-by-hop Notify 364 messages. For example, this may be applicable to controlled 365 environments where nodes invoking notification requests are known to 366 belong to the same key group as nodes generating Notify messages. 368 5.2. RSVP-TE and GMPLS 370 Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast 371 Reroute [RFC4090] deserves additional considerations. 373 With the facility backup method of Fast Reroute, a backup tunnel from 374 the Point of Local Repair (PLR) to the Merge Point (MP) is used to 375 protect Label Switched Paths (protected LSPs) against the failure of 376 a facility (e.g. a router) located between the PLR and the MP. 377 During the failure of the facility, the PLR redirects a protected LSP 378 inside the backup tunnel and as a result, the PLR and MP then need to 379 exchange RSVP control messages between each other (e.g. for the 380 maintenance of the protected LSP). Some of the RSVP messages between 381 the PLR and MP are sent over the backup tunnel (e.g. a Path message 382 from PLR to MP) while some are directly addressed to the RSVP node 383 (e.g. a Resv message from MP to PLR). During the rerouted period, 384 the PLR and the MP effectively become RSVP neighbors, while they may 385 not be directly connected to each other and thus do not behave as 386 RSVP neighbors in the absence of failure. This point is raised in 387 the Security Considerations section of [RFC4090] that says: "Note 388 that the facility backup method requires that a PLR and its selected 389 merge point trust RSVP messages received from each other." We 390 observe that such environments may benefit from group keying: a group 391 key can be used among a set of routers enabled for Fast Reroute 392 thereby easily ensuring that a PLR and MP authenticate messages from 393 each other, without requiring prior specific configuration of keys, 394 or activation of key update mechanism, for every possible pair of PLR 395 and MP. 397 Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS 398 boundaries (see [RFC4216]), the considerations presented above in 399 section 3.1 and 3.2 apply such that per interface or per neighbor 400 keys can be used between two RSVP neighbors in different ASes 401 (independently of the keying method used by the RSVP router to talk 402 to the RSVP routers in the same AS). 404 [RFC4875] specifies protocol extensions for support of Point-to- 405 Multipoint (P2MP) RSVP-TE. In its security considerations section, 406 [RFC4875] points out that RSVP message integrity mechanisms for hop- 407 by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling. 408 In turn, we observe that the considerations in this document on 409 keying methods apply equally to P2MP RSVP-TE for the hop-by-hop 410 signaling. 412 [RFC4206] defines LSP Hierarchy with GMPLS TE and uses non-hop-by-hop 413 signaling. Because it reuses LSP Hierarchy procedures for some of 414 its operations, P2MP RSVP-TE also uses non-hop-by-hop signaling. 415 Both LSP hierarchy and P2MP RSVP-TE rely on the security mechanisms 416 defined in [RFC3473] and [RFC4206] for non hop-by-hop RSVP-TE 417 signaling. We note that the observation in section 3.1 of this 418 document about use of group keying for protection of non-hop-by-hop 419 messages apply to protection of non-hop-by-hop signaling for LSP 420 Hierarchy and P2MP RSVP- TE. 422 6. Applicability of IPsec for RSVP 424 6.1. General Considerations Using IPsec 426 The discussions about the various keying methods in this document are 427 also applicable when using IPsec to protect RSVP. Note that 428 [RFC2747] states in section 1.2 that IPsec is not an optimal choice 429 to protect RSVP. The key argument is that an IPsec SA and an RSVP SA 430 are not based on the same parameters. However, when using group 431 keying, IPsec can be used to protect RSVP. The potential issues and 432 solutions using group keying are: 434 o [RFC2747] specifies in section 4.2, bullet 3, that both the key 435 identifier and the sending system address are used to uniquely 436 determine the key. In a group keying scenario it would be 437 necessary to either store a list of senders to do this, or to not 438 use the sending system address to determine the key. Both methods 439 are valid, and one of the two approaches must be chosen. The pros 440 and cons are beyond the scope of this document. 441 o Anti-replay protection in a group keying scenario requires some 442 changes to the way [RFC2747] defines anti-replay. Possible 443 solutions are discussed in detail in [I-D.weis-gdoi-mac-tek]). 444 For example, when using counter-based methods with various senders 445 in a single SA, the same counter may be received more than once, 446 this conflicts with [RFC2747], which states that each counter 447 value may only be accepted once. Time based approaches are a 448 solution for group keying scenarios. 450 The document "The Multicast Group Security Architecture" [RFC3740] 451 defines in detail a "Group Security Association" (GSA). This 452 definition is also applicable in the context discussed here, and 453 allows the use of IPsec for RSVP. The existing GDOI standard 454 [RFC3547] contains all relevant policy options to secure RSVP with 455 IPsec, and no extensions are necessary. An example GDOI policy would 456 be to encrypt all packets of the RSVP protocol itself (IP protocol 457 46). A router implementing GDOI and IPsec protocols is therefore 458 able to implement RSVP encryption. 460 6.2. Using IPsec ESP 462 In both tunnel mode and transport mode, ESP does not protect the 463 header (in tunnel mode the outer header). This is an issue with 464 group keying when using ESP to secure the RSVP packets: the packet 465 header could be modified by a man-in-the-middle attack, replacing the 466 destination address with another RSVP router in the network. This 467 router will receive the packet, use the group key to decrypt the 468 encapsulated packet, and then act on the RSVP packet. This way an 469 attacker cannot create new reservations or affect existing ones, but 470 he can "re-direct" reservations to parts of the network off the 471 actual reservation path, thereby potentially denying resources to 472 other applications on that part of the network. 474 6.3. Using IPsec AH 476 The INTEGRITY object defined by [RFC2747] provides integrity 477 protection for RSVP also in a group keying context, as discussed 478 above. IPsec AH [RFC4302] is an alternative method to provide 479 integrity 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). IPsec AH tunnel mode (transport mode 484 is not appliable, see section 6.5) protects the entire original IP 485 packet, including the IP header, IP options or extension headers, 486 plus the entire RSVP packet. The difference between the two schemes 487 in terms of covered fields is therefore whether the IP header and IP 488 options or extension headers are protected (as is the case with AH) 489 or not (as is the case with the INTEGRITY object). 491 As described in the next section, IPsec tunnel mode can not be 492 applied for RSVP traffic in the presence of non-RSVP nodes; therefore 493 the security associations in both cases, AH and INTEGRITY object, are 494 between the same RSVP neighbors. From a keying point of view both 495 approaches are therefore comparable. This document focuses on keying 496 approaches only; a general security comparison of these approaches is 497 outside the scope of this document. 499 6.4. Applicability of Tunnel Mode 501 IPsec tunnel mode encapsulates the original packet, prepending a new 502 IP tunnel header plus an ESP or AH sub-header. The entire original 503 packet plus the ESP/AH subheader is secured. In the case of ESP the 504 new, outer IP header however is not cryptographically secured in this 505 process. This leads to the problem described in Section 6.2. AH 506 tunnel mode also secures the outer header, and is therefore not 507 subject to these man-in-the-middle attacks. 509 Protecting RSVP packets with IPsec tunnel mode works with any of the 510 above described keying methods (interface, neighbor or group based), 511 as long as there are no non-RSVP nodes on the path. Note that for 512 RSVP messages to be visible and considered at each hop, such a tunnel 513 would not cross routers, but each RSVP node would establish a tunnel 514 with each of its peers, effectively leading to link protection. 516 In the presence of a non-RSVP hop, tunnel mode can not be applied, 517 because a router upstream a non-RSVP hop does not know the next RSVP 518 hop, and can thus not apply the correct tunnel header. This is 519 independent of the key type used. 521 6.5. Applicability of Transport Mode 523 IPsec transport mode, as defined in [RFC4303] is not suitable for 524 securing RSVP Path messages, since those messages preserve the 525 original source and destination. [RFC4303] states explicitly that 526 "the use of transport mode by an intermediate system (e.g., a 527 security gateway) is permitted only when applied to packets whose 528 source address (for outbound packets) or destination address (for 529 inbound packets) is an address belonging to the intermediate system 530 itself." This would not be the case for RSVP Path messages. 532 6.6. Applicability of Tunnel Mode with Address Preservation 534 The document "Multicast Extensions to the Security Architecture for 535 the Internet Protocol" [RFC5374] defines in section 3.1 a new tunnel 536 mode: Tunnel mode with address preservation. This mode copies the 537 destination and optionally the source address from the inner header 538 to the outer header. Therefore the encapsulated packet will have the 539 same destination address as the original packet, and be normally 540 subject to the same routing decisions. While [RFC5374] is focusing 541 on multicast environments, tunnel mode with address preservation can 542 be used also to protect unicast traffic in conjunction with group 543 keying. 545 Tunnel mode with address preservation, in conjunction with group 546 keying, allows the use of IPsec AH or ESP for protection of RSVP even 547 in cases where non-RSVP nodes have to be traversed. This is because 548 it allows routing of the IPsec protected packet through the non-RSVP 549 nodes in the same way as if it was not IPsec protected. 551 7. End Host Considerations 553 Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches] 554 are used, RSVP signaling is controlled by end systems and not 555 routers. As discussed in [RFC4230], RSVP allows both user-based 556 security and host-based security. User-based authentication aims at 557 "providing policy based admission control mechanism based on user 558 identities or application." To identify the user or the application, 559 a policy element called AUTH_DATA, which is contained in the 560 POLICY_DATA object, is created by the RSVP daemon at the user's host 561 and transmitted inside the RSVP message. This way, a user may 562 authenticate to the Policy Decision Point (or directly to the first 563 hop router). Host-based security relies on the same mechanisms as 564 between routers (i.e. INTEGRITY object) as specified in [RFC2747]. 566 For host-based security, interface or neighbor based keys may be 567 used, however, key management with pre-shared keys can be difficult 568 in a large scale deployment, as described in section 4. In principle 569 an end host can also be part of a group key scheme, such as GDOI. If 570 the end systems are part of the same zone of trust as the network 571 itself, group keying can be extended to include the end systems. If 572 the end systems and the network are in different zones of trust, 573 group keying cannot be used. 575 8. Applicability to Other Architectures and Protocols 577 While, so far, this document only discusses RSVP security assuming 578 the traditional RSVP model as defined by [RFC2205] and [RFC2747], the 579 analysis is also applicable to other RSVP deployment models as well 580 as to similar protocols: 582 o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This 583 scheme defines aggregation of individual RSVP reservations, and 584 discusses use of RSVP authentication for the signaling messages. 585 Group keying is applicable to this scheme, particularly when 586 automatic Deaggregator discovery is used, since in that case, the 587 Aggregator does not know ahead of time which Deaggregator will 588 intercept the initial end-to-end RSVP Path message. 589 o Generic Aggregate Resource ReSerVation Protocol (RSVP) 590 Reservations [RFC4860]: This document also discusses aggregation 591 of individual RSVP reservations. Here again, group keying applies 592 and is mentioned in the Security Considerations section. 593 o Aggregation of Resource ReSerVation Protocol (RSVP) Reservations 594 over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): This scheme also 595 defines a form of aggregation of RSVP reservation but this time 596 over MPLS TE Tunnels. Similarly, group keying may be used in such 597 an environment. 598 o Pre-Congestion Notification (PCN): [I-D.ietf-pcn-architecture] 599 defines an architecture for flow admission and termination based 600 on aggregated pre-congestion information. One deployment model 601 for this architecture is based on IntServ over DiffServ: the 602 DiffServ region is PCN-enabled, RSVP signalling is used end-to-end 603 but the PCN-domain is a single RSVP hop, i.e. only the PCN- 604 boundary-nodes process RSVP messages. In this scenario, RSVP 605 authentication may be required among PCN-boundary-nodes and the 606 considerations about keying approaches discussed earlier in this 607 document apply. In particular, group keying may facilitate 608 operations since the ingress PCN-boundary-node does not 609 necessarily know ahead of time which Egress PCN-boundary-node will 610 intercept and process the initial end-to-end Path message. Note 611 that from the viewpoint of securing end-to-end RSVP, there are a 612 lot of similarities in scenarios involving RSVP Aggregation over 613 aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP 614 Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP 615 (Aggregation) over PCN ingress-egress aggregates. 617 9. Summary 619 The following table summarizes the various approaches for RSVP 620 keying, and their applicability to various RSVP scenarios. In 621 particular, such keying can be used for RSVP authentication (e.g., 622 using RSVP authentication or IPsec AH) and/ or for RSVP encryption 623 (e.g., using IPsec ESP in tunnel mode). 625 +-----------------------------+--------------------+----------------+ 626 | | Neighbor/interface | Group keys | 627 | | based keys | | 628 +-----------------------------+--------------------+----------------+ 629 | Works intra-domain | Yes | Yes | 630 | Works inter-domain | Yes | No | 631 | Works over non-RSVP hops | No | Yes (1) | 632 | Dynamic keying | Yes (IKE) | Yes (eg GDOI) | 633 +-----------------------------+--------------------+----------------+ 635 Table 1: Overview of keying approaches and their applicability 637 (1): RSVP authentication with group keys works over non-RSVP nodes; 638 RSVP encryption with IPsec ESP Tunnel mode does not. 640 We also make the following observations: 642 o All key types can be used statically, or with dynamic key 643 negotiation. This impacts the managability of the solution, but 644 not the applicability itself. 645 o For encryption of RSVP messages IPsec ESP in tunnel mode can be 646 used. There is however a security concern, see Section 6.2. 647 o There are some special cases in RSVP, like non-RSVP hosts, the 648 "Notify" message (as discussed in section 5.1), the various RSVP 649 deployment models discussed in Section 8 and MPLS Traffic 650 Engineering and GMPLS discussed in section 5.2 , which would 651 benefit from a group keying approach. 653 10. Security Considerations 655 This entire document discusses RSVP security; this section describes 656 a specific security considerations relating to subverted RSVP nodes 658 10.1. Subverted RSVP Nodes 660 A subverted node is defined here as an untrusted node, for example 661 because an intruder has gained control over it. Since RSVP 662 authentication is hop-by-hop and not end-to-end, a subverted node in 663 the path breaks the chain of trust. This is to a large extent 664 independent of the type of keying used. 666 For interface or per-neighbor keying, the subverted node can now 667 introduce fake messages to its neighbors. This can be used in a 668 variety of ways, for example by changing the receiver address in the 669 Path message, or by generating fake Path messages. This allows path 670 states to be created on every RSVP router along any arbitrary path 671 through the RSVP domain. That in itself could result in a form of 672 Denial of Service by allowing exhaustion of some router resources 673 (e.g. memory). The subverted node could also generate fake Resv 674 messages upstream corresponding to valid Path states. In doing so, 675 the subverted node can reserve excessive amounts of bandwidth thereby 676 possibly performing a denial of service attack. 678 Group keying allows the additional abuse of sending fake RSVP 679 messages to any node in the RSVP domain, not just adjacent RSVP 680 nodes. However, in practice this can be achieved to a large extent 681 also with per neighbor or interface keys, as discussed above. 682 Therefore the impact of subverted nodes on the path is comparable, 683 independently whether per-interface, per-neighbor or group keys are 684 used. 686 11. Acknowledgements 688 The authors would like to thank everybody who provided feedback on 689 this document. Specific thanks to Bob Briscoe, Hannes Tschofenig, 690 Brian Weis and Ran Atkinson . 692 12. Changes to Previous Version 694 This section provides a change log. It will be removed in the final 695 document: 697 12.1. changes from behringer-00 to behringer-01 699 o New section "Applicability to Other Architectures and Protocols": 700 Goal is to clarify the scope of this document: The idea presented 701 here is also applicable to other architectures 702 (PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc. 704 o Clarified the scope of this document versus RFC4230 (in the 705 introduction, last paragraph). 706 o Added a section on "End Host Considerations". 707 o Expanded section 5.5 (RSVP Encryption) to clarify that GDOI 708 contains all necessary mechanisms to do RSVP encrpytion. 709 o Tried to clarify the "trust to do what?" question raised by Bob 710 Briscoe in a mail on 26 Jul 2007. See the section on trust model. 711 o Lots of small editorial changes (references, typos, figures, etc). 712 o Added an Acknowledgements section. 714 12.2. changes from behringer-01 to ietf-00 716 o various edits to make it clearer that draft-weis-gdoi-for-rsvp is 717 an example of how dynamic group keying could be achieved for RSVP 718 and not necessarily the recommended solution 720 12.3. changes from ietf-00 to ietf-01 722 o Significant re-structuring of the entire document, to improve the 723 flow, and provide more consistency in various sections. 724 o Moved the "Subverted RSVP nodes" discussion into the security 725 considerations section. 726 o Added a "summary" section. 727 o Complete re-write of the old section 5.5 (RSVP encryption), and 728 "promotion" to a separate section. 729 o Changed reference ID.weis-gdoi-for-rsvp to the new draft ID.weis- 730 gdoi-mac-tek 731 o in several places, explicitly mentioned "encryption" for RSVP (in 732 parallel to authentication). 733 o Various minor edits. 735 12.4. changes from ietf-01 to ietf-02 737 o Re-wrote and re-structured the section on IPsec (section 6). 738 o Re-wrote the section on RSVP-TE and GMPLS (section 5.2). 739 o Various editorial changes. 741 12.5. changes from ietf-02 to ietf-03 743 o Extension of section 6.3 (Using IPsec AH), to address comments 744 received from Ran Atkinson. Included a comparison of what AH 745 protects vs what the INTEGRITY object protects. 746 o Added section 6.5 on "tunnel mode with address preservation. 747 o Some minor edits. 749 13. Informative References 751 [I-D.ietf-pcn-architecture] 752 Eardley, P., "Pre-Congestion Notification (PCN) 753 Architecture", draft-ietf-pcn-architecture-09 (work in 754 progress), January 2009. 756 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 757 Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP 758 Proxy Approaches", 759 draft-ietf-tsvwg-rsvp-proxy-approaches-06 (work in 760 progress), October 2008. 762 [I-D.weis-gdoi-mac-tek] 763 Weis, B. and S. Rowles, "GDOI Generic Message 764 Authentication Code Policy", draft-weis-gdoi-mac-tek-00 765 (work in progress), July 2008. 767 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 768 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 769 Functional Specification", RFC 2205, September 1997. 771 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 772 (IKE)", RFC 2409, November 1998. 774 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 775 Authentication", RFC 2747, January 2000. 777 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 778 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 779 RFC 3175, September 2001. 781 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 782 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 783 Tunnels", RFC 3209, December 2001. 785 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 786 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 787 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 789 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 790 Group Domain of Interpretation", RFC 3547, July 2003. 792 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 793 Signature Option", RFC 3562, July 2003. 795 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 796 Architecture", RFC 3740, March 2004. 798 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 799 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 800 May 2005. 802 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 803 Hierarchy with Generalized Multi-Protocol Label Switching 804 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 806 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 807 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 808 November 2005. 810 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 811 Properties", RFC 4230, December 2005. 813 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 814 December 2005. 816 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 817 RFC 4303, December 2005. 819 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 820 RFC 4306, December 2005. 822 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 823 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 824 RFC 4804, February 2007. 826 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 827 Davenport, "Generic Aggregate Resource ReSerVation 828 Protocol (RSVP) Reservations", RFC 4860, May 2007. 830 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 831 "Extensions to Resource Reservation Protocol - Traffic 832 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 833 Switched Paths (LSPs)", RFC 4875, May 2007. 835 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 836 Extensions to the Security Architecture for the Internet 837 Protocol", RFC 5374, November 2008. 839 Authors' Addresses 841 Michael H. Behringer 842 Cisco Systems Inc 843 Village d'Entreprises Green Side 844 400, Avenue Roumanille, Batiment T 3 845 Biot - Sophia Antipolis 06410 846 France 848 Email: mbehring@cisco.com 849 URI: http://www.cisco.com 851 Francois Le Faucheur 852 Cisco Systems Inc 853 Village d'Entreprises Green Side 854 400, Avenue Roumanille, Batiment T 3 855 Biot - Sophia Antipolis 06410 856 France 858 Email: flefauch@cisco.com 859 URI: http://www.cisco.com