idnits 2.17.1 draft-ietf-tsvwg-rsvp-security-groupkeying-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 199: '... receiver MAY initiate an integrity ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2010) is 5052 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2409' is defined on line 821, but no explicit reference was found in the text == Unused Reference: 'RFC4306' is defined on line 869, but no explicit reference was found in the text == 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 B. Weis 5 Expires: December 27, 2010 Cisco Systems 6 June 25, 2010 8 Applicability of Keying Methods for RSVP Security 9 draft-ietf-tsvwg-rsvp-security-groupkeying-06.txt 11 Abstract 13 The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity 14 protection of RSVP neighbors. This requires messages to be 15 cryptographically protected using a shared secret between 16 participating nodes. This document compares group keying for RSVP 17 with per neighbor or per interface keying, and discusses the 18 associated key provisioning methods as well as applicability and 19 limitations of these approaches. The document also discusses 20 applicability of encrypting RSVP messages. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 27, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 57 2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 3 58 3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5 59 3.1. Per interface and per neighbor keys . . . . . . . . . . . 5 60 3.2. Group keys . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 8 62 4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 8 63 4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8 64 4.2.1. Per Neighbor and Per Interface Key Negotiation . . . . 8 65 4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 9 66 5. Specific Cases Supporting Use of Group Keying . . . . . . . . 9 67 5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 9 68 5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 9 69 6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10 70 6.1. General Considerations Using IPsec . . . . . . . . . . . . 10 71 6.2. Comparing AH and the INTEGRITY Object . . . . . . . . . . 11 72 6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 12 73 6.4. Non-Applicability of Transport Mode . . . . . . . . . . . 12 74 6.5. Applicability of Tunnel Mode with Address Preservation . . 12 75 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 13 76 8. Applicability to Other Architectures and Protocols . . . . . . 13 77 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 15 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 81 12. Changes to Previous Version . . . . . . . . . . . . . . . . . 16 82 12.1. changes from behringer-00 to behringer-01 . . . . . . . . 16 83 12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 17 84 12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 17 85 12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 17 86 12.5. changes from ietf-02 to ietf-03 . . . . . . . . . . . . . 17 87 12.6. changes from ietf-03 to ietf-04 . . . . . . . . . . . . . 17 88 12.7. changes from ietf-04 to ietf-05 . . . . . . . . . . . . . 17 89 12.8. changes from ietf-05 to ietf-06 . . . . . . . . . . . . . 18 90 13. Informative References . . . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 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 identity 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 a key per router pair across an entire network is 108 operationally hard, especially when key changes are to be performed 109 on a regular basis. Effectively, many users of RSVP therefore resort 110 to using the same key throughout their RSVP network, and they change 111 it rarely if ever, because of the operational burden. It is however 112 often necessary to regularly change keys due to network operational 113 requirements. 115 This document discusses a variety of keying methods and their 116 applicability to different RSVP deployment environments, for both 117 message integrity and encryption. It is meant as a comparative guide 118 to understand where each RSVP keying method is best deployed, and the 119 limitations of each method. Furthermore, it discusses how RSVP hop 120 by hop authentication is impacted in the presence of non-RSVP nodes, 121 or subverted nodes, in 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 protecting 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]). If a group key is used, the 145 authentication granularity becomes group membership, not (individual) 146 peer authentication. 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) are 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 (because the authentication 158 is now based on group membership, as noted above). 160 The RSVP protocol can operate in the presence of a non-RSVP router in 161 the path from the sender to the receiver. The non-RSVP hop will 162 ignore the RSVP message and just pass it along. The next RSVP node 163 can then process the RSVP message. For RSVP authentication or 164 encryption to work in this case, the key used for computing the RSVP 165 message digest needs to be shared by the two RSVP neighbors, even if 166 they are not IP neighbors. However, in the presence of non-RSVP 167 hops, while an RSVP node always knows the next IP hop before 168 forwarding an RSVP Message, it does not always know the RSVP next 169 hop. In fact, part of the role of a Path message is precisely to 170 discover the RSVP next hop (and to dynamically re-discover it when it 171 changes, for example because of a routing change). Thus, the 172 presence of non-RSVP hops impacts operation of RSVP authentication or 173 encryption and may influence the selection of keying approaches. 175 Figure 1 illustrates this scenario. R2 in this picture does not 176 participate in RSVP, the other nodes do. In this case, R2 will pass 177 on any RSVP messages unchanged, and will ignore them. 179 ----R3--- 180 / \ 181 sender----R1---R2(*) R4----receiver 182 \ / 183 ----R5--- 184 (*) Non-RSVP hop 186 Figure 1: A non-RSVP Node in the path 188 This creates a challenge for RSVP authentication and encryption. In 189 the presence of a non-RSVP hop, with some RSVP messages such as a 190 PATH message, an RSVP router does not know the RSVP next hop for that 191 message at the time of forwarding it. For example, in Figure 1, R1 192 knows that the next IP hop for a Path message addressed to the 193 receiver is R2, but it does necessarily not know if the RSVP next hop 194 is R3 or R5. 196 This means that per interface and per neighbor keys cannot easily be 197 used in the presence of non-RSVP routers on the path between senders 198 and receivers. Section 4.3 of [RFC2747] states that "... the 199 receiver MAY initiate an integrity handshake with the sender." We 200 note that if this handshake is taking place, it can be used to 201 determine the identity of the next RSVP hop. In this case, non-RSVP 202 hops can be traversed also using per interface or per neighbor keys. 204 Group keying will naturally work in the presence of non-RSVP routers. 205 Referring back to Figure 1, with group keying, R1 would use the group 206 key to protect a Path message addressed to the receiver and forwards 207 it to R2. Being a non-RSVP node, R2 will ignore and forward the Path 208 message to R3 or R5 depending on the current shortest path as 209 determined by routing. Whether it is R3 or R5, the RSVP router that 210 receives the Path message will be able to authenticate it 211 successfully using the group key. 213 3. Applicability of Key Types for RSVP 215 3.1. Per interface and per neighbor keys 217 Most current RSVP authentication implementations support per 218 interface RSVP keys. When the interface is point-to-point (and 219 therefore an RSVP router has only a single RSVP neighbor on each 220 interface), this is equivalent to per neighbor keys in the sense that 221 a different key is used for each neighbor. However, when the 222 interface is multipoint, all RSVP speakers on a given subnet have to 223 share the same key in this model. This makes it unsuitable for 224 deployment scenarios where nodes from different security domains are 225 present on a subnet, for example Internet exchange points. A 226 security domain is defined here as a set of nodes that shares a 227 common RSVP security policy. In such cases, per neighbor keys are 228 required. 230 With per neighbor keys, each RSVP key is bound to an interface plus a 231 neighbor on that interface. It allows for the existence of different 232 security domains on a single interface and subnet. 234 per interface and per neighbor keys can be used within a single 235 security domain. As mentioned above, per interface keys are only 236 applicable when all the nodes reachable on the specific interface 237 belong to the same security domain. 239 These key types can also be used between security domains, since they 240 are specific to a particular interface or neighbor. Again, interface 241 level keys can be deployed safely only when all the reachable 242 neighbors on the interface belong to the same security domain. 244 Both monotonically increasing sequence number (e.g., the INTEGRITY 245 object simple sequence numbers [RFC2747], or the ESP and AH anti- 246 replay service [RFC4301] sequence numbers) and time based anti-replay 247 methods (e.g., the INTEGITY sequence numbers based on a clock 248 [RFC2747]) can be used with per neighbor and per interface keys. 250 As discussed in the previous section, per neighbor and per interface 251 keys can not be used in the presence of non-RSVP hops. 253 3.2. Group keys 255 In the case of group keys, all members of a group of RSVP nodes share 256 the same key. This implies that a node uses the same key regardless 257 of the next RSVP hop that will process the message (within the group 258 of nodes sharing the particular key). It also implies that a node 259 will use the same key on the receiving as on the sending side (when 260 exchanging RSVP messages within the group). 262 Group keys apply naturally to intra-domain RSVP authentication, where 263 all RSVP nodes are part of the same security domain and implicitly 264 trust each other. Using group keys, they extend this trust to the 265 group key server. This is represented in Figure 2. 267 ......GKS1............. 268 : : : : : 269 : : : : : 270 source--R1--R2--R3-----destination 271 | | 272 |<-----domain 1----------------->| 274 Figure 2: Group Key Server within a single security domain 276 A single group key cannot normally be used to cover multiple security 277 domains, because by definition the different domains do not trust 278 each other. They would therefore not be willing to trust the same 279 group key server. For a single group key to be used in several 280 security domains, there is a need for a single group key server, 281 which is trusted by both sides. While this is theoretically 282 possible, in practice it is unlikely that there is a single such 283 entity trusted by both domains. Figure 3 illustrates this setup. 285 ...............GKS1.................... 286 : : : : : : : : 287 : : : : : : : : 288 source--R1--R2--R3--------R4--R5--R6--destination 289 | | | | 290 |<-----domain 1--->| |<-------domain 2----->| 292 Figure 3: A Single Group Key Server across security domains 294 A more practical approach for RSVP operation across security domains, 295 is to use a separate group key server for each security domain, and 296 to use per interface or per neighbor keys between the two domains. 297 Figure 4 shows this setup. 299 ....GKS1...... ....GKS2......... 300 : : : : : : : : 301 : : : : : : : : 302 source--R1--R2--R3--------R4--R5--R6--destination 303 | | | | 304 |<-----domain 1--->| |<-------domain 2----->| 306 Figure 4: A group Key Server per security domain 308 As discussed in Section 2, group keying can be used in the presence 309 of non-RSVP hops. 311 Because a group key may be used to verify messages from different 312 peers, monotonically increasing sequence number methods are not 313 appropriate. Time based anti-replay methods (e.g., the INTEGITY 314 sequence numbers based on a clock [RFC2747]) can be used with group 315 keys. 317 4. Key Provisioning Methods for RSVP 319 4.1. Static Key Provisioning 321 Static keys are preconfigured, either manually, or through a network 322 management system, and not negotiated via a protocol. The simplest 323 way to implement RSVP authentication is to use static keys. Static 324 keying can be used with per interface keys, per neighbor keys or 325 group keys. 327 The provisioning of static keys requires either manual operator 328 intervention on each node, or a network management system performing 329 the same task. Time synchronization of static key provisioning and 330 changes is critical, to avoid inconsistent keys within a security 331 domain. 333 Static key provisioning is therefore not an ideal model in a large 334 network. 336 Often, the number of interconnection points across two domains where 337 RSVP is allowed to transit is relatively small and well controlled. 338 Also, the different domains may not be in a position to use an 339 infrastructure trusted by both domains to update keys on both sides. 340 Thus, statically provisioned keys may be applicable to inter-domain 341 RSVP authentication. 343 Since it is not feasible to carry out a key change at the exact same 344 time in communicating RSVP nodes, some grace period needs to be 345 implemented during which an RSVP node will accept both the old and 346 the new key. Otherwise, RSVP operation would suffer interruptions. 347 (Note that also with dynamic keying approaches there can be a grace 348 period where two keys are valid at the same time; however, the grace 349 period in manual keying tends to be significantly longer than with 350 dynamic key rollover schemes.) 352 4.2. Dynamic Keying 354 4.2.1. Per Neighbor and Per Interface Key Negotiation 356 To avoid the problem of manual key provisioning and updates in static 357 key deployments, key negotiation between RSVP neighbors could be used 358 to derive either per interface or per neighbor keys. 360 4.2.2. Dynamic Group Key Distribution 362 With this approach, group keys are dynamically distributed among a 363 set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes 364 a mechanism to distribute group keys to a group of RSVP speakers, 365 using GDOI [RFC3547]. In this solution, a key server authenticates 366 each of the RSVP nodes independently, and then distributes a group 367 key to the group as part of an encrypted and integrity protected key 368 agreement protocol. The authentication in this model can be based on 369 public key mechanisms, thereby avoiding the need for static key 370 provisioning. 372 5. Specific Cases Supporting Use of Group Keying 374 5.1. RSVP Notify Messages 376 [RFC3473] introduces the Notify message and allows such messages to 377 be sent in a non-hop-by-hop fashion. As discussed in the Security 378 Considerations section of [RFC3473], this can interfere with RSVP's 379 hop-by-hop integrity and authentication model. [RFC3473] describes 380 how standard IPsec based integrity and authentication can be used to 381 protect Notify messages. We observe that, alternatively, in some 382 environments, group keying may allow use of regular RSVP 383 authentication ([RFC2747]) for protection of non-hop-by-hop Notify 384 messages. 386 For example, RSVP Notify messages commonly used for traffic 387 engineering in MPLS networks are non-hop-by-hop messages. Such 388 messages may be sent from an ingress node directly to an egress node. 389 Group keying in such a case avoids the establishment of node-to-node 390 keying when node-to-node keying is not otherwise used. 392 5.2. RSVP-TE and GMPLS 394 Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast 395 Reroute [RFC4090] deserves additional considerations. 397 With the facility backup method of Fast Reroute, a backup tunnel from 398 the Point of Local Repair (PLR) to the Merge Point (MP) is used to 399 protect Label Switched Paths (protected LSPs) against the failure of 400 a facility (e.g., a router) located between the PLR and the MP. 401 During the failure of the facility, the PLR redirects a protected LSP 402 inside the backup tunnel and as a result, the PLR and MP then need to 403 exchange RSVP control messages between each other (e.g., for the 404 maintenance of the protected LSP). Some of the RSVP messages between 405 the PLR and MP are sent over the backup tunnel (e.g., a Path message 406 from PLR to MP) while some are directly addressed to the RSVP node 407 (e.g., a Resv message from MP to PLR). During the rerouted period, 408 the PLR and the MP effectively become RSVP neighbors, while they may 409 not be directly connected to each other and thus do not behave as 410 RSVP neighbors in the absence of failure. This point is raised in 411 the Security Considerations section of [RFC4090] that says: "Note 412 that the facility backup method requires that a PLR and its selected 413 merge point trust RSVP messages received from each other." We 414 observe that such environments may benefit from group keying. A 415 group key can be used among a set of routers enabled for Fast Reroute 416 thereby easily ensuring that PLR and MP authenticate messages from 417 each other can be authenticated, without requiring prior specific 418 configuration of keys, or activation of key update mechanism, for 419 every possible pair of PLR and MP. 421 Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS 422 boundaries (see [RFC4216]), the considerations presented above in 423 section 3.1 and 3.2 apply, such that per interface or per neighbor 424 keys can be used between two RSVP neighbors in different ASes 425 (independently of the keying method used by the RSVP router to talk 426 to the RSVP routers in the same AS). 428 [RFC4875] specifies protocol extensions for support of Point-to- 429 Multipoint (P2MP) RSVP-TE. In its Security Considerations section, 430 [RFC4875] points out that RSVP message integrity mechanisms for hop- 431 by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling. 432 In turn, we observe that the analyses in this document of keying 433 methods apply equally to P2MP RSVP-TE for the hop-by-hop signaling. 435 [RFC4206] defines LSP Hierarchy with GMPLS TE and uses non-hop-by-hop 436 signaling. Because it reuses LSP Hierarchy procedures for some of 437 its operations, P2MP RSVP-TE also uses non-hop-by-hop signaling. 438 Both LSP hierarchy and P2MP RSVP-TE rely on the security mechanisms 439 defined in [RFC3473] and [RFC4206] for non hop-by-hop RSVP-TE 440 signaling. We note that the observation in Section 3.1 of this 441 document about use of group keying for protection of non-hop-by-hop 442 messages apply to protection of non-hop-by-hop signaling for LSP 443 Hierarchy and P2MP RSVP- TE. 445 6. Applicability of IPsec for RSVP 447 6.1. General Considerations Using IPsec 449 The discussions about the various keying methods in this document are 450 also applicable when using IPsec [RFC4301] to protect RSVP. Note 451 that [RFC2747] states in section 1.2 that IPsec is not an optimal 452 choice to protect RSVP. The key argument is that an IPsec SA and an 453 RSVP SA are not based on the same parameters. Nevertheless, IPsec 454 can be used to protect RSVP. Note that the SPD traffic selectors for 455 related RSVP flows will not be constant. In some cases, the source 456 and destination addresses are end hosts, and sometimes they are RSVP 457 routers. Therefore, traffic selectors in the SPD should specify ANY 458 for the source address and destination addresses, and specify IP 459 protocol 46 (RSVP). 461 The document "The Multicast Group Security Architecture" [RFC3740] 462 defines in detail a "Group Security Association" (GSA). This 463 definition is also applicable in the context discussed here, and 464 allows the use of IPsec for RSVP. The existing GDOI standard 465 [RFC3547] manages group security associations, which can be used by 466 IPsec. An example GDOI policy would be to encrypt or authenticate 467 all packets of the RSVP protocol itself (IP protocol 46). A router 468 implementing GDOI and the AH and/or ESP protocols is therefore able 469 to implement this policy. 471 Because the traffic selectors for an SA cannot be predicted, SA 472 lookup should use only the SPI (or SPI plus protocol). 474 6.2. Comparing AH and the INTEGRITY Object 476 The INTEGRITY object defined by [RFC2747] provides integrity 477 protection for RSVP also in a group keying context, as discussed 478 above. AH [RFC4302] is an alternative method to provide integrity 479 protection for RSVP packets. 481 The RSVP INTEGRITY object protects the entire RSVP message, but does 482 not protect the IP header of the packet nor the IP options (in IPv4) 483 or extension headers (in IPv6). 485 AH tunnel mode (transport mode is not applicable, see section 6.4) 486 protects the entire original IP packet, including the IP header of 487 the original IP packet ("inner header"), IP options or extension 488 headers, plus the entire RSVP packet. It also protects the immutable 489 fields of the outer header. 491 The difference between the two schemes in terms of covered fields is 492 therefore whether the IP header and IP options or extension headers 493 of the original IP packet are protected (as is the case with AH) or 494 not (as is the case with the INTEGRITY object). Also, AH covers the 495 immutable fields of the outer header. 497 As described in the next section, IPsec tunnel mode can not be 498 applied for RSVP traffic in the presence of non-RSVP nodes; therefore 499 the security associations in both cases, AH and INTEGRITY object, are 500 between the same RSVP neighbors. From a keying point of view both 501 approaches are therefore comparable. 503 6.3. Applicability of Tunnel Mode 505 IPsec tunnel mode encapsulates the original packet, prepending a new 506 IP header plus an ESP or AH sub-header. The entire original packet 507 plus the ESP/AH sub-header is secured. In the case of ESP the new, 508 outer IP header however is not cryptographically secured in this 509 process. This has consequences when group keying is used; see the 510 Security Considerations section for details. 512 Protecting RSVP packets with IPsec tunnel mode works with any of the 513 above described keying methods (interface, neighbor or group based), 514 as long as there are no non-RSVP nodes on the path. Note that for 515 RSVP messages to be visible and considered at each hop, such a tunnel 516 would not cross routers, but each RSVP node would establish a tunnel 517 with each of its peers, effectively leading to link protection. 519 In the presence of a non-RSVP hop, tunnel mode cannot be applied, 520 because a router upstream from a non-RSVP hop does not know the next 521 RSVP hop, and can thus not apply the correct tunnel header. This is 522 independent of the key type used. 524 6.4. Non-Applicability of Transport Mode 526 IPsec transport mode, as defined in [RFC4303] is not suitable for 527 securing RSVP Path messages, since those messages preserve the 528 original source and destination. [RFC4303] states explicitly that 529 "the use of transport mode by an intermediate system (e.g., a 530 security gateway) is permitted only when applied to packets whose 531 source address (for outbound packets) or destination address (for 532 inbound packets) is an address belonging to the intermediate system 533 itself." This would not be the case for RSVP Path messages. 535 6.5. Applicability of Tunnel Mode with Address Preservation 537 When the identity of the next-hop RSVP peer is not known, it is not 538 possible to use tunnel-endpoint destination address in the Tunnel 539 Mode outer IP header. The document "Multicast Extensions to the 540 Security Architecture for the Internet Protocol" [RFC5374] defines in 541 section 3.1 a new tunnel mode: Tunnel mode with address preservation. 542 This mode copies the destination and optionally the source address 543 from the inner header to the outer header. Therefore the 544 encapsulated packet will have the same destination address as the 545 original packet, and be normally subject to the same routing 546 decisions. While [RFC5374] is focusing on multicast environments, 547 tunnel mode with address preservation can be used also to protect 548 unicast traffic in conjunction with group keying. Note that in this 549 tunnel mode the RSVP speakers act as security gateways, because they 550 maintain the original end system addresses of the RSVP packets in the 551 outer tunnel mode IP header. This addressing scheme is used by RSVP 552 to ensure that the packets continue along the routed path toward the 553 destination end host. 555 Tunnel mode with address preservation, in conjunction with group 556 keying, allows the use of AH or ESP for protection of RSVP even in 557 cases where non-RSVP nodes have to be traversed. This is because it 558 allows routing of the IPsec protected packet through the non-RSVP 559 nodes in the same way as if it was not IPsec protected. 561 7. End Host Considerations 563 Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches] 564 are used, RSVP signaling is controlled by end systems and not 565 routers. As discussed in [RFC4230], RSVP allows both user-based 566 security and host-based security. User-based authentication aims at 567 "providing policy based admission control mechanism based on user 568 identities or application." To identify the user or the application, 569 a policy element called AUTH_DATA, which is contained in the 570 POLICY_DATA object, is created by the RSVP daemon at the user's host 571 and transmitted inside the RSVP message. This way, a user may 572 authenticate to the Policy Decision Point (or directly to the first 573 hop router). Host-based security relies on the same mechanisms as 574 between routers (i.e., the INTEGRITY object) as specified in 575 [RFC2747]. For host-based security, per interface or per neighbor 576 keys may be used, however, key management with statically provisioned 577 keys can be difficult in a large scale deployment, as described in 578 section 4. In principle an end host can also be part of a group key 579 scheme, such as GDOI. If the end systems are part of the same 580 security domain as the network itself, group keying can be extended 581 to include the end systems. If the end systems and the network are 582 in different zones of trust, group keying cannot be used. 584 8. Applicability to Other Architectures and Protocols 586 While, so far, this document discusses only RSVP security assuming 587 the traditional RSVP model as defined by [RFC2205] and [RFC2747], the 588 analysis is also applicable to other RSVP deployment models as well 589 as to similar protocols: 591 o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This 592 scheme defines aggregation of individual RSVP reservations, and 593 discusses use of RSVP authentication for the signaling messages. 594 Group keying is applicable to this scheme, particularly when 595 automatic Deaggregator discovery is used, since in that case, the 596 Aggregator does not know ahead of time which Deaggregator will 597 intercept the initial end-to-end RSVP Path message. 598 o Generic Aggregate Resource ReSerVation Protocol (RSVP) 599 Reservations [RFC4860]: This document also discusses aggregation 600 of individual RSVP reservations. Here again, group keying applies 601 and is mentioned in the Security Considerations section. 602 o Aggregation of Resource ReSerVation Protocol (RSVP) Reservations 603 over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): This scheme also 604 defines a form of aggregation of RSVP reservation but this time 605 over MPLS TE Tunnels. Similarly, group keying may be used in such 606 an environment. 607 o Pre-Congestion Notification (PCN): [I-D.ietf-pcn-architecture] 608 defines an architecture for flow admission and termination based 609 on aggregated pre-congestion information. One deployment model 610 for this architecture is based on IntServ over DiffServ: the 611 DiffServ region is PCN-enabled, RSVP signalling is used end-to-end 612 but the PCN-domain is a single RSVP hop, i.e. only the PCN- 613 boundary-nodes process RSVP messages. In this scenario, RSVP 614 authentication may be required among PCN-boundary-nodes and the 615 considerations about keying approaches discussed earlier in this 616 document apply. In particular, group keying may facilitate 617 operations since the ingress PCN-boundary-node does not 618 necessarily know ahead of time which Egress PCN-boundary-node will 619 intercept and process the initial end-to-end Path message. Note 620 that from the viewpoint of securing end-to-end RSVP, there are a 621 lot of similarities in scenarios involving RSVP Aggregation over 622 aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP 623 Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP 624 (Aggregation) over PCN ingress-egress aggregates. 626 9. Summary 628 The following table summarizes the various approaches for RSVP 629 keying, and their applicability to various RSVP scenarios. In 630 particular, such keying can be used for RSVP authentication (e.g., 631 using the RSVP INTEGRITY object or AH) and/ or for RSVP encryption 632 (e.g., using ESP in tunnel mode). 634 +-------------------------------+-----------------+-----------------+ 635 | | per | Group keys | 636 | | neighbor/per | | 637 | | interface keys | | 638 +-------------------------------+-----------------+-----------------+ 639 | Works intra-domain | Yes | Yes | 640 | Works inter-domain | Yes | No | 641 | Works over non-RSVP hops | No | Yes (1) | 642 | Dynamic keying | Yes (IKE) | Yes (e.g., | 643 | | | GDOI) | 644 +-------------------------------+-----------------+-----------------+ 646 Table 1: Overview of keying approaches and their applicability 648 (1): RSVP integrity with group keys works over non-RSVP nodes; RSVP 649 encryption with ESP and RSVP authentication with AH work over non- 650 RSVP nodes in 'Tunnel Mode with Address Preservation'; RSVP 651 encryption with ESP & RSVP authentication with AH do not work over 652 non-RSVP nodes in 'Tunnel Mode'. 654 We also make the following observations: 656 o All key types can be used statically, or with dynamic key 657 negotiation. This impacts the manageability of the solution, but 658 not the applicability itself. 659 o For encryption of RSVP messages, IPsec ESP in tunnel mode can be 660 used. 661 o There are some special cases in RSVP, like non-RSVP hosts, the 662 "Notify" message (as discussed in Section 5.1), the various RSVP 663 deployment models discussed in Section 8 and MPLS Traffic 664 Engineering and GMPLS discussed in section 5.2 , which would 665 benefit from a group keying approach. 667 10. Security Considerations 669 This entire document discusses RSVP security; this section describes 670 a specific security considerations relating to subverted RSVP nodes. 672 10.1. Subverted Nodes 674 A subverted node is defined here as an untrusted node, for example 675 because an intruder has gained control over it. Since RSVP 676 authentication is hop-by-hop and not end-to-end, a subverted node in 677 the path breaks the chain of trust. This is to a large extent 678 independent of the type of keying used. 680 For interface or per neighbor keying, the subverted node can now 681 introduce fake messages to its neighbors. This can be used in a 682 variety of ways, for example by changing the receiver address in the 683 Path message, or by generating fake Path messages. This allows path 684 states to be created on every RSVP router along any arbitrary path 685 through the RSVP domain. That in itself could result in a form of 686 Denial of Service by allowing exhaustion of some router resources 687 (e.g. memory). The subverted node could also generate fake Resv 688 messages upstream corresponding to valid Path states. In doing so, 689 the subverted node can reserve excessive amounts of bandwidth thereby 690 possibly performing a denial of service attack. 692 Group keying allows the additional abuse of sending fake RSVP 693 messages to any node in the RSVP domain, not just adjacent RSVP 694 nodes. However, in practice this can be achieved to a large extent 695 also with per neighbor or interface keys, as discussed above. 696 Therefore the impact of subverted nodes on the path is comparable for 697 all keying schemes discussed here (per interface, per neighbor, group 698 keys). 700 11. Acknowledgements 702 The authors would like to thank everybody who provided feedback on 703 this document. Specific thanks to Bob Briscoe, Hannes Tschofenig, 704 Brian Weis, Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg. 706 12. Changes to Previous Version 708 This section provides a change log. It will be removed in the final 709 document: 711 12.1. changes from behringer-00 to behringer-01 713 o New section "Applicability to Other Architectures and Protocols": 714 Goal is to clarify the scope of this document: The idea presented 715 here is also applicable to other architectures 716 (PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc. 717 o Clarified the scope of this document versus RFC4230 (in the 718 introduction, last paragraph). 719 o Added a section on "End Host Considerations". 720 o Expanded section 5.5 (RSVP Encryption) to clarify that GDOI 721 contains all necessary mechanisms to do RSVP encrpytion. 722 o Tried to clarify the "trust to do what?" question raised by Bob 723 Briscoe in a mail on 26 Jul 2007. See the section on trust model. 724 o Lots of small editorial changes (references, typos, figures, etc). 726 o Added an Acknowledgements section. 728 12.2. changes from behringer-01 to ietf-00 730 o various edits to make it clearer that draft-weis-gdoi-for-rsvp is 731 an example of how dynamic group keying could be achieved for RSVP 732 and not necessarily the recommended solution 734 12.3. changes from ietf-00 to ietf-01 736 o Significant re-structuring of the entire document, to improve the 737 flow, and provide more consistency in various sections. 738 o Moved the "Subverted RSVP nodes" discussion into the security 739 considerations section. 740 o Added a "summary" section. 741 o Complete re-write of the old section 5.5 (RSVP encryption), and 742 "promotion" to a separate section. 743 o Changed reference ID.weis-gdoi-for-rsvp to the new draft ID.weis- 744 gdoi-mac-tek 745 o in several places, explicitly mentioned "encryption" for RSVP (in 746 parallel to authentication). 747 o Various minor edits. 749 12.4. changes from ietf-01 to ietf-02 751 o Re-wrote and re-structured the section on IPsec (section 6). 752 o Re-wrote the section on RSVP-TE and GMPLS (section 5.2). 753 o Various editorial changes. 755 12.5. changes from ietf-02 to ietf-03 757 o Extension of section 6.3 (Using IPsec AH), to address comments 758 received from Ran Atkinson. Included a comparison of what AH 759 protects vs what the INTEGRITY object protects. 760 o Added section 6.5 on "tunnel mode with address preservation. 761 o Some minor edits. 763 12.6. changes from ietf-03 to ietf-04 765 o Added below table 1 in note (1) that "RSVP encryption with ESP and 766 RSVP authentication with AH work over non-RSVP nodes in 'Tunnel 767 Mode with Address Preservation'" 769 12.7. changes from ietf-04 to ietf-05 771 o Clarified in section 6.3 that IPsec AH also secures the immutable 772 fields of the outer header (comment from Bob Briscoe) 774 o Simplified in section 2 the comment that trust in group keying 775 extends to all members of the group (deleted the words on 776 "explicit and implicit"). (comment from Brian Weis) 777 o A number of corrections, re-wordings and clarifications in 778 response to Kenneth Carlberg's email from 2 June 2009 780 12.8. changes from ietf-05 to ietf-06 782 This version addresses extensive comments from Stephen Kent in the 783 SecDir review (see email from Gorry on 15 Jan 2010). Specifically: 784 o Many editorial changes, and small corrections. 785 o Deleted reference to RFC3562, since it is not applicable in this 786 context. 787 o Clarification in section 2 that the handshake specified in RFC2747 788 allows to determine the identity of the next RSVP hop in the 789 presence of non-RSVP hops. 790 o Cleared up inconsistent wording on "trust group" and "security 791 domain", and defined the latter. (Section 3) 792 o Added a paragraph on the applicability of sequence numbers in 793 section 3.1 and 3.2. 794 o Defined static key provisioning. (Section 4.1) 795 o Clarified wording in 6.1 on the use of GDOI. 796 o Added in section 6.6 some clarification to the use of tunnel mode 797 with address preservation. 799 13. Informative References 801 [I-D.ietf-pcn-architecture] 802 Eardley, P., "Pre-Congestion Notification (PCN) 803 Architecture", draft-ietf-pcn-architecture-11 (work in 804 progress), April 2009. 806 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 807 Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP 808 Proxy Approaches", 809 draft-ietf-tsvwg-rsvp-proxy-approaches-09 (work in 810 progress), March 2010. 812 [I-D.weis-gdoi-mac-tek] 813 Weis, B. and S. Rowles, "GDOI Generic Message 814 Authentication Code Policy", draft-weis-gdoi-mac-tek-00 815 (work in progress), July 2008. 817 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 818 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 819 Functional Specification", RFC 2205, September 1997. 821 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 822 (IKE)", RFC 2409, November 1998. 824 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 825 Authentication", RFC 2747, January 2000. 827 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 828 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 829 RFC 3175, September 2001. 831 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 832 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 833 Tunnels", RFC 3209, December 2001. 835 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 836 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 837 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 839 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 840 Group Domain of Interpretation", RFC 3547, July 2003. 842 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 843 Architecture", RFC 3740, March 2004. 845 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 846 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 847 May 2005. 849 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 850 Hierarchy with Generalized Multi-Protocol Label Switching 851 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 853 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 854 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 855 November 2005. 857 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 858 Properties", RFC 4230, December 2005. 860 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 861 Internet Protocol", RFC 4301, December 2005. 863 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 864 December 2005. 866 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 867 RFC 4303, December 2005. 869 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 870 RFC 4306, December 2005. 872 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 873 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 874 RFC 4804, February 2007. 876 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 877 Davenport, "Generic Aggregate Resource ReSerVation 878 Protocol (RSVP) Reservations", RFC 4860, May 2007. 880 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 881 "Extensions to Resource Reservation Protocol - Traffic 882 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 883 Switched Paths (LSPs)", RFC 4875, May 2007. 885 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 886 Extensions to the Security Architecture for the Internet 887 Protocol", RFC 5374, November 2008. 889 Authors' Addresses 891 Michael H. Behringer 892 Cisco Systems 893 Village d'Entreprises Green Side 894 400, Avenue Roumanille, Batiment T 3 895 Biot - Sophia Antipolis 06410 896 France 898 Email: mbehring@cisco.com 899 URI: http://www.cisco.com 901 Francois Le Faucheur 902 Cisco Systems 903 Village d'Entreprises Green Side 904 400, Avenue Roumanille, Batiment T 3 905 Biot - Sophia Antipolis 06410 906 France 908 Email: flefauch@cisco.com 909 URI: http://www.cisco.com 910 Brian Weis 911 Cisco Systems 912 170 W. Tasman Drive 913 San Jose, California 95134-1706 914 USA 916 Email: bew@cisco.com 917 URI: http://www.cisco.com