idnits 2.17.1 draft-ietf-tsvwg-rsvp-security-groupkeying-00.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 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 636. 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 (February 18, 2008) is 5911 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-rsvp-proxy-approaches-03 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- 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 (~~), 2 warnings (==), 11 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: August 21, 2008 February 18, 2008 7 Applicability of Keying Methods for RSVP Security 8 draft-ietf-tsvwg-rsvp-security-groupkeying-00.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 August 21, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 The Resource reSerVation Protocol (RSVP) allows hop-by-hop 42 authentication of RSVP neighbors. This requires messages to be 43 cryptographically signed using a shared secret between participating 44 nodes. This document compares group keying for RSVP with per 45 neighbor or per interface keying, and discusses the associated key 46 provisioning methods as well as applicability and limitations of 47 these approaches. Draft-weis-gdoi-for-rsvp provides an example of 48 how the Group Domain of Interpretation (GDOI) could be used to 49 distribute group keys to RSVP nodes. The present document also 50 discusses applicability of group keying to RSVP encryption. 52 Table of Contents 54 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 55 2. The RSVP Trust Model . . . . . . . . . . . . . . . . . . . . . 3 56 3. Key types for RSVP . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Interface based keys . . . . . . . . . . . . . . . . . . . 4 58 3.2. Neighbor based keys . . . . . . . . . . . . . . . . . . . 5 59 3.3. Group keys . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 5 61 4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 5 62 4.2. Per Neighbor Key Negotiation . . . . . . . . . . . . . . . 6 63 4.3. Dynamic Group Key Distribution . . . . . . . . . . . . . . 6 64 5. Applicability of Various Keying Methods for RSVP . . . . . . . 6 65 5.1. Per Neighbor or Per Interface Keys for Authentication . . 6 66 5.2. Group Keys for Authentication . . . . . . . . . . . . . . 6 67 5.3. Non-RSVP Hops . . . . . . . . . . . . . . . . . . . . . . 7 68 5.4. Subverted RSVP Nodes . . . . . . . . . . . . . . . . . . . 8 69 5.5. RSVP Encryption . . . . . . . . . . . . . . . . . . . . . 9 70 5.6. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 9 71 6. End Host Considerations . . . . . . . . . . . . . . . . . . . 10 72 7. Applicability to Other Architectures and Protocols . . . . . . 10 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 75 10. Changes to Previous Version . . . . . . . . . . . . . . . . . 11 76 10.1. changes from behringer-00 to behringer-01 . . . . . . . . 11 77 10.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 12 78 11. Informative References . . . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 80 Intellectual Property and Copyright Statements . . . . . . . . . . 14 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 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 [I-D.weis-gdoi-for-rsvp] provides an example of how group keys could 104 be dynamically distributed to a set of RSVP routers and updated, 105 using GDOI ([RFC3547]) for the actual key distribution. 107 The present document discusses the various keying methods and their 108 applicability to different RSVP deployment environments, for both 109 message integrity and encryption. It does not mandate any particular 110 method, but is meant as a comparative guideline to understand where 111 each RSVP keying method is best deployed, and its limitations. 112 Furthermore, it discusses how RSVP hop by hop authentication is 113 impacted in the presence of non-RSVP nodes, or subverted nodes, in 114 the reservation path. 116 The document "RSVP Security Properties" ([RFC4230]) provides an 117 overview of RSVP security, including RSVP Cryptographic 118 Authentication [RFC2747], but does not discuss key management. It 119 states that "RFC 2205 assumes that security associations are already 120 available". The present document focuses specifically on key 121 management with different key types, including group keys. Therefore 122 this document complements [RFC4230]. 124 2. The RSVP Trust Model 126 Many protocol security mechanisms used in networks require and use 127 per peer authentication. Each hop authenticates its neighbor with a 128 shared key or certificate. This is also the model used for RSVP. 130 Trust in this model is transitive. Each RSVP node trusts explicitely 131 only its RSVP next hop peers, through the message digest contained in 132 the INTEGRITY object. The next hop RSVP speaker in turn trusts its 133 own peers and so on. See also the document ""RSVP security 134 properties" [RFC4230] for more background. 136 The keys used for generating the RSVP messages can, in particular, be 137 group keys (for example distributed via GDOI [RFC3547], as discussed 138 in [I-D.weis-gdoi-for-rsvp]). The trust model is the same as for 139 RSVP authentication. This is described in more detail in the section 140 "Using GDOI For RSVP Encryption" in section 5.5. 142 The trust an RSVP node has to another RSVP node has an explicit and 143 an implicit component. Explicitely the node trusts the other node to 144 maintain the RSVP messages intact or confidential, depending on 145 whether authentication or encryption (or both) is used. This means 146 only that the message has not been altered or seen by another, non- 147 trusted node. Implicitely each node trusts each other node with 148 which it has a trust relationship established via the mechanisms here 149 to adhere to the protocol specifications laid out by the various 150 standards. Note that in any group keying scheme like GDOI a node 151 trusts explicitely as well as implicitely all the other members of 152 the group. 154 The RSVP protocol can operate in the presence of a non-RSVP router in 155 the path from the sender to the receiver. The non-RSVP hop will 156 ignore the RSVP message and just pass it along. The next RSVP node 157 can then process the RSVP message. For RSVP authentication to work 158 in this case, the key used for computing the RSVP message digest 159 needs to be shared by the two RSVP neighbors, even if they are not IP 160 neighbors. However, in the presence of non-RSVP hops, while an RSVP 161 node always know the next IP hop before forwarding an RSVP Message, 162 it does not always know the RSVP next hop. Thus, the presence of 163 non-RSVP hops impacts operation of RSVP authentication and may 164 influence the keying approaches. This is further discussed in 165 Section 5.3. 167 3. Key types for RSVP 169 3.1. Interface based keys 171 Most current RSVP authentication implementations support interface 172 based RSVP keys. When the interface is point-to-point (and therefore 173 an RSVP router only has a single RSVP neighbor on each interface), 174 this is similar to neighbor based keys in the sense that a different 175 key is used for each neighbor. However, when the interface is 176 multipoint, all RSVP speakers on a given subnet have to share the 177 same key in this model, which makes it unsuitable for deployment 178 scenarios where different trust groups share a subnet, for example 179 Internet exchange points. In such a case, neighbor based keys are 180 required. 182 3.2. Neighbor based keys 184 In this model, an RSVP key is bound to an interface plus a neighbor 185 on that interface. It allows the distinction of different trust 186 groups on a single subnet. (Assuming that layer-2 security is 187 correctly implemented to prevent layer-2 attacks.) 189 3.3. Group keys 191 Here, all members of a group of RSVP nodes share the same key. This 192 implies that a node uses the same key regardless of the next RSVP hop 193 that will process the message (within the group of nodes sharing the 194 particular key). It also implies that a node will use the same key 195 on the receiving as on the sending side (when exchanging RSVP 196 messages withn the group). 198 4. Key Provisioning Methods for RSVP 200 4.1. Static Key Provisioning 202 The simplest way to implement RSVP authentication is to use static, 203 preconfigured keys. Static keying can be used with interface based 204 keys, neighbor based keys or group keys. 206 However, such static key provisioning is expensive on the operational 207 side, since no secure automated mechanism can be used, and initial 208 provisioning as well as key updates require configuration. This 209 method is therefore mostly useful for small deployments, where key 210 changes can be carried out manually, or for deployments with 211 automated configuration tools which support key changes. 213 Static key provisioning is therefore not an ideal model in a large 214 network. 216 Often, the number of interconnection points across two domains where 217 RSVP is allowed to transit is relatively small and well controlled. 218 Also, the different domains may not be in a position to use an 219 infrastructure trusted by both domains to update keys on both sides. 220 Thus, manually configured keys may be applicable to inter-domain RSVP 221 authentication. 223 Since it is not practical to carry out the key change at the exact 224 same time on both sides, some grace period needs to be implemented 225 during which an RSVP node will accept both the old and the new key. 226 Otherwise, RSVP operation would suffer interruptions. 228 4.2. Per Neighbor Key Negotiation 230 To avoid the problem of manual key provisioning and updates in static 231 key deployments, key negotiation between RSVP neighbors could be 232 used. Key negotiation could be used to derive either interface or 233 neighbor based keys. However, existing key negotiation protocols 234 such as IKEv1[RFC2409] or IKEv2 [RFC4306] may not be appropriate in 235 all environments because of the relative complexity of the protocols 236 and related operations. 238 4.3. Dynamic Group Key Distribution 240 With this approach, group keys are dyanmically distributed among a 241 set of RSVP routers. For example, [I-D.weis-gdoi-for-rsvp] describes 242 a mechanism to distribute group keys to a group of RSVP speakers, 243 using GDOI [RFC3547]. In this solution, a key server authenticates 244 each of the RSVP nodes independently, and then distributes a group 245 key to the entire group. 247 5. Applicability of Various Keying Methods for RSVP 249 5.1. Per Neighbor or Per Interface Keys for Authentication 251 Per interface and per neighbor keys can be used within a single 252 security domain. As mentioned above, per interface keys are only 253 applicable when all the hosts reachable on the specific interface 254 belong to the same security domain. 256 These key types can also be used between security domains, since they 257 are specific to a particular interface or neighbor. Again, interface 258 level keys can only be deployed safely when all the reachable 259 neighbors on the interface belong to the same security domain. 261 As discussed in Section 5.3, per neighbor and per interface keys can 262 not be used in the presence of non-RSVP hops. 264 5.2. Group Keys for Authentication 266 Group keys apply naturally to intra-domain RSVP authentication, since 267 all RSVP nodes implicitely trust each other. Using group keys, they 268 extend this trust to the group key server. This is represented in 269 Figure 1. 271 ......GKS1............. 272 : : : : : 273 : : : : : 274 source--R1--R2--R3-----destination 275 | | 276 |<-----domain 1----------------->| 278 Figure 1: Group Key Server within a single security domain 280 A single group key cannot normally be used to cover multiple security 281 domains however, because by definition the different domains do not 282 trust each other and would not be willing to trust the same group key 283 server. For a single group key to be used in several security 284 domains, there is a need for a single group key server, which is 285 trusted by both sides. While this is theoretically possible, in 286 practice it is unlikely that there is a single such entity trusted by 287 both domains. Figure 2 illustrates this setup. 289 ...............GKS1.................... 290 : : : : : : : : 291 : : : : : : : : 292 source--R1--R2--R3--------R4--R5--R6--destination 293 | | | | 294 |<-----domain 1--->| |<-------domain 2----->| 296 Figure 2: A Single Group Key Server across security domains 298 A more practical approach for RSVP operation across security domains, 299 is to use a separate group key server for each security domain, and 300 to use per interface or per peer authentication between the two 301 domains. Figure 3 shows this set-up. 303 ....GKS1...... ....GKS2......... 304 : : : : : : : : 305 : : : : : : : : 306 source--R1--R2--R3--------R4--R5--R6--destination 307 | | | | 308 |<-----domain 1--->| |<-------domain 2----->| 310 Figure 3: A group Key Server per security domain 312 5.3. Non-RSVP Hops 314 In the presence of a non-RSVP router in the path from the sender to 315 the receiver, regular RSVP keeps working. The non-RSVP node ignores 316 the RSVP message, and passes it on transparently to the next node. 317 Figure 4 illustrates this scenario. R2 in this picture does not 318 participate in RSVP, the other nodes do. In this case, R2 will pass 319 on any RSVP messages unchanged, and will ignore them. 321 ----R3--- 322 / \ 323 sender----R1---R2(*) R4----receiver 324 \ / 325 ----R5--- 326 (*) Non-RSVP hop 328 Figure 4: A non-RSVP Node in the path 330 However, this creates an additional challenge for RSVP 331 authentication. In the presence of a non-RSVP hop, with some RSVP 332 messages such as a Path message, an RSVP router does not know the 333 RSVP next hop for that message at the time of forwarding it. In 334 fact, part of the role of a Path message is precisely to discover the 335 RSVP next hop (and to dynamically re-discover it when it changes, say 336 because of a routing change). For example, in Figure 4, R1 knows 337 that the next IP hop for a Path message addresed to the receiver is 338 R2, but it does necessarily not know if the RSVP next hop is R3 or 339 R5. 341 This means that per interface and per neighbor keys cannot easily be 342 used in the presence of non-RSVP routers on the path between senders 343 and receivers. 345 By contrast, group keying will naturally work in the presence of non- 346 RSVP routers. Referring back to Figure 4, with group keying, R1 347 would use the group key to sign a Path message addressed to the 348 receiver and forwards it to R2. Being a non-RSVP node, R2 and will 349 ignore and forward the Path message to R3 or R5 depending on the 350 current shortest path as determined by routing. Whether it is R3 or 351 R5, the RSVP router that receives the Path message will be able to 352 authenticate it successfully with the group key. 354 5.4. Subverted RSVP Nodes 356 A subverted node is defined here as an untrusted node, for example 357 because an intruder has gained control over it. Since RSVP 358 authentication is hop-by-hop and not end-to-end, a subverted node in 359 the path breaks the chain of trust. This is to a large extent 360 independent of the type of keying used. 362 For interface or per-neighbor keying, the subverted node can now 363 introduce fake messages to its neighbors. This can be used in a 364 variety of ways, for example by changing the receiver address in the 365 Path message, or by generating fake Path messages. This allows path 366 states to be created on every RSVP router along any arbitrary path 367 through the RSVP domain. That in itself could result in a form of 368 Denial of Service by allowing exhaustion of some router resources 369 (e.g. memory). The subverted node could also generate fake Resv 370 messages upstream corresponding to valid Path states. In doing so, 371 the subverted node can reserve excessive amounts of bandwidth thereby 372 possibly performing a denial of service attack. 374 Group keying allows the additional abuse of sending fake RSVP 375 messages to any node in the RSVP domain, not just adjacent RSVP 376 nodes. However, in practice this can be achieved to a large extent 377 also with per neighbor or interface keys, as discussed above. 378 Therefore the impact of subverted nodes on the path is comparable, 379 independently whether per-interface, per-neighbor or group keys are 380 used. 382 5.5. RSVP Encryption 384 The keying material can also be used to encrypt the RSVP messages 385 using IPsec [RFC2401], instead of, or in addition to authenticating 386 them. The same considerations apply for this case as discussed above 387 for the authentication case. Group keys are applicable only within a 388 trusted domain, but they allow operation through non-RSVP speakers 389 without further configuration. Per interface or per neighbor keys 390 work also inter-domain, but do not operate in the presence of a non- 391 RSVP router. 393 The existing GDOI standard as described in [RFC3547] contains all 394 relevant policy options to allow for RSVP encryption, and no 395 extensions are necessary. An example GDOI policy would be to encrypt 396 all packets of the RSVP protocol itself (IP protocol 46). A router 397 implementing GDOI is therefore automatically able to encrypt RSVP. 399 [Editor's note: Applicability of tunnel vs transport mode still needs 400 to be discussed.] 402 5.6. RSVP Notify Messages 404 [RFC3473] introduces the Notify message and allows such Notify 405 messages to be sent in a non-hop-by-hop fashion. As discussed in the 406 Security Considerations section of [RFC3473], this can interfere with 407 RSVP's hop-by-hop integrity and authentication model. [RFC3473] 408 describes how standard IPsec based integrity and authentication can 409 be used to protect Notify messages. We observe that, alternatively, 410 in some environments, group keying may allow use of regular RSVP 411 authentication ([RFC2747]) for protection of non-hop-by-hop Notify 412 messages. For example, this may be applicable to controlled 413 environments where nodes invoking notification requests are known to 414 belong to the same key group as nodes generating Notify messages. 416 6. End Host Considerations 418 Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches] 419 are used, RSVP signaling is controlled by end systems and not 420 routers. As discussed in [RFC4230], RSVP allows both user-based 421 security and host-based security. User-based authentication aims at 422 "providing policy based admission control mechanism based on user 423 identities or application." To identify the user or the application, 424 a policy element called AUTH_DATA, which is contained in the 425 POLICY_DATA object, is created by the RSVP daemon at the user's host 426 and transmitted inside the RSVP message. This way, a user may 427 authenticate to the Policy Decision Point (or directly to the first 428 hop router). Host-based security relies on the same mechanisms as 429 between routers (i.e. INTEGRITY object ) as specified in [RFC2747]. 430 For host-based security, interface or neighbor based keys may be 431 used, however, key management with pre-shared keys can be difficult 432 in a large scale deployment, as described in section 4. In principle 433 an end host can also be part of a group key scheme, such as GDOI. If 434 the end systems are part of the same zone of trust as the network 435 itself, group keying can be extended to include the end systems. If 436 the end systems and the network are in different zones of trust, 437 group keying cannot be used. 439 7. Applicability to Other Architectures and Protocols 441 While, so far, this document only discusses RSVP security assuming 442 the traditional RSVP model as defined by [RFC2205] and [RFC2747], the 443 analysis is also applicable to other RSVP deployment models as well 444 as to similar protocols: 446 o Aggregation of RSVP for IPv4 and IPv6 Reservations [RFC3175]: This 447 scheme defines aggregation of individual RSVP reservations, and 448 discusses use of RSVP authentication for the signaling messages. 449 Group keying is applicable to this scheme, particularly when 450 automatic Deaggregator discovery is used, since in that case, the 451 Aggregator does not know ahead of time which Deaggregator will 452 intercept the initial end-to-end RSVP Path message. 453 o Generic Aggregate Resource ReSerVation Protocol (RSVP) 454 Reservations [RFC4860]: This document also discusses aggregation 455 of individual RSVP reservations. Here again, group keying applies 456 and is mentioned in the Security Considerations section. 457 o Aggregation of Resource ReSerVation Protocol (RSVP) Reservations 458 over MPLS TE/DS-TE Tunnels [RFC4804]([RFC4804]): This scheme also 459 defines a form of aggregation of RSVP reservation but this time 460 over MPLS TE Tunnels. Similarly, group keying may be used in such 461 an environment. 463 o Pre-Congestion Notification (PCN): [I-D.ietf-pcn-architecture] 464 defines an architecture for flow admission and termination based 465 on aggregated pre-congestion information. One deployment model 466 for this architecture is based on IntServ over DiffServ: the 467 DiffServ region is PCN-enabled, RSVP signalling is used end-to-end 468 but the PCN-domain is a single RSVP hop, i.e. only the PCN- 469 boundary-nodes process RSVP messages. In this scenario, RSVP 470 authentication may be required among PCN-boundary-nodes and the 471 considerations about keying approaches discussed earlier in this 472 document apply. In particular, group keying may facilitate 473 operations since the ingress PCN-boundary-node does not 474 necessarily know ahead of time which Egress PCN-boundary-node will 475 intercept and process the initial end-to-end Path message. Note 476 that from the viewpoint of securing end-to-end RSVP, there are a 477 lot of similarities in scenarios involving RSVP Aggregation over 478 aggregate RSVP reservations ([RFC3175], [RFC4860]), RSVP 479 Aggregation over MPLS-TE tunnels ([RFC4804]), and RSVP 480 (Aggregation) over PCN ingress-egress aggregates. 482 8. Security Considerations 484 This entire document discusses RSVP security. 486 9. Acknowledgements 488 The authors would like to thank everybody who provided feedback on 489 this document. Specific thanks to Bob Briscoe, Hannes Tschofenig and 490 Brian Weis. 492 10. Changes to Previous Version 494 The following changes were made in version 01: 496 10.1. changes from behringer-00 to behringer-01 498 o New section "Applicability to Other Architectures and Protocols": 499 Goal is to clarify the scope of this document: The idea presented 500 here is also applicable to other architectures 501 (PCN[I-D.ietf-pcn-architecture], RFC3175 and RFC4860, etc. 502 o Clarified the scope of this document versus RFC4230 (in the 503 introduction, last paragraph). 504 o Added a section on "End Host Considerations". 505 o Expanded section 5.5 (RSVP Encryption) to clarify that GDOI 506 contains all necessary mechanisms to do RSVP encrpytion. 508 o Tried to clarify the "trust to do what?" question raised by Bob 509 Briscoe in a mail on 26 Jul 2007. See the section on trust model. 510 o Lots of small editorial changes (references, typos, figures, etc). 511 o Added an Acknowledgements section. 513 10.2. changes from behringer-01 to ietf-00 515 o various edits to make it clearer that draft-weis-gdoi-for-rsvp is 516 an example of how dynamic group keying could be achieved for RSVP 517 and not necessraily the recommended solution 519 11. Informative References 521 [I-D.ietf-pcn-architecture] 522 Eardley, P., "Pre-Congestion Notification Architecture", 523 October 2007. 525 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 526 Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP 527 Proxy Approaches", 528 draft-ietf-tsvwg-rsvp-proxy-approaches-03 (work in 529 progress), December 2007. 531 [I-D.weis-gdoi-for-rsvp] 532 Weis, B., "Group Domain of Interpretation (GDOI) support 533 for RSVP", July 2007. 535 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 536 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 537 Functional Specification", RFC 2205, September 1997. 539 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 540 Internet Protocol", RFC 2401, November 1998. 542 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 543 (IKE)", RFC 2409, November 1998. 545 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 546 Authentication", RFC 2747, January 2000. 548 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 549 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 550 RFC 3175, September 2001. 552 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 553 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 554 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 556 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 557 Group Domain of Interpretation", RFC 3547, July 2003. 559 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 560 Signature Option", RFC 3562, July 2003. 562 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 563 Properties", RFC 4230, December 2005. 565 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 566 RFC 4306, December 2005. 568 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 569 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 570 RFC 4804, February 2007. 572 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 573 Davenport, "Generic Aggregate Resource ReSerVation 574 Protocol (RSVP) Reservations", RFC 4860, May 2007. 576 Authors' Addresses 578 Michael H. Behringer 579 Cisco Systems Inc 580 Village d'Entreprises Green Side 581 400, Avenue Roumanille, Batiment T 3 582 Biot - Sophia Antipolis 06410 583 France 585 Email: mbehring@cisco.com 586 URI: http://www.cisco.com 588 Francois Le Faucheur 589 Cisco Systems Inc 590 Village d'Entreprises Green Side 591 400, Avenue Roumanille, Batiment T 3 592 Biot - Sophia Antipolis 06410 593 France 595 Email: flefauch@cisco.com 596 URI: http://www.cisco.com 598 Full Copyright Statement 600 Copyright (C) The IETF Trust (2008). 602 This document is subject to the rights, licenses and restrictions 603 contained in BCP 78, and except as set forth therein, the authors 604 retain all their rights. 606 This document and the information contained herein are provided on an 607 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 608 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 609 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 610 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 611 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 612 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 614 Intellectual Property 616 The IETF takes no position regarding the validity or scope of any 617 Intellectual Property Rights or other rights that might be claimed to 618 pertain to the implementation or use of the technology described in 619 this document or the extent to which any license under such rights 620 might or might not be available; nor does it represent that it has 621 made any independent effort to identify any such rights. Information 622 on the procedures with respect to rights in RFC documents can be 623 found in BCP 78 and BCP 79. 625 Copies of IPR disclosures made to the IETF Secretariat and any 626 assurances of licenses to be made available, or the result of an 627 attempt made to obtain a general license or permission for the use of 628 such proprietary rights by implementers or users of this 629 specification can be obtained from the IETF on-line IPR repository at 630 http://www.ietf.org/ipr. 632 The IETF invites any interested party to bring to its attention any 633 copyrights, patents or patent applications, or other proprietary 634 rights that may cover technology that may be required to implement 635 this standard. Please address the information to the IETF at 636 ietf-ipr@ietf.org. 638 Acknowledgment 640 Funding for the RFC Editor function is provided by the IETF 641 Administrative Support Activity (IASA).