idnits 2.17.1 draft-ietf-tsvwg-rsvp-security-groupkeying-01.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 751. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 762. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 775. 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 (July 11, 2008) is 5767 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-03 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-rsvp-proxy-approaches-04 == 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: January 12, 2009 July 11, 2008 7 Applicability of Keying Methods for RSVP Security 8 draft-ietf-tsvwg-rsvp-security-groupkeying-01.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 January 12, 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. For example, the Group Domain of Interpretation 44 (GDOI) could be used to distribute group keys to RSVP nodes. The 45 present document also discusses applicability of group keying to RSVP 46 encryption. 48 Table of Contents 50 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 51 2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 3 52 3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5 53 3.1. Interface and neighbor based keys . . . . . . . . . . . . 5 54 3.2. Group keys . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 7 56 4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 7 57 4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8 58 4.2.1. Neighbor and Interface Based Key Negotiation . . . . . 8 59 4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 8 60 5. Specific Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 8 62 5.2. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 9 64 6.1. Applicability of IPsec ESP . . . . . . . . . . . . . . . . 10 65 6.2. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 10 66 6.3. Applicability of Transport Mode . . . . . . . . . . . . . 11 67 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 11 68 8. Applicability to Other Architectures and Protocols . . . . . . 11 69 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 10.1. Subverted RSVP Nodes . . . . . . . . . . . . . . . . . . . 13 72 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 73 12. Changes to Previous Version . . . . . . . . . . . . . . . . . 14 74 12.1. changes from behringer-00 to behringer-01 . . . . . . . . 14 75 12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 14 76 12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 15 77 13. Informative References . . . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 79 Intellectual Property and Copyright Statements . . . . . . . . . . 18 81 1. Introduction and Problem Statement 83 The Resource reSerVation Protocol [RFC2205] allows hop-by-hop 84 authentication of RSVP neighbors, as specified in [RFC2747]. In this 85 mode, an integrity object is attached to each RSVP message to 86 transmit a keyed message digest. This message digest allows the 87 recipient to verify the authenticity of the RSVP node that sent the 88 message, and to validate the integrity of the message. Through the 89 inclusion of a sequence number in the scope of the digest, the digest 90 also offers replay protection. 92 [RFC2747] does not dictate how the key for the integrity operation is 93 derived. Currently, most implementations of RSVP use a statically 94 configured key, per interface or per neighbor. However, to manually 95 configure key per router pair across an entire network is 96 operationally hard, especially for key changes. Effectively, many 97 users of RSVP therefore resort to the same key throughout their RSVP 98 network, and change it rarely if ever, because of the operational 99 burden. [RFC3562] however recommends regular key changes, at least 100 every 90 days. 102 [I-D.weis-gdoi-mac-tek] provides an example of how group keys could 103 be dynamically distributed to a set of RSVP routers and updated, 104 using GDOI ([RFC3547]) for the actual key distribution. 106 The present document discusses the various keying methods and their 107 applicability to different RSVP deployment environments, for both 108 message integrity and encryption. It does not mandate any particular 109 method, but is meant as a comparative guideline to understand where 110 each RSVP keying method is best deployed, and its limitations. 111 Furthermore, it discusses how RSVP hop by hop authentication is 112 impacted in the presence of non-RSVP nodes, or subverted nodes, in 113 the reservation path. 115 The document "RSVP Security Properties" ([RFC4230]) provides an 116 overview of RSVP security, including RSVP Cryptographic 117 Authentication [RFC2747], but does not discuss key management. It 118 states that "RFC 2205 assumes that security associations are already 119 available". The present document focuses specifically on key 120 management with different key types, including group keys. Therefore 121 this document complements [RFC4230]. 123 2. The RSVP Hop-by-Hop Trust Model 125 Many protocol security mechanisms used in networks require and use 126 per peer authentication. Each hop authenticates its neighbor with a 127 shared key or certificate. This is also the model used for RSVP. 129 Trust in this model is transitive. Each RSVP node trusts explicitely 130 only its RSVP next hop peers, through the message digest contained in 131 the INTEGRITY object. The next hop RSVP speaker in turn trusts its 132 own peers and so on. See also the document "RSVP security 133 properties" [RFC4230] for more background. 135 The keys used for generating the RSVP messages can, in particular, be 136 group keys (for example distributed via GDOI [RFC3547], as discussed 137 in [I-D.weis-gdoi-mac-tek]). 139 The trust an RSVP node has to another RSVP node has an explicit and 140 an implicit component. Explicitely the node trusts the other node to 141 maintain the RSVP messages intact or confidential, depending on 142 whether authentication or encryption (or both) is used. This means 143 only that the message has not been altered or seen by another, non- 144 trusted node. Implicitely each node trusts each other node with 145 which it has a trust relationship established via the mechanisms here 146 to adhere to the protocol specifications laid out by the various 147 standards. Note that in any group keying scheme like GDOI a node 148 trusts explicitely as well as implicitely all the other members of 149 the group. 151 The RSVP protocol can operate in the presence of a non-RSVP router in 152 the path from the sender to the receiver. The non-RSVP hop will 153 ignore the RSVP message and just pass it along. The next RSVP node 154 can then process the RSVP message. For RSVP authentication or 155 encryption to work in this case, the key used for computing the RSVP 156 message digest needs to be shared by the two RSVP neighbors, even if 157 they are not IP neighbors. However, in the presence of non-RSVP 158 hops, while an RSVP node always know the next IP hop before 159 forwarding an RSVP Message, it does not always know the RSVP next 160 hop. In fact, part of the role of a Path message is precisely to 161 discover the RSVP next hop (and to dynamically re-discover it when it 162 changes, for example because of a routing change). Thus, the 163 presence of non-RSVP hops impacts operation of RSVP authentication or 164 encryption and may influence the selection of keying approaches. 166 Figure 1 illustrates this scenario. R2 in this picture does not 167 participate in RSVP, the other nodes do. In this case, R2 will pass 168 on any RSVP messages unchanged, and will ignore them. 170 ----R3--- 171 / \ 172 sender----R1---R2(*) R4----receiver 173 \ / 174 ----R5--- 175 (*) Non-RSVP hop 177 Figure 1: A non-RSVP Node in the path 179 This creates a challenge for RSVP authentication and encrpytion. In 180 the presence of a non-RSVP hop, with some RSVP messages such as a 181 PATH message, an RSVP router does not know the RSVP next hop for that 182 message at the time of forwarding it. For example, in Figure 1, R1 183 knows that the next IP hop for a Path message addresed to the 184 receiver is R2, but it does necessarily not know if the RSVP next hop 185 is R3 or R5. 187 This means that per interface and per neighbor keys cannot easily be 188 used in the presence of non-RSVP routers on the path between senders 189 and receivers. 191 By contrast, group keying will naturally work in the presence of non- 192 RSVP routers. Referring back to Figure 1, with group keying, R1 193 would use the group key to sign a Path message addressed to the 194 receiver and forwards it to R2. Being a non-RSVP node, R2 and will 195 ignore and forward the Path message to R3 or R5 depending on the 196 current shortest path as determined by routing. Whether it is R3 or 197 R5, the RSVP router that receives the Path message will be able to 198 authenticate it successfully with the group key. 200 3. Applicability of Key Types for RSVP 202 3.1. Interface and neighbor based keys 204 Most current RSVP authentication implementations support interface 205 based RSVP keys. When the interface is point-to-point (and therefore 206 an RSVP router only has a single RSVP neighbor on each interface), 207 this is equivalent to neighbor based keys in the sense that a 208 different key is used for each neighbor. However, when the interface 209 is multipoint, all RSVP speakers on a given subnet have to share the 210 same key in this model, which makes it unsuitable for deployment 211 scenarios where different trust groups share a subnet, for example 212 Internet exchange points. In such a case, neighbor based keys are 213 required. 215 With neighbor based keys, an RSVP key is bound to an interface plus a 216 neighbor on that interface. It allows the distinction of different 217 trust groups on a single subnet. (Assuming that layer-2 security is 218 correctly implemented to prevent layer-2 attacks.) 220 Per interface and per neighbor keys can be used within a single 221 security domain. As mentioned above, per interface keys are only 222 applicable when all the nodes reachable on the specific interface 223 belong to the same security domain. 225 These key types can also be used between security domains, since they 226 are specific to a particular interface or neighbor. Again, interface 227 level keys can only be deployed safely when all the reachable 228 neighbors on the interface belong to the same security domain. 230 As discussed in the previous section, per neighbor and per interface 231 keys can not be used in the presence of non-RSVP hops. 233 3.2. Group keys 235 Here, all members of a group of RSVP nodes share the same key. This 236 implies that a node uses the same key regardless of the next RSVP hop 237 that will process the message (within the group of nodes sharing the 238 particular key). It also implies that a node will use the same key 239 on the receiving as on the sending side (when exchanging RSVP 240 messages within the group). 242 Group keys apply naturally to intra-domain RSVP authentication, since 243 all RSVP nodes implicitely trust each other. Using group keys, they 244 extend this trust to the group key server. This is represented in 245 Figure 2. 247 ......GKS1............. 248 : : : : : 249 : : : : : 250 source--R1--R2--R3-----destination 251 | | 252 |<-----domain 1----------------->| 254 Figure 2: Group Key Server within a single security domain 256 A single group key cannot normally be used to cover multiple security 257 domains however, because by definition the different domains do not 258 trust each other and would not be willing to trust the same group key 259 server. For a single group key to be used in several security 260 domains, there is a need for a single group key server, which is 261 trusted by both sides. While this is theoretically possible, in 262 practice it is unlikely that there is a single such entity trusted by 263 both domains. Figure 3 illustrates this setup. 265 ...............GKS1.................... 266 : : : : : : : : 267 : : : : : : : : 268 source--R1--R2--R3--------R4--R5--R6--destination 269 | | | | 270 |<-----domain 1--->| |<-------domain 2----->| 272 Figure 3: A Single Group Key Server across security domains 274 A more practical approach for RSVP operation across security domains, 275 is to use a separate group key server for each security domain, and 276 to use per interface or per neighbor authentication between the two 277 domains. Figure 4 shows this set-up. 279 ....GKS1...... ....GKS2......... 280 : : : : : : : : 281 : : : : : : : : 282 source--R1--R2--R3--------R4--R5--R6--destination 283 | | | | 284 |<-----domain 1--->| |<-------domain 2----->| 286 Figure 4: A group Key Server per security domain 288 As discussed in section 2, group keying can be used in the presence 289 of non-RSVP hops. 291 4. Key Provisioning Methods for RSVP 293 4.1. Static Key Provisioning 295 The simplest way to implement RSVP authentication is to use static, 296 preconfigured keys. Static keying can be used with interface based 297 keys, neighbor based keys or group keys. 299 However, such static key provisioning is expensive on the operational 300 side, since no secure automated mechanism can be used, and initial 301 provisioning as well as key updates require configuration. This 302 method is therefore mostly useful for small deployments, where key 303 changes can be carried out manually, or for deployments with 304 automated configuration tools which support key changes. 306 Static key provisioning is therefore not an ideal model in a large 307 network. 309 Often, the number of interconnection points across two domains where 310 RSVP is allowed to transit is relatively small and well controlled. 311 Also, the different domains may not be in a position to use an 312 infrastructure trusted by both domains to update keys on both sides. 313 Thus, manually configured keys may be applicable to inter-domain RSVP 314 authentication. 316 Since it is not feasible to carry out the key change at the exact 317 same time on both sides, some grace period needs to be implemented 318 during which an RSVP node will accept both the old and the new key. 319 Otherwise, RSVP operation would suffer interruptions. (Note that 320 also with dynamic keying approaches there can be a grace period where 321 two keys are valid at the same time; however, the grace period in 322 manual keying tends to be significantly longer than with dynamic key 323 rollover schemes.) 325 4.2. Dynamic Keying 327 4.2.1. Neighbor and Interface Based Key Negotiation 329 To avoid the problem of manual key provisioning and updates in static 330 key deployments, key negotiation between RSVP neighbors could be used 331 to derive either interface or neighbor based keys. However, existing 332 key negotiation protocols such as IKEv1 [RFC2409] or IKEv2 [RFC4306] 333 may not be appropriate in all environments because of the relative 334 complexity of the protocols and related operations. 336 4.2.2. Dynamic Group Key Distribution 338 With this approach, group keys are dyanmically distributed among a 339 set of RSVP routers. For example, [I-D.weis-gdoi-mac-tek] describes 340 a mechanism to distribute group keys to a group of RSVP speakers, 341 using GDOI [RFC3547]. In this solution, a key server authenticates 342 each of the RSVP nodes independently, and then distributes a group 343 key to the entire group. 345 5. Specific Cases 347 5.1. RSVP Notify Messages 349 [RFC3473] introduces the Notify message and allows such Notify 350 messages to be sent in a non-hop-by-hop fashion. As discussed in the 351 Security Considerations section of [RFC3473], this can interfere with 352 RSVP's hop-by-hop integrity and authentication model. [RFC3473] 353 describes how standard IPsec based integrity and authentication can 354 be used to protect Notify messages. We observe that, alternatively, 355 in some environments, group keying may allow use of regular RSVP 356 authentication ([RFC2747]) for protection of non-hop-by-hop Notify 357 messages. For example, this may be applicable to controlled 358 environments where nodes invoking notification requests are known to 359 belong to the same key group as nodes generating Notify messages. 361 5.2. RSVP-TE 363 Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast 364 Reroute [RFC4090] deserve additional considerations. For example, 365 with the facility backup method of Fast Reroute, a backup tunnel from 366 the Point of Local Repair (PLR) to the Merge Point (MP) is used to 367 protect Label Switched Paths (protected LSPs) from the failure of a 368 facility (e.g. a router) located between the PLR and the MP. During 369 the failure of the facility, the PLR redirects a protected LSP inside 370 the backup tunnel and also exchange RSVP control message for the 371 maintenance the protected LSP over the backup tunnel. Therefore, 372 during the rerouted period, the PLR and the MP effectively become 373 RSVP neighbors while they may not be directly connected to each other 374 and thus do not behave as RSVP neighbors in the absence of failure. 376 This point is raised in the Security Considerations section of 377 [RFC4090] that says: "Note that the facility backup method requires 378 that a PLR and its selected merge point trust RSVP messages received 379 from each other." We observe that such environments may benefit from 380 group keying since the group key could also be easily used between 381 the PLR and the MP. 383 6. Applicability of IPsec for RSVP 385 The discussions about the various keying methods in this document are 386 applicable to the built-in authentication in the RSVP protocol, using 387 the INTEGRITY object, as defined in [RFC2747]. In principle, they 388 are also applicable to using IPsec to protect RSVP, however, 389 [RFC2747] discusses in section 1.2 why IPsec is not an optimal choice 390 to protect RSVP. The key argument is that an IPsec SA and an RSVP SA 391 are not based on the same parameters. We believe that group keying 392 may solve some of the issues mentioned. [Editorial note: Detailed 393 discussion will be added in the next version of the document.] 395 To address specific requirements for RSVP encryption, we focus the 396 discussion here on IPsec ESP (Encapsulation security payload; 397 [RFC4303]). 399 IPsec Authentication Header (AH) is currently not considered in this 400 document, since authentication is built into RSVP through the 401 mechansims defined by [RFC2747]. 403 6.1. Applicability of IPsec ESP 405 The keying approaches discussed in this document can also be used to 406 encrypt the RSVP messages using IPsec [RFC4301], instead of, or in 407 addition to authenticating them. The same considerations apply for 408 this case as discussed above for the authentication case. Group keys 409 are applicable only within a trusted domain, but they allow operation 410 through non-RSVP speakers without further configuration. Per 411 interface or per neighbor keys work also inter-domain, but do not 412 operate in the presence of a non-RSVP router. 414 The existing GDOI standard as described in [RFC3547] contains all 415 relevant policy options to allow for RSVP encryption, and no 416 extensions are necessary. An example GDOI policy would be to encrypt 417 all packets of the RSVP protocol itself (IP protocol 46). A router 418 implementing GDOI and IPsec is therefore able to implement RSVP 419 encryption. 421 Since in both tunnel mode and transport mode ESP does not protect the 422 header (in tunnel mode the outer header), there is an issue with 423 group keying, when using ESP to secure the RSVP packets: The packet 424 header could be modified by a man-in-the-middle attack, replacing the 425 destination address with another RSVP router in the network. This 426 router will receive the packet, use the group key to decrypt the 427 encapsulated packet, and then act on the RSVP packet. This way an 428 attacker cannot create new reservations or affect existing ones, but 429 he can "re-direct" reservations to parts of the network off the 430 actual reservation path, thereby potentially denying resources to 431 other applications on that part of the network. 433 6.2. Applicability of Tunnel Mode 435 IPsec tunnel mode for ESP encapsulates and encypts the original 436 packet, prepending a new IP tunnel header plus an ESP sub-header. 437 The entire original packet is encrypted, and the integrity of the 438 original packet plus the ESP subheader is secured. The new, outer IP 439 header however is not cryptographically secured in this process. 441 Protecting RSVP packets with IPsec ESP tunnel mode works with any of 442 the above described keying methods (interface, neighbor or group 443 based), as long as there are no non-RSVP nodes on the path. Note 444 that for RSVP messages to be visible and considered at each hop, such 445 a tunnel would not cross routers, but each RSVP node would establish 446 a tunnel with each of its peers, effectively leading to link 447 protection. 449 In the presence of a non-RSVP hop, tunnel mode can not be applied, 450 because a router upstream a non-RSVP hop does not know the next RSVP 451 hop, and can thus not apply the correct tunnel header. This is 452 independent of the key type used. 454 6.3. Applicability of Transport Mode 456 IPsec transport mode for ESP, as defined in [RFC4303] is not suitable 457 for securing RSVP Path messages, since those messages preserve the 458 original source and destination. [RFC4303] states explicitely that 459 "the use of transport mode by an intermediate system (e.g., a 460 security gateway) is permitted only when applied to packets whose 461 source address (for outbound packets) or destination address (for 462 inbound packets) is an address belonging to the intermediate system 463 itself. This would not be the case for RSVP Path messages. 465 7. End Host Considerations 467 Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches] 468 are used, RSVP signaling is controlled by end systems and not 469 routers. As discussed in [RFC4230], RSVP allows both user-based 470 security and host-based security. User-based authentication aims at 471 "providing policy based admission control mechanism based on user 472 identities or application." To identify the user or the application, 473 a policy element called AUTH_DATA, which is contained in the 474 POLICY_DATA object, is created by the RSVP daemon at the user's host 475 and transmitted inside the RSVP message. This way, a user may 476 authenticate to the Policy Decision Point (or directly to the first 477 hop router). Host-based security relies on the same mechanisms as 478 between routers (i.e. INTEGRITY object ) as specified in [RFC2747]. 479 For host-based security, interface or neighbor based keys may be 480 used, however, key management with pre-shared keys can be difficult 481 in a large scale deployment, as described in section 4. In principle 482 an end host can also be part of a group key scheme, such as GDOI. If 483 the end systems are part of the same zone of trust as the network 484 itself, group keying can be extended to include the end systems. If 485 the end systems and the network are in different zones of trust, 486 group keying cannot be used. 488 8. Applicability to Other Architectures and Protocols 490 While, so far, this document only discusses RSVP security assuming 491 the traditional RSVP model as defined by [RFC2205] and [RFC2747], the 492 analysis is also applicable to other RSVP deployment models as well 493 as to similar protocols: 495 o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This 496 scheme defines aggregation of individual RSVP reservations, and 497 discusses use of RSVP authentication for the signaling messages. 498 Group keying is applicable to this scheme, particularly when 499 automatic Deaggregator discovery is used, since in that case, the 500 Aggregator does not know ahead of time which Deaggregator will 501 intercept the initial end-to-end RSVP Path message. 502 o Generic Aggregate Resource ReSerVation Protocol (RSVP) 503 Reservations [RFC4860]: This document also discusses aggregation 504 of individual RSVP reservations. Here again, group keying applies 505 and is mentioned in the Security Considerations section. 506 o Aggregation of Resource ReSerVation Protocol (RSVP) Reservations 507 over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): This scheme also 508 defines a form of aggregation of RSVP reservation but this time 509 over MPLS TE Tunnels. Similarly, group keying may be used in such 510 an environment. 511 o Pre-Congestion Notification (PCN): [I-D.ietf-pcn-architecture] 512 defines an architecture for flow admission and termination based 513 on aggregated pre-congestion information. One deployment model 514 for this architecture is based on IntServ over DiffServ: the 515 DiffServ region is PCN-enabled, RSVP signalling is used end-to-end 516 but the PCN-domain is a single RSVP hop, i.e. only the PCN- 517 boundary-nodes process RSVP messages. In this scenario, RSVP 518 authentication may be required among PCN-boundary-nodes and the 519 considerations about keying approaches discussed earlier in this 520 document apply. In particular, group keying may facilitate 521 operations since the ingress PCN-boundary-node does not 522 necessarily know ahead of time which Egress PCN-boundary-node will 523 intercept and process the initial end-to-end Path message. Note 524 that from the viewpoint of securing end-to-end RSVP, there are a 525 lot of similarities in scenarios involving RSVP Aggregation over 526 aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP 527 Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP 528 (Aggregation) over PCN ingress-egress aggregates. 530 9. Summary 532 The following table summarizes the various approaches for RSVP 533 keying, and their applicability to various RSVP scenarios. In 534 particular, such keying can be used for RSVP Authentication and/ or 535 for RSVP Encryption (using ESP in Tunnel mode). 537 +-----------------------------+--------------------+----------------+ 538 | | Neighbor/interface | Group keys | 539 | | based keys | | 540 +-----------------------------+--------------------+----------------+ 541 | Works intra-domain | Yes | Yes | 542 | Works inter-domain | Yes | No | 543 | Works over non-RSVP hops | No | Yes (1) | 544 | Dynamic keying | Yes (IKE) | Yes (eg GDOI) | 545 +-----------------------------+--------------------+----------------+ 547 Table 1: Overview of keying approaches and their applicability 549 (1): RSVP authentication with group keys works over non-RSVP nodes; 550 RSVP encryption with IPsec ESP Tunnel mode does not. 552 We also make the following observations: 554 o All key types can be used statically, or with dynamic key 555 negotiation. This impacts the managability of the solution, but 556 not the applicability itself. 557 o For encryption of RSVP messages IPsec ESP in tunnel mode can be 558 used. There is however a security concern, see Section 6.1. 559 o There are some special cases in RSVP, like non-RSVP hosts, the 560 "notify" message, the various RSVP deployment models discussed in 561 Section 8 and MPLS traffic engineering, which would benefit from a 562 group keying approach. 564 10. Security Considerations 566 This entire document discusses RSVP security; this section describes 567 a specific security considerations relating to subverted RSVP nodes 569 10.1. Subverted RSVP Nodes 571 A subverted node is defined here as an untrusted node, for example 572 because an intruder has gained control over it. Since RSVP 573 authentication is hop-by-hop and not end-to-end, a subverted node in 574 the path breaks the chain of trust. This is to a large extent 575 independent of the type of keying used. 577 For interface or per-neighbor keying, the subverted node can now 578 introduce fake messages to its neighbors. This can be used in a 579 variety of ways, for example by changing the receiver address in the 580 Path message, or by generating fake Path messages. This allows path 581 states to be created on every RSVP router along any arbitrary path 582 through the RSVP domain. That in itself could result in a form of 583 Denial of Service by allowing exhaustion of some router resources 584 (e.g. memory). The subverted node could also generate fake Resv 585 messages upstream corresponding to valid Path states. In doing so, 586 the subverted node can reserve excessive amounts of bandwidth thereby 587 possibly performing a denial of service attack. 589 Group keying allows the additional abuse of sending fake RSVP 590 messages to any node in the RSVP domain, not just adjacent RSVP 591 nodes. However, in practice this can be achieved to a large extent 592 also with per neighbor or interface keys, as discussed above. 593 Therefore the impact of subverted nodes on the path is comparable, 594 independently whether per-interface, per-neighbor or group keys are 595 used. 597 11. Acknowledgements 599 The authors would like to thank everybody who provided feedback on 600 this document. Specific thanks to Bob Briscoe, Hannes Tschofenig and 601 Brian Weis. 603 12. Changes to Previous Version 605 This section provides a change log. It will be removed in the final 606 document: 608 12.1. changes from behringer-00 to behringer-01 610 o New section "Applicability to Other Architectures and Protocols": 611 Goal is to clarify the scope of this document: The idea presented 612 here is also applicable to other architectures 613 (PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc. 614 o Clarified the scope of this document versus RFC4230 (in the 615 introduction, last paragraph). 616 o Added a section on "End Host Considerations". 617 o Expanded section 5.5 (RSVP Encryption) to clarify that GDOI 618 contains all necessary mechanisms to do RSVP encrpytion. 619 o Tried to clarify the "trust to do what?" question raised by Bob 620 Briscoe in a mail on 26 Jul 2007. See the section on trust model. 621 o Lots of small editorial changes (references, typos, figures, etc). 622 o Added an Acknowledgements section. 624 12.2. changes from behringer-01 to ietf-00 626 o various edits to make it clearer that draft-weis-gdoi-for-rsvp is 627 an example of how dynamic group keying could be achieved for RSVP 628 and not necesarily the recommended solution 630 12.3. changes from ietf-00 to ietf-01 632 o Significant re-structuring of the entire document, to improve the 633 flow, and provide more consistency in various sections. 634 o Moved the "Subverted RSVP nodes" discussion into the security 635 considerations section. 636 o Added a "summary" section. 637 o Complete re-write of the old section 5.5 (RSVP encryption), and 638 "promotion" to a separate section. 639 o Changed reference ID.weis-gdoi-for-rsvp to the new draft ID.weis- 640 gdoi-mac-tek 641 o in several places, explicitely mentioned "encryption" for RSVP (in 642 parallel to authentication). 643 o Various minor edits. 645 13. Informative References 647 [I-D.ietf-pcn-architecture] 648 Eardley, P., "Pre-Congestion Notification Architecture", 649 draft-ietf-pcn-architecture-03 (work in progress), 650 February 2008. 652 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 653 Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP 654 Proxy Approaches", 655 draft-ietf-tsvwg-rsvp-proxy-approaches-04 (work in 656 progress), April 2008. 658 [I-D.weis-gdoi-mac-tek] 659 Weis, B. and S. Rowles, "GDOI Generic Message 660 Authentication Code Policy", draft-weis-gdoi-mac-tek-00 661 (work in progress), July 2008. 663 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 664 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 665 Functional Specification", RFC 2205, September 1997. 667 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 668 (IKE)", RFC 2409, November 1998. 670 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 671 Authentication", RFC 2747, January 2000. 673 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 674 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 675 RFC 3175, September 2001. 677 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 678 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 679 Tunnels", RFC 3209, December 2001. 681 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 682 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 683 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 685 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 686 Group Domain of Interpretation", RFC 3547, July 2003. 688 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 689 Signature Option", RFC 3562, July 2003. 691 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 692 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 693 May 2005. 695 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 696 Properties", RFC 4230, December 2005. 698 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 699 Internet Protocol", RFC 4301, December 2005. 701 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 702 RFC 4303, December 2005. 704 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 705 RFC 4306, December 2005. 707 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 708 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 709 RFC 4804, February 2007. 711 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 712 Davenport, "Generic Aggregate Resource ReSerVation 713 Protocol (RSVP) Reservations", RFC 4860, May 2007. 715 Authors' Addresses 717 Michael H. Behringer 718 Cisco Systems Inc 719 Village d'Entreprises Green Side 720 400, Avenue Roumanille, Batiment T 3 721 Biot - Sophia Antipolis 06410 722 France 724 Email: mbehring@cisco.com 725 URI: http://www.cisco.com 727 Francois Le Faucheur 728 Cisco Systems Inc 729 Village d'Entreprises Green Side 730 400, Avenue Roumanille, Batiment T 3 731 Biot - Sophia Antipolis 06410 732 France 734 Email: flefauch@cisco.com 735 URI: http://www.cisco.com 737 Full Copyright Statement 739 Copyright (C) The IETF Trust (2008). 741 This document is subject to the rights, licenses and restrictions 742 contained in BCP 78, and except as set forth therein, the authors 743 retain all their rights. 745 This document and the information contained herein are provided on an 746 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 747 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 748 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 749 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 750 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 751 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 753 Intellectual Property 755 The IETF takes no position regarding the validity or scope of any 756 Intellectual Property Rights or other rights that might be claimed to 757 pertain to the implementation or use of the technology described in 758 this document or the extent to which any license under such rights 759 might or might not be available; nor does it represent that it has 760 made any independent effort to identify any such rights. Information 761 on the procedures with respect to rights in RFC documents can be 762 found in BCP 78 and BCP 79. 764 Copies of IPR disclosures made to the IETF Secretariat and any 765 assurances of licenses to be made available, or the result of an 766 attempt made to obtain a general license or permission for the use of 767 such proprietary rights by implementers or users of this 768 specification can be obtained from the IETF on-line IPR repository at 769 http://www.ietf.org/ipr. 771 The IETF invites any interested party to bring to its attention any 772 copyrights, patents or patent applications, or other proprietary 773 rights that may cover technology that may be required to implement 774 this standard. Please address the information to the IETF at 775 ietf-ipr@ietf.org.