idnits 2.17.1 draft-ietf-tsvwg-rsvp-security-groupkeying-04.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 24, 2009) is 5511 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-10 == 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 25, 2009 March 24, 2009 7 Applicability of Keying Methods for RSVP Security 8 draft-ietf-tsvwg-rsvp-security-groupkeying-04.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 25, 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 12.6. changes from ietf-03 to ietf-04 . . . . . . . . . . . . . 17 90 13. Informative References . . . . . . . . . . . . . . . . . . . . 17 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 93 1. Introduction and Problem Statement 95 The Resource reSerVation Protocol [RFC2205] allows hop-by-hop 96 authentication of RSVP neighbors, as specified in [RFC2747]. In this 97 mode, an integrity object is attached to each RSVP message to 98 transmit a keyed message digest. This message digest allows the 99 recipient to verify the authenticity of the RSVP node that sent the 100 message, and to validate the integrity of the message. Through the 101 inclusion of a sequence number in the scope of the digest, the digest 102 also offers replay protection. 104 [RFC2747] does not dictate how the key for the integrity operation is 105 derived. Currently, most implementations of RSVP use a statically 106 configured key, per interface or per neighbor. However, to manually 107 configure key per router pair across an entire network is 108 operationally hard, especially for key changes. Effectively, many 109 users of RSVP therefore resort to the same key throughout their RSVP 110 network, and change it rarely if ever, because of the operational 111 burden. [RFC3562] however recommends regular key changes, at least 112 every 90 days. 114 The present document discusses the various keying methods and their 115 applicability to different RSVP deployment environments, for both 116 message integrity and encryption. It does not recommend any 117 particular method or protocol (e.g., RSVP authentication versus IPsec 118 AH), but is meant as a comparative guideline to understand where each 119 RSVP keying method is best deployed, and its limitations. 120 Furthermore, it discusses how RSVP hop by hop authentication is 121 impacted in the presence of non-RSVP nodes, or subverted nodes, in 122 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 generating the 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]). 147 The trust an RSVP node has to another RSVP node has an explicit and 148 an implicit component. Explicitly the node trusts the other node to 149 maintain the RSVP messages intact or confidential, depending on 150 whether authentication or encryption (or both) is used. This means 151 only that the message has not been altered or seen by another, non- 152 trusted node. Implicitly each node trusts each other node with which 153 it has a trust relationship established via the mechanisms here to 154 adhere to the protocol specifications laid out by the various 155 standards. Note that in any group keying scheme like GDOI a node 156 trusts explicitly as well as implicitly all the other members of the 157 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 and 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 subnet. (Assuming that layer-2 security is 226 correctly implemented to prevent layer-2 attacks.) 228 Per interface and per neighbor keys can be used within a single 229 security domain. As mentioned above, per interface keys are only 230 applicable when all the nodes reachable on the specific interface 231 belong to the same security domain. 233 These key types can also be used between security domains, since they 234 are specific to a particular interface or neighbor. Again, interface 235 level keys can only be deployed safely when all the reachable 236 neighbors on the interface belong to the same security domain. 238 As discussed in the previous section, per neighbor and per interface 239 keys can not be used in the presence of non-RSVP hops. 241 3.2. Group keys 243 Here, all members of a group of RSVP nodes share the same key. This 244 implies that a node uses the same key regardless of the next RSVP hop 245 that will process the message (within the group of nodes sharing the 246 particular key). It also implies that a node will use the same key 247 on the receiving as on the sending side (when exchanging RSVP 248 messages within the group). 250 Group keys apply naturally to intra-domain RSVP authentication, since 251 all RSVP nodes implicitly trust each other. Using group keys, they 252 extend this trust to the group key server. This is represented in 253 Figure 2. 255 ......GKS1............. 256 : : : : : 257 : : : : : 258 source--R1--R2--R3-----destination 259 | | 260 |<-----domain 1----------------->| 262 Figure 2: Group Key Server within a single security domain 264 A single group key cannot normally be used to cover multiple security 265 domains however, because by definition the different domains do not 266 trust each other and would not be willing to trust the same group key 267 server. For a single group key to be used in several security 268 domains, there is a need for a single group key server, which is 269 trusted by both sides. While this is theoretically possible, in 270 practice it is unlikely that there is a single such entity trusted by 271 both domains. Figure 3 illustrates this setup. 273 ...............GKS1.................... 274 : : : : : : : : 275 : : : : : : : : 276 source--R1--R2--R3--------R4--R5--R6--destination 277 | | | | 278 |<-----domain 1--->| |<-------domain 2----->| 280 Figure 3: A Single Group Key Server across security domains 282 A more practical approach for RSVP operation across security domains, 283 is to use a separate group key server for each security domain, and 284 to use per interface or per neighbor authentication between the two 285 domains. Figure 4 shows this set-up. 287 ....GKS1...... ....GKS2......... 288 : : : : : : : : 289 : : : : : : : : 290 source--R1--R2--R3--------R4--R5--R6--destination 291 | | | | 292 |<-----domain 1--->| |<-------domain 2----->| 294 Figure 4: A group Key Server per security domain 296 As discussed in section 2, group keying can be used in the presence 297 of non-RSVP hops. 299 4. Key Provisioning Methods for RSVP 301 4.1. Static Key Provisioning 303 The simplest way to implement RSVP authentication is to use static, 304 preconfigured keys. Static keying can be used with interface based 305 keys, neighbor based keys or group keys. 307 However, such static key provisioning is expensive on the operational 308 side, since no secure automated mechanism can be used, and initial 309 provisioning as well as key updates require configuration. This 310 method is therefore mostly useful for small deployments, where key 311 changes can be carried out manually, or for deployments with 312 automated configuration tools which support key changes. 314 Static key provisioning is therefore not an ideal model in a large 315 network. 317 Often, the number of interconnection points across two domains where 318 RSVP is allowed to transit is relatively small and well controlled. 319 Also, the different domains may not be in a position to use an 320 infrastructure trusted by both domains to update keys on both sides. 321 Thus, manually configured keys may be applicable to inter-domain RSVP 322 authentication. 324 Since it is not feasible to carry out the key change at the exact 325 same time on both sides, some grace period needs to be implemented 326 during which an RSVP node will accept both the old and the new key. 327 Otherwise, RSVP operation would suffer interruptions. (Note that 328 also with dynamic keying approaches there can be a grace period where 329 two keys are valid at the same time; however, the grace period in 330 manual keying tends to be significantly longer than with dynamic key 331 rollover schemes.) 333 4.2. Dynamic Keying 335 4.2.1. Neighbor and Interface Based Key Negotiation 337 To avoid the problem of manual key provisioning and updates in static 338 key deployments, key negotiation between RSVP neighbors could be used 339 to derive either interface or neighbor based keys. However, existing 340 key negotiation protocols such as IKEv1 [RFC2409] or IKEv2 [RFC4306] 341 may not be appropriate in all environments because of the relative 342 complexity of the protocols and related operations. 344 4.2.2. Dynamic Group Key Distribution 346 With this approach, group keys are dynamically distributed among a 347 set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes 348 a mechanism to distribute group keys to a group of RSVP speakers, 349 using GDOI [RFC3547]. In this solution, a key server authenticates 350 each of the RSVP nodes independently, and then distributes a group 351 key to the entire group. 353 5. Specific Cases 355 5.1. RSVP Notify Messages 357 [RFC3473] introduces the Notify message and allows such Notify 358 messages to be sent in a non-hop-by-hop fashion. As discussed in the 359 Security Considerations section of [RFC3473], this can interfere with 360 RSVP's hop-by-hop integrity and authentication model. [RFC3473] 361 describes how standard IPsec based integrity and authentication can 362 be used to protect Notify messages. We observe that, alternatively, 363 in some environments, group keying may allow use of regular RSVP 364 authentication ([RFC2747]) for protection of non-hop-by-hop Notify 365 messages. For example, this may be applicable to controlled 366 environments where nodes invoking notification requests are known to 367 belong to the same key group as nodes generating Notify messages. 369 5.2. RSVP-TE and GMPLS 371 Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast 372 Reroute [RFC4090] deserves additional considerations. 374 With the facility backup method of Fast Reroute, a backup tunnel from 375 the Point of Local Repair (PLR) to the Merge Point (MP) is used to 376 protect Label Switched Paths (protected LSPs) against the failure of 377 a facility (e.g. a router) located between the PLR and the MP. 378 During the failure of the facility, the PLR redirects a protected LSP 379 inside the backup tunnel and as a result, the PLR and MP then need to 380 exchange RSVP control messages between each other (e.g. for the 381 maintenance of the protected LSP). Some of the RSVP messages between 382 the PLR and MP are sent over the backup tunnel (e.g. a Path message 383 from PLR to MP) while some are directly addressed to the RSVP node 384 (e.g. a Resv message from MP to PLR). During the rerouted period, 385 the PLR and the MP effectively become RSVP neighbors, while they may 386 not be directly connected to each other and thus do not behave as 387 RSVP neighbors in the absence of failure. This point is raised in 388 the Security Considerations section of [RFC4090] that says: "Note 389 that the facility backup method requires that a PLR and its selected 390 merge point trust RSVP messages received from each other." We 391 observe that such environments may benefit from group keying: a group 392 key can be used among a set of routers enabled for Fast Reroute 393 thereby easily ensuring that a PLR and MP authenticate messages from 394 each other, without requiring prior specific configuration of keys, 395 or activation of key update mechanism, for every possible pair of PLR 396 and MP. 398 Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS 399 boundaries (see [RFC4216]), the considerations presented above in 400 section 3.1 and 3.2 apply such that per interface or per neighbor 401 keys can be used between two RSVP neighbors in different ASes 402 (independently of the keying method used by the RSVP router to talk 403 to the RSVP routers in the same AS). 405 [RFC4875] specifies protocol extensions for support of Point-to- 406 Multipoint (P2MP) RSVP-TE. In its security considerations section, 407 [RFC4875] points out that RSVP message integrity mechanisms for hop- 408 by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling. 409 In turn, we observe that the considerations in this document on 410 keying methods apply equally to P2MP RSVP-TE for the hop-by-hop 411 signaling. 413 [RFC4206] defines LSP Hierarchy with GMPLS TE and uses non-hop-by-hop 414 signaling. Because it reuses LSP Hierarchy procedures for some of 415 its operations, P2MP RSVP-TE also uses non-hop-by-hop signaling. 416 Both LSP hierarchy and P2MP RSVP-TE rely on the security mechanisms 417 defined in [RFC3473] and [RFC4206] for non hop-by-hop RSVP-TE 418 signaling. We note that the observation in section 3.1 of this 419 document about use of group keying for protection of non-hop-by-hop 420 messages apply to protection of non-hop-by-hop signaling for LSP 421 Hierarchy and P2MP RSVP- TE. 423 6. Applicability of IPsec for RSVP 425 6.1. General Considerations Using IPsec 427 The discussions about the various keying methods in this document are 428 also applicable when using IPsec to protect RSVP. Note that 429 [RFC2747] states in section 1.2 that IPsec is not an optimal choice 430 to protect RSVP. The key argument is that an IPsec SA and an RSVP SA 431 are not based on the same parameters. However, when using group 432 keying, IPsec can be used to protect RSVP. The potential issues and 433 solutions using group keying are: 435 o [RFC2747] specifies in section 4.2, bullet 3, that both the key 436 identifier and the sending system address are used to uniquely 437 determine the key. In a group keying scenario it would be 438 necessary to either store a list of senders to do this, or to not 439 use the sending system address to determine the key. Both methods 440 are valid, and one of the two approaches must be chosen. The pros 441 and cons are beyond the scope of this document. 442 o Anti-replay protection in a group keying scenario requires some 443 changes to the way [RFC2747] defines anti-replay. Possible 444 solutions are discussed in detail in [I-D.weis-gdoi-mac-tek]). 445 For example, when using counter-based methods with various senders 446 in a single SA, the same counter may be received more than once, 447 this conflicts with [RFC2747], which states that each counter 448 value may only be accepted once. Time based approaches are a 449 solution for group keying scenarios. 451 The document "The Multicast Group Security Architecture" [RFC3740] 452 defines in detail a "Group Security Association" (GSA). This 453 definition is also applicable in the context discussed here, and 454 allows the use of IPsec for RSVP. The existing GDOI standard 455 [RFC3547] contains all relevant policy options to secure RSVP with 456 IPsec, and no extensions are necessary. An example GDOI policy would 457 be to encrypt all packets of the RSVP protocol itself (IP protocol 458 46). A router implementing GDOI and IPsec protocols is therefore 459 able to implement RSVP encryption. 461 6.2. Using IPsec ESP 463 In both tunnel mode and transport mode, ESP does not protect the 464 header (in tunnel mode the outer header). This is an issue with 465 group keying when using ESP to secure the RSVP packets: the packet 466 header could be modified by a man-in-the-middle attack, replacing the 467 destination address with another RSVP router in the network. This 468 router will receive the packet, use the group key to decrypt the 469 encapsulated packet, and then act on the RSVP packet. This way an 470 attacker cannot create new reservations or affect existing ones, but 471 he can "re-direct" reservations to parts of the network off the 472 actual reservation path, thereby potentially denying resources to 473 other applications on that part of the network. 475 6.3. Using IPsec AH 477 The INTEGRITY object defined by [RFC2747] provides integrity 478 protection for RSVP also in a group keying context, as discussed 479 above. IPsec AH [RFC4302] is an alternative method to provide 480 integrity protection for RSVP packets. 482 The RSVP INTEGRITY object protects the entire RSVP message, but does 483 not protect the IP header of the packet nor the IP options (in IPv4) 484 or extension headers (in IPv6). IPsec AH tunnel mode (transport mode 485 is not appliable, see section 6.5) protects the entire original IP 486 packet, including the IP header, IP options or extension headers, 487 plus the entire RSVP packet. The difference between the two schemes 488 in terms of covered fields is therefore whether the IP header and IP 489 options or extension headers are protected (as is the case with AH) 490 or not (as is the case with the INTEGRITY object). 492 As described in the next section, IPsec tunnel mode can not be 493 applied for RSVP traffic in the presence of non-RSVP nodes; therefore 494 the security associations in both cases, AH and INTEGRITY object, are 495 between the same RSVP neighbors. From a keying point of view both 496 approaches are therefore comparable. This document focuses on keying 497 approaches only; a general security comparison of these approaches is 498 outside the scope of this document. 500 6.4. Applicability of Tunnel Mode 502 IPsec tunnel mode encapsulates the original packet, prepending a new 503 IP tunnel header plus an ESP or AH sub-header. The entire original 504 packet plus the ESP/AH subheader is secured. In the case of ESP the 505 new, outer IP header however is not cryptographically secured in this 506 process. This leads to the problem described in Section 6.2. AH 507 tunnel mode also secures the outer header, and is therefore not 508 subject to these man-in-the-middle attacks. 510 Protecting RSVP packets with IPsec tunnel mode works with any of the 511 above described keying methods (interface, neighbor or group based), 512 as long as there are no non-RSVP nodes on the path. Note that for 513 RSVP messages to be visible and considered at each hop, such a tunnel 514 would not cross routers, but each RSVP node would establish a tunnel 515 with each of its peers, effectively leading to link protection. 517 In the presence of a non-RSVP hop, tunnel mode can not be applied, 518 because a router upstream a non-RSVP hop does not know the next RSVP 519 hop, and can thus not apply the correct tunnel header. This is 520 independent of the key type used. 522 6.5. Applicability of Transport Mode 524 IPsec transport mode, as defined in [RFC4303] is not suitable for 525 securing RSVP Path messages, since those messages preserve the 526 original source and destination. [RFC4303] states explicitly that 527 "the use of transport mode by an intermediate system (e.g., a 528 security gateway) is permitted only when applied to packets whose 529 source address (for outbound packets) or destination address (for 530 inbound packets) is an address belonging to the intermediate system 531 itself." This would not be the case for RSVP Path messages. 533 6.6. Applicability of Tunnel Mode with Address Preservation 535 The document "Multicast Extensions to the Security Architecture for 536 the Internet Protocol" [RFC5374] defines in section 3.1 a new tunnel 537 mode: Tunnel mode with address preservation. This mode copies the 538 destination and optionally the source address from the inner header 539 to the outer header. Therefore the encapsulated packet will have the 540 same destination address as the original packet, and be normally 541 subject to the same routing decisions. While [RFC5374] is focusing 542 on multicast environments, tunnel mode with address preservation can 543 be used also to protect unicast traffic in conjunction with group 544 keying. 546 Tunnel mode with address preservation, in conjunction with group 547 keying, allows the use of IPsec AH or ESP for protection of RSVP even 548 in cases where non-RSVP nodes have to be traversed. This is because 549 it allows routing of the IPsec protected packet through the non-RSVP 550 nodes in the same way as if it was not IPsec protected. 552 7. End Host Considerations 554 Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches] 555 are used, RSVP signaling is controlled by end systems and not 556 routers. As discussed in [RFC4230], RSVP allows both user-based 557 security and host-based security. User-based authentication aims at 558 "providing policy based admission control mechanism based on user 559 identities or application." To identify the user or the application, 560 a policy element called AUTH_DATA, which is contained in the 561 POLICY_DATA object, is created by the RSVP daemon at the user's host 562 and transmitted inside the RSVP message. This way, a user may 563 authenticate to the Policy Decision Point (or directly to the first 564 hop router). Host-based security relies on the same mechanisms as 565 between routers (i.e. INTEGRITY object) as specified in [RFC2747]. 567 For host-based security, interface or neighbor based keys may be 568 used, however, key management with pre-shared keys can be difficult 569 in a large scale deployment, as described in section 4. In principle 570 an end host can also be part of a group key scheme, such as GDOI. If 571 the end systems are part of the same zone of trust as the network 572 itself, group keying can be extended to include the end systems. If 573 the end systems and the network are in different zones of trust, 574 group keying cannot be used. 576 8. Applicability to Other Architectures and Protocols 578 While, so far, this document only discusses RSVP security assuming 579 the traditional RSVP model as defined by [RFC2205] and [RFC2747], the 580 analysis is also applicable to other RSVP deployment models as well 581 as to similar protocols: 583 o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This 584 scheme defines aggregation of individual RSVP reservations, and 585 discusses use of RSVP authentication for the signaling messages. 586 Group keying is applicable to this scheme, particularly when 587 automatic Deaggregator discovery is used, since in that case, the 588 Aggregator does not know ahead of time which Deaggregator will 589 intercept the initial end-to-end RSVP Path message. 590 o Generic Aggregate Resource ReSerVation Protocol (RSVP) 591 Reservations [RFC4860]: This document also discusses aggregation 592 of individual RSVP reservations. Here again, group keying applies 593 and is mentioned in the Security Considerations section. 594 o Aggregation of Resource ReSerVation Protocol (RSVP) Reservations 595 over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): This scheme also 596 defines a form of aggregation of RSVP reservation but this time 597 over MPLS TE Tunnels. Similarly, group keying may be used in such 598 an environment. 599 o Pre-Congestion Notification (PCN): [I-D.ietf-pcn-architecture] 600 defines an architecture for flow admission and termination based 601 on aggregated pre-congestion information. One deployment model 602 for this architecture is based on IntServ over DiffServ: the 603 DiffServ region is PCN-enabled, RSVP signalling is used end-to-end 604 but the PCN-domain is a single RSVP hop, i.e. only the PCN- 605 boundary-nodes process RSVP messages. In this scenario, RSVP 606 authentication may be required among PCN-boundary-nodes and the 607 considerations about keying approaches discussed earlier in this 608 document apply. In particular, group keying may facilitate 609 operations since the ingress PCN-boundary-node does not 610 necessarily know ahead of time which Egress PCN-boundary-node will 611 intercept and process the initial end-to-end Path message. Note 612 that from the viewpoint of securing end-to-end RSVP, there are a 613 lot of similarities in scenarios involving RSVP Aggregation over 614 aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP 615 Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP 616 (Aggregation) over PCN ingress-egress aggregates. 618 9. Summary 620 The following table summarizes the various approaches for RSVP 621 keying, and their applicability to various RSVP scenarios. In 622 particular, such keying can be used for RSVP authentication (e.g., 623 using RSVP authentication or IPsec AH) and/ or for RSVP encryption 624 (e.g., using IPsec ESP in tunnel mode). 626 +-----------------------------+--------------------+----------------+ 627 | | Neighbor/interface | Group keys | 628 | | based keys | | 629 +-----------------------------+--------------------+----------------+ 630 | Works intra-domain | Yes | Yes | 631 | Works inter-domain | Yes | No | 632 | Works over non-RSVP hops | No | Yes (1) | 633 | Dynamic keying | Yes (IKE) | Yes (eg GDOI) | 634 +-----------------------------+--------------------+----------------+ 636 Table 1: Overview of keying approaches and their applicability 638 (1): RSVP integrity with group keys works over non-RSVP nodes; RSVP 639 encryption with ESP and RSVP authentication with AH work over non- 640 RSVP nodes in 'Tunnel Mode with Address Preservation'; RSVP 641 encryption with ESP & RSVP authentication with AH do not work over 642 non-RSVP nodes in 'Tunnel Mode'. 644 We also make the following observations: 646 o All key types can be used statically, or with dynamic key 647 negotiation. This impacts the managability of the solution, but 648 not the applicability itself. 649 o For encryption of RSVP messages IPsec ESP in tunnel mode can be 650 used. There is however a security concern, see Section 6.2. 651 o There are some special cases in RSVP, like non-RSVP hosts, the 652 "Notify" message (as discussed in section 5.1), the various RSVP 653 deployment models discussed in Section 8 and MPLS Traffic 654 Engineering and GMPLS discussed in section 5.2 , which would 655 benefit from a group keying approach. 657 10. Security Considerations 659 This entire document discusses RSVP security; this section describes 660 a specific security considerations relating to subverted RSVP nodes 662 10.1. Subverted RSVP Nodes 664 A subverted node is defined here as an untrusted node, for example 665 because an intruder has gained control over it. Since RSVP 666 authentication is hop-by-hop and not end-to-end, a subverted node in 667 the path breaks the chain of trust. This is to a large extent 668 independent of the type of keying used. 670 For interface or per-neighbor keying, the subverted node can now 671 introduce fake messages to its neighbors. This can be used in a 672 variety of ways, for example by changing the receiver address in the 673 Path message, or by generating fake Path messages. This allows path 674 states to be created on every RSVP router along any arbitrary path 675 through the RSVP domain. That in itself could result in a form of 676 Denial of Service by allowing exhaustion of some router resources 677 (e.g. memory). The subverted node could also generate fake Resv 678 messages upstream corresponding to valid Path states. In doing so, 679 the subverted node can reserve excessive amounts of bandwidth thereby 680 possibly performing a denial of service attack. 682 Group keying allows the additional abuse of sending fake RSVP 683 messages to any node in the RSVP domain, not just adjacent RSVP 684 nodes. However, in practice this can be achieved to a large extent 685 also with per neighbor or interface keys, as discussed above. 686 Therefore the impact of subverted nodes on the path is comparable, 687 independently whether per-interface, per-neighbor or group keys are 688 used. 690 11. Acknowledgements 692 The authors would like to thank everybody who provided feedback on 693 this document. Specific thanks to Bob Briscoe, Hannes Tschofenig, 694 Brian Weis and Ran Atkinson . 696 12. Changes to Previous Version 698 This section provides a change log. It will be removed in the final 699 document: 701 12.1. changes from behringer-00 to behringer-01 703 o New section "Applicability to Other Architectures and Protocols": 704 Goal is to clarify the scope of this document: The idea presented 705 here is also applicable to other architectures 706 (PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc. 707 o Clarified the scope of this document versus RFC4230 (in the 708 introduction, last paragraph). 709 o Added a section on "End Host Considerations". 710 o Expanded section 5.5 (RSVP Encryption) to clarify that GDOI 711 contains all necessary mechanisms to do RSVP encrpytion. 712 o Tried to clarify the "trust to do what?" question raised by Bob 713 Briscoe in a mail on 26 Jul 2007. See the section on trust model. 714 o Lots of small editorial changes (references, typos, figures, etc). 715 o Added an Acknowledgements section. 717 12.2. changes from behringer-01 to ietf-00 719 o various edits to make it clearer that draft-weis-gdoi-for-rsvp is 720 an example of how dynamic group keying could be achieved for RSVP 721 and not necessarily the recommended solution 723 12.3. changes from ietf-00 to ietf-01 725 o Significant re-structuring of the entire document, to improve the 726 flow, and provide more consistency in various sections. 727 o Moved the "Subverted RSVP nodes" discussion into the security 728 considerations section. 729 o Added a "summary" section. 730 o Complete re-write of the old section 5.5 (RSVP encryption), and 731 "promotion" to a separate section. 732 o Changed reference ID.weis-gdoi-for-rsvp to the new draft ID.weis- 733 gdoi-mac-tek 734 o in several places, explicitly mentioned "encryption" for RSVP (in 735 parallel to authentication). 736 o Various minor edits. 738 12.4. changes from ietf-01 to ietf-02 740 o Re-wrote and re-structured the section on IPsec (section 6). 741 o Re-wrote the section on RSVP-TE and GMPLS (section 5.2). 742 o Various editorial changes. 744 12.5. changes from ietf-02 to ietf-03 746 o Extension of section 6.3 (Using IPsec AH), to address comments 747 received from Ran Atkinson. Included a comparison of what AH 748 protects vs what the INTEGRITY object protects. 749 o Added section 6.5 on "tunnel mode with address preservation. 750 o Some minor edits. 752 12.6. changes from ietf-03 to ietf-04 754 o Added below table 1 in note (1) that "RSVP encryption with ESP and 755 RSVP authentication with AH work over non-RSVP nodes in 'Tunnel 756 Mode with Address Preservation'" 758 13. Informative References 760 [I-D.ietf-pcn-architecture] 761 Eardley, P., "Pre-Congestion Notification (PCN) 762 Architecture", draft-ietf-pcn-architecture-10 (work in 763 progress), March 2009. 765 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 766 Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP 767 Proxy Approaches", 768 draft-ietf-tsvwg-rsvp-proxy-approaches-06 (work in 769 progress), October 2008. 771 [I-D.weis-gdoi-mac-tek] 772 Weis, B. and S. Rowles, "GDOI Generic Message 773 Authentication Code Policy", draft-weis-gdoi-mac-tek-00 774 (work in progress), July 2008. 776 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 777 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 778 Functional Specification", RFC 2205, September 1997. 780 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 781 (IKE)", RFC 2409, November 1998. 783 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 784 Authentication", RFC 2747, January 2000. 786 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 787 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 788 RFC 3175, September 2001. 790 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 791 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 792 Tunnels", RFC 3209, December 2001. 794 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 795 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 796 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 798 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 799 Group Domain of Interpretation", RFC 3547, July 2003. 801 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 802 Signature Option", RFC 3562, July 2003. 804 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 805 Architecture", RFC 3740, March 2004. 807 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 808 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 809 May 2005. 811 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 812 Hierarchy with Generalized Multi-Protocol Label Switching 813 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 815 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 816 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 817 November 2005. 819 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 820 Properties", RFC 4230, December 2005. 822 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 823 December 2005. 825 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 826 RFC 4303, December 2005. 828 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 829 RFC 4306, December 2005. 831 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 832 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 833 RFC 4804, February 2007. 835 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 836 Davenport, "Generic Aggregate Resource ReSerVation 837 Protocol (RSVP) Reservations", RFC 4860, May 2007. 839 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 840 "Extensions to Resource Reservation Protocol - Traffic 841 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 842 Switched Paths (LSPs)", RFC 4875, May 2007. 844 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 845 Extensions to the Security Architecture for the Internet 846 Protocol", RFC 5374, November 2008. 848 Authors' Addresses 850 Michael H. Behringer 851 Cisco Systems Inc 852 Village d'Entreprises Green Side 853 400, Avenue Roumanille, Batiment T 3 854 Biot - Sophia Antipolis 06410 855 France 857 Email: mbehring@cisco.com 858 URI: http://www.cisco.com 860 Francois Le Faucheur 861 Cisco Systems Inc 862 Village d'Entreprises Green Side 863 400, Avenue Roumanille, Batiment T 3 864 Biot - Sophia Antipolis 06410 865 France 867 Email: flefauch@cisco.com 868 URI: http://www.cisco.com