idnits 2.17.1 draft-ietf-tsvwg-rsvp-security-groupkeying-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 813. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 837. 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 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 (November 3, 2008) is 5652 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-08 == 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 (==), 10 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: May 7, 2009 November 3, 2008 7 Applicability of Keying Methods for RSVP Security 8 draft-ietf-tsvwg-rsvp-security-groupkeying-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 7, 2009. 35 Abstract 37 The Resource reSerVation Protocol (RSVP) allows hop-by-hop 38 authentication of RSVP neighbors. This requires messages to be 39 cryptographically signed using a shared secret between participating 40 nodes. This document compares group keying for RSVP with per 41 neighbor or per interface keying, and discusses the associated key 42 provisioning methods as well as applicability and limitations of 43 these approaches. The present document also discusses applicability 44 of group keying to RSVP encryption. 46 Table of Contents 48 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 49 2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 3 50 3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5 51 3.1. Interface and neighbor based keys . . . . . . . . . . . . 5 52 3.2. Group keys . . . . . . . . . . . . . . . . . . . . . . . . 6 53 4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 7 54 4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 7 55 4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8 56 4.2.1. Neighbor and Interface Based Key Negotiation . . . . . 8 57 4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 8 58 5. Specific Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 8 60 5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 8 61 6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10 62 6.1. General Considerations Using IPsec . . . . . . . . . . . . 10 63 6.2. Using IPsec ESP . . . . . . . . . . . . . . . . . . . . . 10 64 6.3. Using IPsec AH . . . . . . . . . . . . . . . . . . . . . . 11 65 6.4. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 11 66 6.5. Applicability of Transport Mode . . . . . . . . . . . . . 11 67 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 11 68 8. Applicability to Other Architectures and Protocols . . . . . . 12 69 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 10.1. Subverted RSVP Nodes . . . . . . . . . . . . . . . . . . . 14 72 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 73 12. Changes to Previous Version . . . . . . . . . . . . . . . . . 15 74 12.1. changes from behringer-00 to behringer-01 . . . . . . . . 15 75 12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 15 76 12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 15 77 12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 15 78 13. Informative References . . . . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 80 Intellectual Property and Copyright Statements . . . . . . . . . . 19 82 1. Introduction and Problem Statement 84 The Resource reSerVation Protocol [RFC2205] allows hop-by-hop 85 authentication of RSVP neighbors, as specified in [RFC2747]. In this 86 mode, an integrity object is attached to each RSVP message to 87 transmit a keyed message digest. This message digest allows the 88 recipient to verify the authenticity of the RSVP node that sent the 89 message, and to validate the integrity of the message. Through the 90 inclusion of a sequence number in the scope of the digest, the digest 91 also offers replay protection. 93 [RFC2747] does not dictate how the key for the integrity operation is 94 derived. Currently, most implementations of RSVP use a statically 95 configured key, per interface or per neighbor. However, to manually 96 configure key per router pair across an entire network is 97 operationally hard, especially for key changes. Effectively, many 98 users of RSVP therefore resort to the same key throughout their RSVP 99 network, and change it rarely if ever, because of the operational 100 burden. [RFC3562] however recommends regular key changes, at least 101 every 90 days. 103 The present document discusses the various keying methods and their 104 applicability to different RSVP deployment environments, for both 105 message integrity and encryption. It does not recommend any 106 particular method or protocol (e.g., RSVP authentication versus IPsec 107 AH), but is meant as a comparative guideline to understand where each 108 RSVP keying method is best deployed, and its limitations. 109 Furthermore, it discusses how RSVP hop by hop authentication is 110 impacted in the presence of non-RSVP nodes, or subverted nodes, in 111 the reservation path. 113 The document "RSVP Security Properties" ([RFC4230]) provides an 114 overview of RSVP security, including RSVP Cryptographic 115 Authentication [RFC2747], but does not discuss key management. It 116 states that "RFC 2205 assumes that security associations are already 117 available". The present document focuses specifically on key 118 management with different key types, including group keys. Therefore 119 this document complements [RFC4230]. 121 2. The RSVP Hop-by-Hop Trust Model 123 Many protocol security mechanisms used in networks require and use 124 per peer authentication. Each hop authenticates its neighbor with a 125 shared key or certificate. This is also the model used for RSVP. 126 Trust in this model is transitive. Each RSVP node trusts explicitly 127 only its RSVP next hop peers, through the message digest contained in 128 the INTEGRITY object. The next hop RSVP speaker in turn trusts its 129 own peers and so on. See also the document "RSVP security 130 properties" [RFC4230] for more background. 132 The keys used for generating the RSVP messages can, in particular, be 133 group keys (for example distributed via GDOI [RFC3547], as discussed 134 in [I-D.weis-gdoi-mac-tek]). 136 The trust an RSVP node has to another RSVP node has an explicit and 137 an implicit component. Explicitly the node trusts the other node to 138 maintain the RSVP messages intact or confidential, depending on 139 whether authentication or encryption (or both) is used. This means 140 only that the message has not been altered or seen by another, non- 141 trusted node. Implicitly each node trusts each other node with which 142 it has a trust relationship established via the mechanisms here to 143 adhere to the protocol specifications laid out by the various 144 standards. Note that in any group keying scheme like GDOI a node 145 trusts explicitly as well as implicitly all the other members of the 146 group. 148 The RSVP protocol can operate in the presence of a non-RSVP router in 149 the path from the sender to the receiver. The non-RSVP hop will 150 ignore the RSVP message and just pass it along. The next RSVP node 151 can then process the RSVP message. For RSVP authentication or 152 encryption to work in this case, the key used for computing the RSVP 153 message digest needs to be shared by the two RSVP neighbors, even if 154 they are not IP neighbors. However, in the presence of non-RSVP 155 hops, while an RSVP node always knows the next IP hop before 156 forwarding an RSVP Message, it does not always know the RSVP next 157 hop. In fact, part of the role of a Path message is precisely to 158 discover the RSVP next hop (and to dynamically re-discover it when it 159 changes, for example because of a routing change). Thus, the 160 presence of non-RSVP hops impacts operation of RSVP authentication or 161 encryption and may influence the selection of keying approaches. 163 Figure 1 illustrates this scenario. R2 in this picture does not 164 participate in RSVP, the other nodes do. In this case, R2 will pass 165 on any RSVP messages unchanged, and will ignore them. 167 ----R3--- 168 / \ 169 sender----R1---R2(*) R4----receiver 170 \ / 171 ----R5--- 172 (*) Non-RSVP hop 174 Figure 1: A non-RSVP Node in the path 176 This creates a challenge for RSVP authentication and encryption. In 177 the presence of a non-RSVP hop, with some RSVP messages such as a 178 PATH message, an RSVP router does not know the RSVP next hop for that 179 message at the time of forwarding it. For example, in Figure 1, R1 180 knows that the next IP hop for a Path message addressed to the 181 receiver is R2, but it does necessarily not know if the RSVP next hop 182 is R3 or R5. 184 This means that per interface and per neighbor keys cannot easily be 185 used in the presence of non-RSVP routers on the path between senders 186 and receivers. 188 By contrast, group keying will naturally work in the presence of non- 189 RSVP routers. Referring back to Figure 1, with group keying, R1 190 would use the group key to sign a Path message addressed to the 191 receiver and forwards it to R2. Being a non-RSVP node, R2 and will 192 ignore and forward the Path message to R3 or R5 depending on the 193 current shortest path as determined by routing. Whether it is R3 or 194 R5, the RSVP router that receives the Path message will be able to 195 authenticate it successfully with the group key. 197 3. Applicability of Key Types for RSVP 199 3.1. Interface and neighbor based keys 201 Most current RSVP authentication implementations support interface 202 based RSVP keys. When the interface is point-to-point (and therefore 203 an RSVP router only has a single RSVP neighbor on each interface), 204 this is equivalent to neighbor based keys in the sense that a 205 different key is used for each neighbor. However, when the interface 206 is multipoint, all RSVP speakers on a given subnet have to share the 207 same key in this model, which makes it unsuitable for deployment 208 scenarios where different trust groups share a subnet, for example 209 Internet exchange points. In such a case, neighbor based keys are 210 required. 212 With neighbor based keys, an RSVP key is bound to an interface plus a 213 neighbor on that interface. It allows the distinction of different 214 trust groups on a single subnet. (Assuming that layer-2 security is 215 correctly implemented to prevent layer-2 attacks.) 217 Per interface and per neighbor keys can be used within a single 218 security domain. As mentioned above, per interface keys are only 219 applicable when all the nodes reachable on the specific interface 220 belong to the same security domain. 222 These key types can also be used between security domains, since they 223 are specific to a particular interface or neighbor. Again, interface 224 level keys can only be deployed safely when all the reachable 225 neighbors on the interface belong to the same security domain. 227 As discussed in the previous section, per neighbor and per interface 228 keys can not be used in the presence of non-RSVP hops. 230 3.2. Group keys 232 Here, all members of a group of RSVP nodes share the same key. This 233 implies that a node uses the same key regardless of the next RSVP hop 234 that will process the message (within the group of nodes sharing the 235 particular key). It also implies that a node will use the same key 236 on the receiving as on the sending side (when exchanging RSVP 237 messages within the group). 239 Group keys apply naturally to intra-domain RSVP authentication, since 240 all RSVP nodes implicitly trust each other. Using group keys, they 241 extend this trust to the group key server. This is represented in 242 Figure 2. 244 ......GKS1............. 245 : : : : : 246 : : : : : 247 source--R1--R2--R3-----destination 248 | | 249 |<-----domain 1----------------->| 251 Figure 2: Group Key Server within a single security domain 253 A single group key cannot normally be used to cover multiple security 254 domains however, because by definition the different domains do not 255 trust each other and would not be willing to trust the same group key 256 server. For a single group key to be used in several security 257 domains, there is a need for a single group key server, which is 258 trusted by both sides. While this is theoretically possible, in 259 practice it is unlikely that there is a single such entity trusted by 260 both domains. Figure 3 illustrates this setup. 262 ...............GKS1.................... 263 : : : : : : : : 264 : : : : : : : : 265 source--R1--R2--R3--------R4--R5--R6--destination 266 | | | | 267 |<-----domain 1--->| |<-------domain 2----->| 269 Figure 3: A Single Group Key Server across security domains 271 A more practical approach for RSVP operation across security domains, 272 is to use a separate group key server for each security domain, and 273 to use per interface or per neighbor authentication between the two 274 domains. Figure 4 shows this set-up. 276 ....GKS1...... ....GKS2......... 277 : : : : : : : : 278 : : : : : : : : 279 source--R1--R2--R3--------R4--R5--R6--destination 280 | | | | 281 |<-----domain 1--->| |<-------domain 2----->| 283 Figure 4: A group Key Server per security domain 285 As discussed in section 2, group keying can be used in the presence 286 of non-RSVP hops. 288 4. Key Provisioning Methods for RSVP 290 4.1. Static Key Provisioning 292 The simplest way to implement RSVP authentication is to use static, 293 preconfigured keys. Static keying can be used with interface based 294 keys, neighbor based keys or group keys. 296 However, such static key provisioning is expensive on the operational 297 side, since no secure automated mechanism can be used, and initial 298 provisioning as well as key updates require configuration. This 299 method is therefore mostly useful for small deployments, where key 300 changes can be carried out manually, or for deployments with 301 automated configuration tools which support key changes. 303 Static key provisioning is therefore not an ideal model in a large 304 network. 306 Often, the number of interconnection points across two domains where 307 RSVP is allowed to transit is relatively small and well controlled. 308 Also, the different domains may not be in a position to use an 309 infrastructure trusted by both domains to update keys on both sides. 310 Thus, manually configured keys may be applicable to inter-domain RSVP 311 authentication. 313 Since it is not feasible to carry out the key change at the exact 314 same time on both sides, some grace period needs to be implemented 315 during which an RSVP node will accept both the old and the new key. 316 Otherwise, RSVP operation would suffer interruptions. (Note that 317 also with dynamic keying approaches there can be a grace period where 318 two keys are valid at the same time; however, the grace period in 319 manual keying tends to be significantly longer than with dynamic key 320 rollover schemes.) 322 4.2. Dynamic Keying 324 4.2.1. Neighbor and Interface Based Key Negotiation 326 To avoid the problem of manual key provisioning and updates in static 327 key deployments, key negotiation between RSVP neighbors could be used 328 to derive either interface or neighbor based keys. However, existing 329 key negotiation protocols such as IKEv1 [RFC2409] or IKEv2 [RFC4306] 330 may not be appropriate in all environments because of the relative 331 complexity of the protocols and related operations. 333 4.2.2. Dynamic Group Key Distribution 335 With this approach, group keys are dynamically distributed among a 336 set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes 337 a mechanism to distribute group keys to a group of RSVP speakers, 338 using GDOI [RFC3547]. In this solution, a key server authenticates 339 each of the RSVP nodes independently, and then distributes a group 340 key to the entire group. 342 5. Specific Cases 344 5.1. RSVP Notify Messages 346 [RFC3473] introduces the Notify message and allows such Notify 347 messages to be sent in a non-hop-by-hop fashion. As discussed in the 348 Security Considerations section of [RFC3473], this can interfere with 349 RSVP's hop-by-hop integrity and authentication model. [RFC3473] 350 describes how standard IPsec based integrity and authentication can 351 be used to protect Notify messages. We observe that, alternatively, 352 in some environments, group keying may allow use of regular RSVP 353 authentication ([RFC2747]) for protection of non-hop-by-hop Notify 354 messages. For example, this may be applicable to controlled 355 environments where nodes invoking notification requests are known to 356 belong to the same key group as nodes generating Notify messages. 358 5.2. RSVP-TE and GMPLS 360 Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast 361 Reroute [RFC4090] deserves additional considerations. 363 With the facility backup method of Fast Reroute, a backup tunnel from 364 the Point of Local Repair (PLR) to the Merge Point (MP) is used to 365 protect Label Switched Paths (protected LSPs) against the failure of 366 a facility (e.g. a router) located between the PLR and the MP. 367 During the failure of the facility, the PLR redirects a protected LSP 368 inside the backup tunnel and as a result, the PLR and MP then need to 369 exchange RSVP control messages between each other (e.g. for the 370 maintenance of the protected LSP). Some of the RSVP messages between 371 the PLR and MP are sent over the backup tunnel (e.g. a Path message 372 from PLR to MP) while some are directly addressed to the RSVP node 373 (e.g. a Resv message from MP to PLR). During the rerouted period, 374 the PLR and the MP effectively become RSVP neighbors, while they may 375 not be directly connected to each other and thus do not behave as 376 RSVP neighbors in the absence of failure. This point is raised in 377 the Security Considerations section of [RFC4090] that says: "Note 378 that the facility backup method requires that a PLR and its selected 379 merge point trust RSVP messages received from each other." We 380 observe that such environments may benefit from group keying: a group 381 key can be used among a set of routers enabled for Fast Reroute 382 thereby easily ensuring that a PLR and MP authenticate messages from 383 each other, without requiring prior specific configuration of keys, 384 or activation of key update mechanism, for every possible pair of PLR 385 and MP. 387 Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS 388 boundaries (see [RFC4216]), the considerations presented above in 389 section 3.1 and 3.2 apply such that per interface or per neighbor 390 keys can be used between two RSVP neighbors in different ASes 391 (independently of the keying method used by the RSVP router to talk 392 to the RSVP routers in the same AS). 394 [RFC4875] specifies protocol extensions for support of Point-to- 395 Multipoint (P2MP) RSVP-TE. In its security considerations section, 396 [RFC4875] points out that RSVP message integrity mechanisms for hop- 397 by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling. 398 In turn, we observe that the considerations in this document on 399 keying methods apply equally to P2MP RSVP-TE for the hop-by-hop 400 signaling. 402 [RFC4206] defines LSP Hierarchy with GMPLS TE and uses non-hop-by-hop 403 signaling. Because it reuses LSP Hierarchy procedures for some of 404 its operations, P2MP RSVP-TE also uses non-hop-by-hop signaling. 405 Both LSP hierarchy and P2MP RSVP-TE rely on the security mechanisms 406 defined in [RFC3473] and [RFC4206] for non hop-by-hop RSVP-TE 407 signaling. We note that the observation in section 3.1 of this 408 document about use of group keying for protection of non-hop-by-hop 409 messages apply to protection of non-hop-by-hop signaling for LSP 410 Hierarchy and P2MP RSVP- TE. 412 6. Applicability of IPsec for RSVP 414 6.1. General Considerations Using IPsec 416 The discussions about the various keying methods in this document are 417 also applicable when using IPsec to protect RSVP. Note that 418 [RFC2747] states in section 1.2 that IPsec is not an optimal choice 419 to protect RSVP. The key argument is that an IPsec SA and an RSVP SA 420 are not based on the same parameters. However, when using group 421 keying, IPsec can be used to protect RSVP. The potential issues and 422 solutions using group keying are: 424 o [RFC2747] specifies in section 4.2, bullet 3, that both the key 425 identifier and the sending system address are used to uniquely 426 determine the key. In a group keying scenario it would be 427 necessary to either store a list of senders to do this, or to not 428 use the sending system address to determine the key. Both methods 429 are valid, and one of the two approaches must be chosen. The pros 430 and cons are beyond the scope of this document. 431 o Anti-replay protection in a group keying scenario requires some 432 changes to the way [RFC2747] defines anti-replay. Possible 433 solutions are discussed in detail in [I-D.weis-gdoi-mac-tek]). 434 For example, when using counter-based methods with various senders 435 in a single SA, the same counter may be received more than once, 436 this conflicts with [RFC2747], which states that each counter 437 value may only be accepted once. Time based approaches are a 438 solution for group keying scenarios. 440 The document "The Multicast Group Security Architecture" [RFC3740] 441 defines in detail a "Group Security Association" (GSA). This 442 definition is also applicable in the context discussed here, and 443 allows the use of IPsec for RSVP. The existing GDOI standard 444 [RFC3547] contains all relevant policy options to secure RSVP with 445 IPsec, and no extensions are necessary. An example GDOI policy would 446 be to encrypt all packets of the RSVP protocol itself (IP protocol 447 46). A router implementing GDOI and IPsec protocols is therefore 448 able to implement RSVP encryption. 450 6.2. Using IPsec ESP 452 In both tunnel mode and transport mode, ESP does not protect the 453 header (in tunnel mode the outer header). This is an issue with 454 group keying when using ESP to secure the RSVP packets: the packet 455 header could be modified by a man-in-the-middle attack, replacing the 456 destination address with another RSVP router in the network. This 457 router will receive the packet, use the group key to decrypt the 458 encapsulated packet, and then act on the RSVP packet. This way an 459 attacker cannot create new reservations or affect existing ones, but 460 he can "re-direct" reservations to parts of the network off the 461 actual reservation path, thereby potentially denying resources to 462 other applications on that part of the network. 464 6.3. Using IPsec AH 466 The INTEGRITY object defined by [RFC2747] provides integrity 467 protection for RSVP also in a group keying context, as discussed 468 above. IPsec AH is an alternative method to provide integrity 469 protection for RSVP. Both methods provide comparable security. 471 6.4. Applicability of Tunnel Mode 473 IPsec tunnel mode encapsulates the original packet, prepending a new 474 IP tunnel header plus an ESP or AH sub-header. The entire original 475 packet plus the ESP/AH subheader is secured. In the case of ESP the 476 new, outer IP header however is not cryptographically secured in this 477 process. This leads to the problem described in Section 6.2. AH 478 tunnel mode also secures the outer header, and is therefore not 479 subject to these man-in-the-middle attacks. 481 Protecting RSVP packets with IPsec tunnel mode works with any of the 482 above described keying methods (interface, neighbor or group based), 483 as long as there are no non-RSVP nodes on the path. Note that for 484 RSVP messages to be visible and considered at each hop, such a tunnel 485 would not cross routers, but each RSVP node would establish a tunnel 486 with each of its peers, effectively leading to link protection. 488 In the presence of a non-RSVP hop, tunnel mode can not be applied, 489 because a router upstream a non-RSVP hop does not know the next RSVP 490 hop, and can thus not apply the correct tunnel header. This is 491 independent of the key type used. 493 6.5. Applicability of Transport Mode 495 IPsec transport mode, as defined in [RFC4303] is not suitable for 496 securing RSVP Path messages, since those messages preserve the 497 original source and destination. [RFC4303] states explicitly that 498 "the use of transport mode by an intermediate system (e.g., a 499 security gateway) is permitted only when applied to packets whose 500 source address (for outbound packets) or destination address (for 501 inbound packets) is an address belonging to the intermediate system 502 itself." This would not be the case for RSVP Path messages. 504 7. End Host Considerations 506 Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches] 507 are used, RSVP signaling is controlled by end systems and not 508 routers. As discussed in [RFC4230], RSVP allows both user-based 509 security and host-based security. User-based authentication aims at 510 "providing policy based admission control mechanism based on user 511 identities or application." To identify the user or the application, 512 a policy element called AUTH_DATA, which is contained in the 513 POLICY_DATA object, is created by the RSVP daemon at the user's host 514 and transmitted inside the RSVP message. This way, a user may 515 authenticate to the Policy Decision Point (or directly to the first 516 hop router). Host-based security relies on the same mechanisms as 517 between routers (i.e. INTEGRITY object) as specified in [RFC2747]. 518 For host-based security, interface or neighbor based keys may be 519 used, however, key management with pre-shared keys can be difficult 520 in a large scale deployment, as described in section 4. In principle 521 an end host can also be part of a group key scheme, such as GDOI. If 522 the end systems are part of the same zone of trust as the network 523 itself, group keying can be extended to include the end systems. If 524 the end systems and the network are in different zones of trust, 525 group keying cannot be used. 527 8. Applicability to Other Architectures and Protocols 529 While, so far, this document only discusses RSVP security assuming 530 the traditional RSVP model as defined by [RFC2205] and [RFC2747], the 531 analysis is also applicable to other RSVP deployment models as well 532 as to similar protocols: 534 o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This 535 scheme defines aggregation of individual RSVP reservations, and 536 discusses use of RSVP authentication for the signaling messages. 537 Group keying is applicable to this scheme, particularly when 538 automatic Deaggregator discovery is used, since in that case, the 539 Aggregator does not know ahead of time which Deaggregator will 540 intercept the initial end-to-end RSVP Path message. 541 o Generic Aggregate Resource ReSerVation Protocol (RSVP) 542 Reservations [RFC4860]: This document also discusses aggregation 543 of individual RSVP reservations. Here again, group keying applies 544 and is mentioned in the Security Considerations section. 545 o Aggregation of Resource ReSerVation Protocol (RSVP) Reservations 546 over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): This scheme also 547 defines a form of aggregation of RSVP reservation but this time 548 over MPLS TE Tunnels. Similarly, group keying may be used in such 549 an environment. 550 o Pre-Congestion Notification (PCN): [I-D.ietf-pcn-architecture] 551 defines an architecture for flow admission and termination based 552 on aggregated pre-congestion information. One deployment model 553 for this architecture is based on IntServ over DiffServ: the 554 DiffServ region is PCN-enabled, RSVP signalling is used end-to-end 555 but the PCN-domain is a single RSVP hop, i.e. only the PCN- 556 boundary-nodes process RSVP messages. In this scenario, RSVP 557 authentication may be required among PCN-boundary-nodes and the 558 considerations about keying approaches discussed earlier in this 559 document apply. In particular, group keying may facilitate 560 operations since the ingress PCN-boundary-node does not 561 necessarily know ahead of time which Egress PCN-boundary-node will 562 intercept and process the initial end-to-end Path message. Note 563 that from the viewpoint of securing end-to-end RSVP, there are a 564 lot of similarities in scenarios involving RSVP Aggregation over 565 aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP 566 Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP 567 (Aggregation) over PCN ingress-egress aggregates. 569 9. Summary 571 The following table summarizes the various approaches for RSVP 572 keying, and their applicability to various RSVP scenarios. In 573 particular, such keying can be used for RSVP authentication (e.g., 574 using RSVP authentication or IPsec AH) and/ or for RSVP encryption 575 (e.g., using IPsec ESP in tunnel mode). 577 +-----------------------------+--------------------+----------------+ 578 | | Neighbor/interface | Group keys | 579 | | based keys | | 580 +-----------------------------+--------------------+----------------+ 581 | Works intra-domain | Yes | Yes | 582 | Works inter-domain | Yes | No | 583 | Works over non-RSVP hops | No | Yes (1) | 584 | Dynamic keying | Yes (IKE) | Yes (eg GDOI) | 585 +-----------------------------+--------------------+----------------+ 587 Table 1: Overview of keying approaches and their applicability 589 (1): RSVP authentication with group keys works over non-RSVP nodes; 590 RSVP encryption with IPsec ESP Tunnel mode does not. 592 We also make the following observations: 594 o All key types can be used statically, or with dynamic key 595 negotiation. This impacts the managability of the solution, but 596 not the applicability itself. 597 o For encryption of RSVP messages IPsec ESP in tunnel mode can be 598 used. There is however a security concern, see Section 6.2. 600 o There are some special cases in RSVP, like non-RSVP hosts, the 601 "Notify" message (as discussed in section 5.1), the various RSVP 602 deployment models discussed in Section 8 and MPLS Traffic 603 Engineering and GMPLS discussed in section 5.2 , which would 604 benefit from a group keying approach. 606 10. Security Considerations 608 This entire document discusses RSVP security; this section describes 609 a specific security considerations relating to subverted RSVP nodes 611 10.1. Subverted RSVP Nodes 613 A subverted node is defined here as an untrusted node, for example 614 because an intruder has gained control over it. Since RSVP 615 authentication is hop-by-hop and not end-to-end, a subverted node in 616 the path breaks the chain of trust. This is to a large extent 617 independent of the type of keying used. 619 For interface or per-neighbor keying, the subverted node can now 620 introduce fake messages to its neighbors. This can be used in a 621 variety of ways, for example by changing the receiver address in the 622 Path message, or by generating fake Path messages. This allows path 623 states to be created on every RSVP router along any arbitrary path 624 through the RSVP domain. That in itself could result in a form of 625 Denial of Service by allowing exhaustion of some router resources 626 (e.g. memory). The subverted node could also generate fake Resv 627 messages upstream corresponding to valid Path states. In doing so, 628 the subverted node can reserve excessive amounts of bandwidth thereby 629 possibly performing a denial of service attack. 631 Group keying allows the additional abuse of sending fake RSVP 632 messages to any node in the RSVP domain, not just adjacent RSVP 633 nodes. However, in practice this can be achieved to a large extent 634 also with per neighbor or interface keys, as discussed above. 635 Therefore the impact of subverted nodes on the path is comparable, 636 independently whether per-interface, per-neighbor or group keys are 637 used. 639 11. Acknowledgements 641 The authors would like to thank everybody who provided feedback on 642 this document. Specific thanks to Bob Briscoe, Hannes Tschofenig and 643 Brian Weis. 645 12. Changes to Previous Version 647 This section provides a change log. It will be removed in the final 648 document: 650 12.1. changes from behringer-00 to behringer-01 652 o New section "Applicability to Other Architectures and Protocols": 653 Goal is to clarify the scope of this document: The idea presented 654 here is also applicable to other architectures 655 (PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc. 656 o Clarified the scope of this document versus RFC4230 (in the 657 introduction, last paragraph). 658 o Added a section on "End Host Considerations". 659 o Expanded section 5.5 (RSVP Encryption) to clarify that GDOI 660 contains all necessary mechanisms to do RSVP encrpytion. 661 o Tried to clarify the "trust to do what?" question raised by Bob 662 Briscoe in a mail on 26 Jul 2007. See the section on trust model. 663 o Lots of small editorial changes (references, typos, figures, etc). 664 o Added an Acknowledgements section. 666 12.2. changes from behringer-01 to ietf-00 668 o various edits to make it clearer that draft-weis-gdoi-for-rsvp is 669 an example of how dynamic group keying could be achieved for RSVP 670 and not necessarily the recommended solution 672 12.3. changes from ietf-00 to ietf-01 674 o Significant re-structuring of the entire document, to improve the 675 flow, and provide more consistency in various sections. 676 o Moved the "Subverted RSVP nodes" discussion into the security 677 considerations section. 678 o Added a "summary" section. 679 o Complete re-write of the old section 5.5 (RSVP encryption), and 680 "promotion" to a separate section. 681 o Changed reference ID.weis-gdoi-for-rsvp to the new draft ID.weis- 682 gdoi-mac-tek 683 o in several places, explicitly mentioned "encryption" for RSVP (in 684 parallel to authentication). 685 o Various minor edits. 687 12.4. changes from ietf-01 to ietf-02 689 o Re-wrote and re-structured the section on IPsec (section 6). 690 o Re-wrote the section on RSVP-TE and GMPLS (section 5.2). 692 o Various editorial changes. 694 13. Informative References 696 [I-D.ietf-pcn-architecture] 697 Eardley, P., "Pre-Congestion Notification (PCN) 698 Architecture", draft-ietf-pcn-architecture-08 (work in 699 progress), October 2008. 701 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 702 Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP 703 Proxy Approaches", 704 draft-ietf-tsvwg-rsvp-proxy-approaches-06 (work in 705 progress), October 2008. 707 [I-D.weis-gdoi-mac-tek] 708 Weis, B. and S. Rowles, "GDOI Generic Message 709 Authentication Code Policy", draft-weis-gdoi-mac-tek-00 710 (work in progress), July 2008. 712 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 713 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 714 Functional Specification", RFC 2205, September 1997. 716 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 717 (IKE)", RFC 2409, November 1998. 719 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 720 Authentication", RFC 2747, January 2000. 722 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 723 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 724 RFC 3175, September 2001. 726 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 727 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 728 Tunnels", RFC 3209, December 2001. 730 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 731 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 732 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 734 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 735 Group Domain of Interpretation", RFC 3547, July 2003. 737 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 738 Signature Option", RFC 3562, July 2003. 740 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 741 Architecture", RFC 3740, March 2004. 743 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 744 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 745 May 2005. 747 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 748 Hierarchy with Generalized Multi-Protocol Label Switching 749 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 751 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 752 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 753 November 2005. 755 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 756 Properties", RFC 4230, December 2005. 758 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 759 RFC 4303, December 2005. 761 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 762 RFC 4306, December 2005. 764 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 765 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 766 RFC 4804, February 2007. 768 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 769 Davenport, "Generic Aggregate Resource ReSerVation 770 Protocol (RSVP) Reservations", RFC 4860, May 2007. 772 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 773 "Extensions to Resource Reservation Protocol - Traffic 774 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 775 Switched Paths (LSPs)", RFC 4875, May 2007. 777 Authors' Addresses 779 Michael H. Behringer 780 Cisco Systems Inc 781 Village d'Entreprises Green Side 782 400, Avenue Roumanille, Batiment T 3 783 Biot - Sophia Antipolis 06410 784 France 786 Email: mbehring@cisco.com 787 URI: http://www.cisco.com 789 Francois Le Faucheur 790 Cisco Systems Inc 791 Village d'Entreprises Green Side 792 400, Avenue Roumanille, Batiment T 3 793 Biot - Sophia Antipolis 06410 794 France 796 Email: flefauch@cisco.com 797 URI: http://www.cisco.com 799 Full Copyright Statement 801 Copyright (C) The IETF Trust (2008). 803 This document is subject to the rights, licenses and restrictions 804 contained in BCP 78, and except as set forth therein, the authors 805 retain all their rights. 807 This document and the information contained herein are provided on an 808 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 809 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 810 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 811 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 812 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 813 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 815 Intellectual Property 817 The IETF takes no position regarding the validity or scope of any 818 Intellectual Property Rights or other rights that might be claimed to 819 pertain to the implementation or use of the technology described in 820 this document or the extent to which any license under such rights 821 might or might not be available; nor does it represent that it has 822 made any independent effort to identify any such rights. Information 823 on the procedures with respect to rights in RFC documents can be 824 found in BCP 78 and BCP 79. 826 Copies of IPR disclosures made to the IETF Secretariat and any 827 assurances of licenses to be made available, or the result of an 828 attempt made to obtain a general license or permission for the use of 829 such proprietary rights by implementers or users of this 830 specification can be obtained from the IETF on-line IPR repository at 831 http://www.ietf.org/ipr. 833 The IETF invites any interested party to bring to its attention any 834 copyrights, patents or patent applications, or other proprietary 835 rights that may cover technology that may be required to implement 836 this standard. Please address the information to the IETF at 837 ietf-ipr@ietf.org.