idnits 2.17.1 draft-ietf-msec-ipsec-extensions-06.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1281. 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 abstract seems to contain references ([RFC4301]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3171 (Obsoleted by RFC 5771) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 3940 (Obsoleted by RFC 5740) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MSEC Working Group B. Weis 2 Internet-Draft Cisco Systems 3 Intended status: Standards Track G. Gross 4 Expires: January, 2008 IdentAware Security 5 D. Ignjatic 6 Polycom 7 July, 2007 9 Multicast Extensions to the Security Architecture for the Internet 10 Protocol 11 draft-ietf-msec-ipsec-extensions-06.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that 16 any applicable patent or other IPR claims of which he or she is 17 aware have been or will be disclosed, and any of which he or she 18 becomes aware will be disclosed, in accordance with Section 6 of 19 BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The Security Architecture for the Internet Protocol [RFC4301] 45 describes security services for traffic at the IP layer. That 46 architecture primarily defines services for Internet Protocol (IP) 47 unicast packets. It also defines services for manually keyed 48 Security Associations (SAs) matching IP multicast traffic 49 selectors. This document further defines the security services for 50 manually and dynamically keyed SAs matching IP multicast traffic 51 selectors within that Security Architecture. 53 Table of Contents 55 1. Introduction.....................................................3 56 1.1 Scope.........................................................3 57 1.2 Terminology...................................................4 58 2. Overview of IP Multicast Operation...............................5 59 3. Security Association Modes.......................................6 60 3.1 Tunnel Mode with Address Preservation.........................6 61 4. Security Association.............................................8 62 4.1 Major IPsec Databases.........................................8 63 4.1.1 Group Security Policy Database (GSPD).....................8 64 4.1.2 Security Association Database (SAD).......................9 65 4.1.3 Peer Authorization Database (PAD).........................9 66 4.2 Group Security Association (GSA).............................11 67 4.3 Data Origin Authentication...................................12 68 4.4 Group SA and Key Management..................................13 69 4.4.1 Co-Existence of Multiple Key Management Protocols........13 70 4.4.2 New Security Association Attributes......................13 71 5. IP Traffic Processing...........................................14 72 5.1 Outbound IP Multicast Traffic Processing.....................14 73 5.2 Inbound IP Multicast Traffic Processing......................14 74 6. Security Considerations.........................................15 75 6.1 Security Issues Solved by IPsec Multicast Extensions.........15 76 6.2 Security Issues Not Solved by IPsec Multicast Extensions.....15 77 6.2.1 Outsider Attacks.........................................15 78 6.2.2 Insider Attacks..........................................16 79 6.3 Implementation or Deployment Issues that Impact Security.....17 80 6.3.1 Homogeneous Group Cryptographic Algorithm Capabilities...17 81 6.3.2 Groups that Span Two or More Security Policy Domains.....17 82 6.3.3 Network Address Translation..............................17 83 7. IANA Considerations.............................................20 84 8. Acknowledgements................................................20 85 9. References......................................................20 86 9.1 Normative References.........................................20 87 9.2 Informative References.......................................21 88 Appendix A - Multicast Application Service Models..................23 89 A.1 Unidirectional Multicast Applications........................23 90 A.2 Bi-directional Reliable Multicast Applications...............23 91 A.3 Any-To-Any Multicast Applications............................24 92 Author's Address...................................................25 93 Full Copyright Statement...........................................26 94 Intellectual Property..............................................26 95 1. Introduction 97 The Security Architecture for the Internet Protocol [RFC4301] 98 provides security services for traffic at the IP layer. It 99 describes an architecture for IPsec compliant systems, and a set of 100 security services for the IP layer. These security services 101 primarily describe services and semantics for IPsec Security 102 Associations (SAs) shared between two IPsec devices. Typically, 103 this includes SAs with traffic selectors that include a unicast 104 address in the IP destination field, and results in an IPsec packet 105 with a unicast address in the IP destination field. The security 106 services defined in RFC 4301 can also be used to tunnel IP 107 multicast packets, where the tunnel is a pairwise association 108 between two IPsec devices. RFC4301 defined manually keyed 109 transport mode IPsec SA support for IP packets with a multicast 110 address in the IP destination address field. However, RFC4301 did 111 not define the interaction of an IPsec subsystem with a Group Key 112 Management protocol or the semantics of a tunnel mode IPsec SA with 113 an IP multicast address in the outer IP header. 115 This document describes extensions to RFC 4301 that further define 116 the IPsec security architecture for groups of IPsec devices to 117 share SAs. In particular, it supports SAs with traffic selectors 118 that include a multicast address in the IP destination field, and 119 results in an IPsec packet with an IP multicast address in the IP 120 destination field. It also describes additional semantics for IPsec 121 Group Key Management (GKM) subsystems. Note that this document uses 122 the term "GKM protocol" generically and therefore it does not 123 assume a particular GKM protocol. 125 1.1 Scope 127 The IPsec extensions described in this document support IPsec 128 Security Associations that result in IPsec packets with IPv4 or 129 IPv6 multicast group addresses as the destination address. Both 130 Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) 131 [RFC3569] [RFC3376] group addresses are supported. 133 These extensions also support Security Associations with IPv4 134 Broadcast addresses that result in an IPv4 link-level broadcast 135 packet, and IPv6 Anycast addresses [RFC2526] that result in an IPv6 136 Anycast packet. These destination address types share many of the 137 same characteristics of multicast addresses because there may be 138 multiple candidate receivers of a packet protected by IPsec. 140 The IPsec architecture does not make requirements upon entities not 141 participating in IPsec (e.g., network devices between IPsec 142 endpoints). As such, these multicast extensions do not require 143 intermediate systems in a multicast enabled network to participate 144 in IPsec. In particular, no requirements are placed on the use of 145 multicast routing protocols (e.g., PIM-SM [RFC4601]) or multicast 146 admission protocols (e.g., IGMP [RFC3376]. 148 All implementation models of IPsec (e.g., "bump-in-the-stack", 149 "bump-in-the-wire") are supported. 151 This version of the multicast IPsec extension specification 152 requires that all IPsec devices participating in a Security 153 Association are homogeneous. They MUST share a common set of 154 cryptographic transform and protocol handling capabilities. The 155 semantics of an "IPsec composite group" [COMPGRP], a heterogeneous 156 IPsec cryptographic group formed from the union of two or more sub- 157 groups, is an area for future standardization. 159 1.2 Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 163 this document are to be interpreted as described in RFC 2119 164 [RFC2119]. 166 The following key terms are used throughout this document. 168 Any-Source Multicast (ASM) 169 The Internet Protocol (IP) multicast service model as defined 170 in RFC 1112 [RFC1112]. In this model one or more senders source 171 packets to a single IP multicast address. When receivers join 172 the group, they receive all packets sent to that IP multicast 173 address. This is known as a (*,G) group. 175 Group Controller Key Server (GCKS) 176 A Group Key Management (GKM) protocol server that manages IPsec 177 state for a group. A GCKS authenticates and provides the IPsec 178 SA policy and keying material to GKM group members. 180 Group Key Management (GKM) Protocol 181 A key management protocol used by a GCKS to distribute IPsec 182 Security Association policy and keying material. A GKM protocol 183 is used when a group of IPsec devices require the same SAs. For 184 example, when an IPsec SA describes an IP multicast 185 destination, the sender and all receivers need to have the 186 group SA. 188 Group Key Management Subsystem 189 A subsystem in an IPsec device implementing a Group Key 190 Management protocol. The GKM subsystem provides IPsec SAs to 191 the IPsec subsystem on the IPsec device. Refer to RFC 3547 192 [RFC3547] and RFC 4535 [RFC4535] for additional information. 194 Group Member 195 An IPsec device that belongs to a group. A Group Member is 196 authorized to be a Group Sender and/or a Group Receiver. 198 Group Owner 199 An administrative entity that chooses the policy for a group. 201 Group Security Association (GSA) 202 A collection of IPsec Security Associations (SAs) and GKM 203 Subsystem SAs necessary for a Group Member to receive key 204 updates. A GSA describes the working policy for a group. Refer 205 to RFC 4046 [RFC4046] for additional information. 207 Group Security Policy Database (GSPD) 208 The GSPD is a multicast-capable security policy database, as 209 mentioned in RFC3740 and RFC4301 section 4.4.1.1. Its semantics 210 are a superset of the unicast SPD defined by RFC4301 section 211 4.4.1. Unlike a unicast SPD-S in which point-to-point traffic 212 selectors are inherently bi-directional, multicast security 213 traffic selectors in the GSPD-S introduce a "sender only", 214 "receiver only" or "symmetric" directional attribute. Refer to 215 section 4.1.1 for more details. 217 Group Receiver 218 A Group Member that is authorized to receive packets sent to a 219 group by a Group Sender. 221 Group Sender 222 A Group Member that is authorized to send packets to a group. 224 Source-Specific Multicast (SSM) 225 The Internet Protocol (IP) multicast service model as defined 226 in RFC 3569 [RFC3569]. In this model, each combination of a 227 sender and an IP multicast address is considered a group. This 228 is known as an (S,G) group. 230 Tunnel Mode with Address Preservation 231 A type of IPsec tunnel mode used by security gateway 232 implementations when encapsulating IP multicast packets such 233 that they remain IP multicast packets. This mode is necessary 234 for IP multicast routing to correctly route IP multicast 235 packets protected by IPsec. 237 2. Overview of IP Multicast Operation 239 IP multicasting is a means of sending a single packet to a "host 240 group", a set of zero or more hosts identified by a single IP 241 destination address. IP multicast packets are UDP data packets 242 delivered to all members of the group with either "best-effort" 243 [RFC1112], or reliable delivery (e.g., NORM) [RFC3940]. 245 A sender to an IP multicast group sets the destination of the 246 packet to an IP address that has been allocated for IP multicast. 247 Allocated IP multicast addresses are defined in RFC 3171, RFC 3306, 248 and RFC 3307 [RFC3171] [RFC3306] [RFC3307]. Potential receivers of 249 the packet "join" the IP multicast group by registering with a 250 network routing device [RFC3376] [RFC3810], signaling its intent to 251 receive packets sent to a particular IP multicast group. 253 Network routing devices configured to pass IP multicast packets 254 participate in multicast routing protocols (e.g., PIM-SM) 255 [RFC4601]. Multicast routing protocols maintain state regarding 256 which devices have registered to receive packets for a particular 257 IP multicast group. When a router receives an IP multicast packet, 258 it forwards a copy of the packet out each interface for which there 259 are known receivers. 261 3. Security Association Modes 263 IPsec supports two modes of use: transport mode and tunnel mode. 264 In transport mode, IP Authentication Header (AH) [RFC4302] and IP 265 Encapsulating Security Payload (ESP) [RFC4303] provide protection 266 primarily for next layer protocols; in tunnel mode, AH and ESP are 267 applied to tunneled IP packets. 269 A host implementation of IPsec using the multicast extensions MAY 270 use either transport mode or tunnel mode to encapsulate an IP 271 multicast packet. These processing rules are identical to the 272 rules described in Section 4.1 or [RFC4301]. However, the 273 destination address for the IPsec packet is an IP multicast 274 address, rather than a unicast host address. 276 A security gateway implementation of IPsec using the multicast 277 extensions MUST use a tunnel mode SA, for the reasons described in 278 Section 4.1 of [RFC4301]. In particular, the security gateway 279 needs to use tunnel mode to encapsulate incoming fragments, since 280 IPsec cannot directly operate on fragments. 282 3.1 Tunnel Mode with Address Preservation 284 New header construction semantics are required when tunnel mode is 285 used to encapsulate IP multicast packets that are to remain IP 286 multicast packets. These semantics are due to the following unique 287 requirements of IP multicast routing protocols (e.g., PIM-SM 288 [RFC4601]). This document describes these new header construction 289 semantics as "tunnel mode with address preservation", and is 290 described as follows. 292 - IP multicast routing protocols compare the destination address 293 on a packet to the multicast routing state. If the destination 294 of an IP multicast packet is changed it will no longer be 295 properly routed. Therefore, an IPsec security gateway needs to 296 preserve the multicast IP destination address after IPsec tunnel 297 encapsulation. 299 The GKM Subsystem on a security gateway implementing the IPsec 300 multicast extensions preserves the multicast IP address as 301 follows. Firstly, the GKM Subsystem sets the Remote Address PFP 302 flag in the GSPD-S entry for the traffic selectors. This flag 303 causes the remote address of the packet matching IPsec SA 304 traffic selectors to be propagated to the IPsec tunnel 305 encapsulation. Secondly, the GKM Subsystem needs to signal that 306 destination address preservation is in effect for a particular 307 IPsec SA. The GKM protocol MUST define an attribute that signals 308 destination address preservation to the GKM Subsystem on an 309 IPsec security gateway. 311 - IP multicast routing protocols also typically create multicast 312 distribution trees based on the source address. If an IPsec 313 security gateway changes the source address of an IP multicast 314 packet (e.g., to its own IP address), the resulting IPsec 315 protected packet may fail Reverse Path Forwarding (RPF) checks 316 on other routers. A failed RPF check may result in the packet 317 being dropped. 319 To accommodate routing protocol RPF checks, the GKM Subsystem on 320 a security gateway implementation implementing the IPsec 321 multicast extensions needs to preserve the original packet IP 322 source address as follows. Firstly, the GSPD-S entry for the 323 traffic selectors sets the Source Address PFP flag. This flag 324 causes the remote address to be propagated to the IPsec SA. 325 Secondly, the GKM Subsystem needs to signal that source address 326 preservation is in effect for a particular IPsec SA. The GKM 327 Subsystem MUST define a protocol attribute that signals source 328 address preservation to the GKM Subsystem on an IPsec security 329 gateway. 331 Some applications of address preservation may only require the 332 destination address to be preserved. For this reason, the 333 specification of destination address preservation and source 334 address preservation are separated in the above description. 336 Address preservation is applicable only for tunnel mode IPsec SAs 337 that specify the IP version of the encapsulating header to be the 338 same version as that of the inner header. When the IP versions are 339 different, tunnel processing semantics described in RFC 4301 MUST 340 be followed. 342 In summary, retaining both the IP source and destination addresses 343 of the inner IP header allow IP multicast routing protocols to 344 route the packet irrespective of the packet being protected by 345 IPsec. This result is necessary in order for the multicast 346 extensions to allow a security gateway to provide IPsec services 347 for IP multicast packets. This method of RFC 4301 tunnel mode is 348 known as "tunnel mode with address preservation". 350 4. Security Association 352 4.1 Major IPsec Databases 354 The following sections describe the GKM Subsystem and IPsec 355 extension interactions with the IPsec databases. The major IPsec 356 databases needed expanded semantics to fully support multicast. 358 4.1.1 Group Security Policy Database (GSPD) 360 The Group Security Policy Database is a security policy database 361 capable of implementing both unicast security associations as 362 defined by RFC4301 and the multicast extensions defined by this 363 specification. A new Group Security Policy Database (GSPD) 364 attribute is introduced: GSPD entry directionality. Directionality 365 can take three types. Each GSPD entry can be marked "symmetric", 366 "sender only" or "receiver only". "Symmetric" GSPD entries are the 367 common entries as specified by RFC 4301. "Symmetric" SHOULD be the 368 default directionality unless specified otherwise. GSPD entries 369 marked as "sender only" or "receiver only" SHOULD support 370 multicast IP addresses in their destination address selectors. If 371 the processing requested is bypass or discard and a "sender only" 372 type is configured the entry SHOULD be put in GSPD-O only. 373 Reciprocally, if the type is "receiver only", the entry SHOULD go 374 to GSPD-I only. SSM is supported by the use of unicast IP address 375 selectors as documented in RFC 4301. 377 GSPD entries created by a GCKS may be assigned identical SPIs to 378 SAD entries created by IKEv2 [RFC4306]. This is not a problem for 379 the inbound traffic as the appropriate SAs can be matched using 380 the algorithm described in RFC 4301 section 4.1. In addition, SAs 381 with identical SPI values but not manually keyed can be 382 differentiated because they contain a link to their parent SPD 383 entries. However, the outbound traffic needs to be matched against 384 the GSPD selectors so that the appropriate SA can be created on 385 packet arrival. IPsec implementations that support multicast MUST 386 use the destination address as the additional selector and match 387 it against the GSPD entries marked "sender only". 389 To facilitate dynamic group keying, the outbound GSPD MUST 390 implement a policy action capability that triggers a GKM protocol 391 registration exchange (as per Section 5.1 of [RFC4301]). For 392 example, the Group Sender GSPD policy might trigger on a match 393 with a specified multicast application packet. The ensuing Group 394 Sender registration exchange would setup the Group Sender's 395 outbound SAD entry that encrypts the multicast application's data 396 stream. In the inverse direction, group policy may also setup an 397 inbound IPsec SA. 399 At the Group Receiver endpoint(s), the GSPD policy might trigger 400 on a match with the multicast application packet sent from the 401 Group Sender. The ensuing Group Receiver registration exchange 402 would setup the Group Receiver's inbound SAD entry that decrypts 403 the multicast application's data stream. In the inverse direction, 404 the group policy may also setup an outbound IPsec SA (e.g. when 405 supporting an ASM service model). 407 The IPsec subsystem MAY provide GSPD policy mechanisms (e.g. 408 trigger on detection of IGMP/MLD leave group exchange) that 409 automatically initiate a GKM protocol de-registration exchange. 410 De-registration may allow a GCKS to minimize exposure of the 411 group's secret key by re-keying a group on a group membership 412 change event. It also minimizes cost on a GCKS for those groups 413 that maintain member state. 415 Additionally, the GKM subsystem MAY setup the GSPD/SAD state 416 information independent of the multicast application's state. In 417 this scenario, the group's Group Owner issues management 418 directives that tells the GKM subsystem when it should start GKM 419 registration and de-registration protocol exchanges. Typically the 420 registration policy strives to make sure that the group's IPsec 421 subsystem state is "always ready" in anticipation of the multicast 422 application starting its execution. 424 4.1.2 Security Association Database (SAD) 426 The Security Association Database (SAD) can support multicast SAs, 427 if manually configured. An outbound multicast SA has the same 428 structure as a unicast SA. The source address is that of the Group 429 Sender and the destination address is the multicast group address. 430 An inbound multicast SA MUST be configured with the source 431 addresses of each Group Sender peer authorized to transmit to the 432 multicast SA in question. The SPI value for a multicast SA is 433 provided by a GCKS, not by the receiver as occurs for a unicast SA. 434 Other than the SPI assignment and the inbound packet de- 435 multiplexing described in RFC4301 section 4.1, the SAD behaves 436 identically for unicast and multicast security associations. 438 4.1.3 Peer Authorization Database (PAD) 440 The Peer Authorization Database (PAD) is extended in order to 441 accommodate peers that may take on specific roles in the group. 442 Such roles can be GCKS, Group Sender or a Group Receiver. A peer 443 can have multiple roles. The PAD may also contain root certificates 444 for PKI used by the group. 446 4.1.3.1 GKM/IPsec Interactions with the PAD 448 The RFC 4301 section 4.4.3 introduced the PAD. In summary, the PAD 449 manages the IPsec entity authentication mechanism(s) and 450 authorization of each such peer identity to negotiate modifications 451 to the GSPD/SAD. Within the context of the GKM/IPsec subsystem, the 452 PAD defines for each group: 454 . For those groups that authenticate identities using a Public Key 455 Infrastructure, the PAD contains the group's set of one or more 456 trusted root public key certificates. The PAD may also include 457 the PKI configuration data needed to retrieve supporting 458 certificates needed for an end entity's certificate path 459 validation. 461 . A set of one or more group membership authorization rules. The 462 GCKS examines these rules to determine a candidate group 463 member's acceptable authentication mechanism and to decide 464 whether that candidate has the authority to join the group. 466 . A set of one or more GCKS role authorization rules. A group 467 member uses these rules to decide which systems are authorized 468 to act as a GCKS for a given group. These rules also declare the 469 permitted GCKS authentication mechanism(s). 471 . A set of one or more Group Sender role authorization rules. In 472 some groups the group members allowed to send protected packets 473 is restricted. A GCKS uses these rules to declare which systems 474 are authorized to be a Group Sender for a given group. 476 Some GKM protocols (e.g. GSAKMP [RFC4535]) distribute their group's 477 PAD configuration in a security policy token [RFC4534] signed by 478 the group's policy authority, also known as the Group Owner (GO). 479 Each group member receives the policy token (using a method not 480 described in this memo) and verifies the Group Owner's signature on 481 the policy token. If that GO signature is accepted, then the group 482 member dynamically updates its PAD with the policy token's 483 contents. 485 The PAD MUST provide a management interface capability that allows 486 an administrator to enforce that the scope of a GKM group's policy 487 specified GSPD/SAD modifications are restricted to only those 488 traffic data flows that belong to that group. This authorization 489 MUST be configurable at GKM group granularity. In the inverse 490 direction, the PAD management interface MUST provide a mechanism(s) 491 to enforce that IKEv2 security associations do not negotiate 492 traffic selectors that conflict or override GKM group policies. 494 This document refers to re-key mechanisms as being multicast 495 because of the inherent scalability of IP multicast distribution. 497 However, there is no particular reason that re-key mechanisms need 498 be multicast. For example, [ZLLY03] describes a method of re-key 499 employing both unicast and multicast messages. 501 4.2 Group Security Association (GSA) 503 As stated in Section 4 of [RFC3740] an IPsec implementation 504 supporting these extensions has a number of security associations: 505 one or more IPsec SAs, and one or more GKM SAs used to download 506 IPsec SAs. These SAs are collectively referred to as a Group 507 Security Association (GSA). 509 4.2.1 Concurrent IPsec SA Life Spans and Re-key Rollover 511 During a cryptographic group's lifetime, multiple IPsec group 512 security associations can exist concurrently. This occurs 513 principally due to two reasons: 515 - There are multiple Group Senders authorized in the group, each 516 with its own IPsec SA that maintains anti-replay state. A group 517 that does not rely on IP Security anti-replay services can share 518 one IPsec SA for all of its Group Senders. 520 - The life spans of a Group Sender's two (or more) IPsec SAs are 521 allowed to overlap in time, so that there is continuity in the 522 multicast data stream across group re-key events. This capability 523 is referred to as "re-key rollover continuity". 525 Each group re-key multicast message sent by a GCKS signals the 526 start of a new Group Sender time epoch, with each such epoch 527 having an associated IPsec SA. The group membership interacts with 528 these IPsec SAs as follows: 530 - As a precursor to the Group Sender beginning its re-key rollover 531 continuity processing, the GCKS periodically multicasts a Re-Key 532 Event (RKE) message to the group. The RKE multicast contains 533 group policy directives, and new IPsec SA policy and keying 534 material. In the absence of a reliable multicast transport 535 protocol, the GCKS may re-transmit the RKE a policy defined 536 number of times to improve the availability of re-key 537 information. 539 - The RKE multicast configures the group's GSPD/SAD with the new 540 IPsec SAs. Each IPsec SA that replaces an existing SA is called a 541 "leading edge" IPsec SA. The leading edge IPsec SA has a new 542 Security Parameter Index (SPI) and its associated keying material 543 keys it. For a short period after the GCKS multicasts the RKE, a 544 Group Sender does not yet transmit data using the leading edge 545 IPsec SA. Meanwhile, other Group Members prepare to use this 546 IPsec SA by installing the new IPsec SAs to their respective 547 GSPD/SAD. 549 - After waiting a sufficiently long enough period such that all of 550 the Group Members have processed the RKE multicast, the Group 551 Sender begins to transmit using the leading edge IPsec SA with 552 its data encrypted by the new keying material. Only authorized 553 Group Members can decrypt these IPsec SA multicast transmissions. 554 The time delay that a Group Sender waits before starting its 555 first leading edge SA transmission is a GKM/IPsec policy 556 parameter. This value SHOULD be configurable at the Group Owner 557 management interface on a per group basis. 559 - The Group Sender's "trailing edge" SA is the oldest security 560 association in use by the group for that sender. All authorized 561 Group Members can receive and decrypt data for this SA, but the 562 Group Sender does not transmit new data using the "trailing edge" 563 SA after it has transitioned to the "leading edge SA". The 564 trailing edge SA is deleted by the group's endpoints according 565 to group policy (e.g., after a defined period has elapsed)" 567 This re-key rollover strategy allows the group to drain its in 568 transit datagrams from the network while transitioning to the 569 leading edge SA. Staggering the roles of each respective IPsec SA 570 as described above improves the group's synchronization even when 571 there are high network propagation delays. Note that due to group 572 membership joins and leaves, each Group Sender time epoch may have 573 a different group membership set. 575 It is a group policy decision whether the re-key event transition 576 between epochs provides forward and backward secrecy. The group's 577 re-key protocol keying material and algorithm (e.g. Logical Key 578 Hierarchy) enforces this policy. Implementations MAY offer a Group 579 Owner management interface option to enable/disable re-key rollover 580 continuity for a particular group. This specification requires that 581 a GKM/IPsec implementation MUST support at least two concurrent 582 IPsec SAs per Group Sender and this re-key rollover continuity 583 algorithm. 585 4.3 Data Origin Authentication 587 As defined in [RFC4301], data origin authentication is a security 588 service that verifies the identity of the claimed source of data. 589 A Message Authentication Code (MAC) is often used to achieve data 590 origin authentication for connections shared between two parties. 591 But typical MAC authentication methods using a single shared 592 secret are not sufficient to provide data origin authentication 593 for groups with more than two parties. With a MAC algorithm, every 594 group member can use the MAC key to create a valid MAC tag, 595 whether or not they are the authentic originator of the group 596 application's data. 598 When the property of data origin authentication is required for an 599 IPsec SA distributed from a GKCS, an authentication transform 600 where the originator keeps a secret should be used. Two possible 601 algorithms are TESLA [RFC4082] or RSA digital signature [RFC4359]. 603 In some cases, (e.g., digital signature authentication transforms) 604 the processing cost of the algorithm is significantly greater than 605 an HMAC authentication method. To protect against denial of 606 service attacks from device that is not authorized to join the 607 group, the IPsec SA using this algorithm may be encapsulated with 608 an IPsec SA using a MAC authentication algorithm. However, doing 609 so requires the packet to be sent across the IPsec boundary for 610 additional inbound processing (see Section 5.2 of [RFC4301]). This 611 use of ESP encapsulated within ESP accommodates the constraint 612 that an ESP trailer defines an Integrity Check Value (ICV) for 613 only a single authenticator transform. Relaxing this constraint on 614 the use of the ICV field is an area for future standardization. 616 4.4 Group SA and Key Management 618 4.4.1 Co-Existence of Multiple Key Management Protocols 620 Often, the GKM subsystem will be introduced to an existent IPsec 621 subsystem as a companion key management protocol to IKEv2 622 [RFC4306]. A fundamental GKM protocol IP Security subsystem 623 requirement is that both the GKM protocol and IKEv2 can 624 simultaneously share access to a common Group Security Policy 625 Database and Security Association Database. The mechanisms that 626 provide mutually exclusive access to the common GSPD/SAD data 627 structures are a local matter. This includes the GSPD-outbound 628 cache and the GSPD-inbound cache. However, implementers should note 629 that IKEv2 SPI allocation is entirely independent from GKM SPI 630 allocation because group security associations are qualified by a 631 destination multicast IP address and may optionally have a source 632 IP address qualifier. See [RFC4303, Section 2.1] for further 633 explanation. 635 The Peer Authorization Database does require explicit coordination 636 between the GKM protocol and IKEv2. Section 4.1.3 describes these 637 interactions. 639 4.4.2 New Security Association Attributes 641 A number of new security association attributes are defined to 642 convey extensions defined in this document. Each GKM protocol 643 supporting this architecture MUST support the following list of 644 attributes described elsewhere in this document. 646 - Address Preservation (Section 3.1). This attribute describes 647 whether address preservation is to be applied to the SA on the 648 source address, destination address, or both source and 649 destination addresses. 651 - Directional attribute (Section 4.1.1). This attribute describes 652 whether a pair of SAs (one in each direction) are to be installed 653 (to match the "symmetric" SPD directionality), only in the 654 outbound direction (to match "receiver only" SPD directionality), 655 or only in the inbound direction (to match "sender only" SPD 656 directionality). 658 - Any of the cryptographic transform-specific parameters and keys 659 that are sent from the GCKS to the Group Members (e.g. data origin 660 authentication parameters as described in section 4.3). 662 - Re-key rollover procedure time intervals (section 4.2.1). The 663 time that the Group Receiver IPsec subsystems will wait after 664 creating the leading edge IPsec SA before they will retire the 665 trailing edge IPsec SA. Also, the time that the Group Sender will 666 delay before it starts transmitting on the leading edges IPsec SA. 668 5. IP Traffic Processing 670 Processing of traffic follows Section 5 of [RFC4301], with the 671 additions described below when these IP multicast extensions are 672 supported. 674 5.1 Outbound IP Multicast Traffic Processing 676 If an IPsec SA is marked as supporting tunnel mode with address 677 preservation (as described in Section 3.1), either or both of the 678 outer header source or destination addresses is marked as being 679 preserved. If the source address is marked as being preserved, 680 during header construction the "src address" header field MUST be 681 "copied from inner hdr" rather than "constructed" as described in 682 [RFC4301]. Similarly, if the destination address is marked as being 683 preserved, during header construction the "dest address" header 684 field MUST be "copied from inner hdr" rather than "constructed". 686 5.2 Inbound IP Multicast Traffic Processing 688 If an IPsec SA is marked as supporting tunnel mode with address 689 preservation (as described in Section 3.1), the marked address 690 (i.e., source and/or destination address) on the outer IP header 691 MUST be verified to be the same value as the inner IP header. If 692 the addresses are not consistent, the IPsec system MUST treat the 693 error in the same manner as other invalid selectors, as described 694 in Section 5.2 of [RFC4301]. In particular the IPsec system MUST 695 discard the packet, as well as treat the inconsistency as an 696 auditable event. 698 6. Security Considerations 700 The IP security multicast extensions defined by this specification 701 build on the unicast-oriented IP security architecture [RFC4301]. 702 Consequently, this specification inherits many of the RFC4301 703 security considerations and the reader is advised to review it as 704 companion guidance. 706 6.1 Security Issues Solved by IPsec Multicast Extensions 708 The IP security multicast extension service provides the following 709 network layer mechanisms for secure group communications: 711 - Confidentiality using a group shared encryption key. 713 - Group source authentication and integrity protection using a 714 group shared authentication key. 716 - Group Sender data origin authentication using a digital 717 signature, TESLA, or other mechanism. 719 - Anti-replay protection for a limited number of Group Senders 720 using the ESP (or AH) sequence number facility. 722 - Filtering of multicast transmissions by those group members who 723 are not authorized by group policy to be Group Senders. This 724 feature leverages the IPsec state-less firewall service. 726 In support of the above services, this specification enhances the 727 definition of the SPD, PAD, and SAD databases to facilitate the 728 automated group key management of large-scale cryptographic groups. 730 6.2 Security Issues Not Solved by IPsec Multicast Extensions 732 As noted in RFC4301 section 2.2, it is out of scope of this 733 architecture to defend the group's keys or its application data 734 against those attacks against many aspects of the operating 735 environment in which the IPsec implementation executes. However, it 736 should be noted that the risk of attacks originating by an 737 adversary in the network is magnified to the extent that the group 738 keys are shared across a large number of systems. 740 The security issues that are left unsolved by the IPsec multicast 741 extension service divide into two broad categories: outsider 742 attacks, and insider attacks. 744 6.2.1 Outsider Attacks 745 The IPsec multicast extension service does not defend against an 746 Adversary outside of the group who has: 748 - The capability to launch a multicast flooding denial-of-service 749 attack against the group, originating from a system whose IPsec 750 subsystem does not filter the unauthorized multicast 751 transmissions. 753 - Compromised a multicast router, allowing the Adversary to corrupt 754 or delete all multicast packets destined for the group endpoints 755 downstream from that router. 757 - Captured a copy of an earlier multicast packet transmission and 758 then replays it to a group that does not have the anti-replay 759 service enabled. Note that for a large-scale any source multicast 760 group, it is impractical for the Group Receivers to maintain an 761 anti-replay state for every potential Group Sender. Group 762 policies that require anti-replay protection for a large-scale 763 any-source-multicast group should consider an application layer 764 total order multicast protocol. 766 6.2.2 Insider Attacks 768 For large-scale groups, the IP security multicast extensions are 769 dependent on an automated Group Key Management protocol to 770 correctly authenticate and authorize trustworthy members in 771 compliance to the group's policies. Inherent in the concept of a 772 cryptographic group is a set of one or more shared secrets 773 entrusted to all of the group's members. Consequently, the 774 service's security guarantees are no stronger than the weakest 775 member admitted to the group by the GKM system. The GKM system is 776 responsible for responding to compromised group member detection by 777 executing a group key recovery procedure. The GKM re-keying 778 protocol will expel the compromised group members and distribute 779 new group keying material to the trusted members. Alternatively, 780 the group policy may require the GKM system to terminate the group. 782 In the event that an Adversary has been admitted into the group by 783 the GKM system, the following attacks are possible and they can not 784 be solved by the IPsec multicast extension service: 786 - The Adversary can disclose the secret group key or group data to 787 an unauthorized party outside of the group. After a group key or 788 data compromise, cryptographic methods such as traitor tracing or 789 watermarking can assist in the forensics process. However, these 790 methods are outside the scope of this specification. 792 - The insider Adversary can forge packet transmissions that appear 793 to be from a peer group member. To defend against this attack for 794 those Group Sender transmissions that merit the overhead, the 795 group policy can require the Group Sender to multicast packets 796 using the data origin authentication service. 798 - If the group's data origin authentication service uses digital 799 signatures, then the insider Adversary can launch a computational 800 resource denial of service attack by multicasting bogus signed 801 packets. 803 6.3 Implementation or Deployment Issues that Impact Security 805 6.3.1 Homogeneous Group Cryptographic Algorithm Capabilities 807 The IP security multicast extensions service can not defend against 808 a poorly considered group security policy that allows a weaker 809 cryptographic algorithm simply because all of the group's endpoints 810 are known to support it. Unfortunately, large-scale groups can be 811 difficult to upgrade to the current best in class cryptographic 812 algorithms. One possible approach to solving many of these problems 813 is the deployment of composite groups that can straddle 814 heterogeneous groups [COMPGRP]. A standard solution for 815 heterogeneous groups is an activity for future standardization. In 816 the interim, synchronization of a group's cryptographic 817 capabilities could be achieved using a secure and scalable software 818 distribution management tool. 820 6.3.2 Groups that Span Two or More Security Policy Domains 822 Large-scale groups may span multiple legal jurisdictions (e.g 823 countries) that enforce limits on cryptographic algorithms or key 824 strengths. As currently defined, the IPsec multicast extension 825 service requires a single group policy per group. As noted above, 826 this problem remains an area for future standardization. 828 6.3.3 Network Address Translation 830 With the advent of NAT and mobile nodes, IPsec multicast 831 applications need to overcome several architectural barriers to 832 their successful deployment. This section surveys those problems 833 and identifies the GSPD/SAD state information that the GKM 834 protocol supporting NAT and mobile nodes need to synchronize 835 across the group membership. 837 6.3.3.1 GSPD Losses Synchronization with Internet Layer's State 839 The most prominent problem facing GKM protocols supporting IPsec 840 is that the GKM protocol's group security policy mechanism can 841 inadvertently configure the group's GSPD traffic selectors with 842 unreliable transient IP addresses. The IP addresses are transient 843 because of either node mobility or Network Address Translation 844 (NAT), both of which can unilaterally change a Group Sender's 845 source IP address without signaling the GKM protocol. The absence 846 of a GSPD synchronization mechanism can cause the group's data 847 traffic to be discarded rather than processed correctly. 849 6.3.3.2 Mobile Multicast Care-Of Address Route Optimization 851 Both Mobile IPv4 [RFC3344] and Mobile IPv6 provide transparent 852 unicast communications to a mobile Node. However, comparable 853 support for secure multicast mobility management is not specified 854 by these standards. The goal is the ability to maintain an end-to- 855 end transport mode group SA between a Group Sender mobile node that 856 has a volatile care-of-address and a Group Receiver membership that 857 also may have mobile endpoints. In particular, there is no secure 858 mechanism for route optimization of the triangular multicast path 859 between the correspondent Group Receiver nodes, the home agent, and 860 the mobile node. Any proposed solution needs to be secure against 861 hostile re-direct and flooding attacks. 863 6.3.3.3 NAT Translation Mappings Are Not Predictable 865 The following spontaneous NAT behaviors adversely impact source- 866 specific secure multicast groups. When a NAT gateway is on the 867 path between a Group Sender residing behind a NAT and a public 868 IPv4 multicast Group Receiver, the NAT gateway alters the private 869 source address to a public IPv4 address. This translation needs to 870 be coordinated with every Group Receiver's inbound GSPD multicast 871 entries that depend on that source address as a traffic selector. 872 One might mistakenly assume that the GCKS could set up the Group 873 Members with a GSPD entry that anticipates the value(s) that the 874 NAT translates the packet's source address. However, there are 875 known cases where this address translation can spontaneously 876 change without warning: 878 - NAT gateways may re-boot and lose their address translation 879 state information. 881 - The NAT gateway may de-allocate its address translation state 882 after an inactivity timer expires. The address translation used 883 by the NAT gateway after the resumption of data flow may differ 884 than that known to the GSPD selectors at the group endpoints. 886 - The GCKS may not have global consistent knowledge of a group 887 endpoint's current public and private address mappings due to 888 network errors or race conditions. For example, a Group Member's 889 address may change due to a DHCP assigned address lease 890 expiration. 892 - Alternate paths may exist between a given pair of Group Members. 893 If there are parallel NAT gateways along those paths, then the 894 address translation state information at each NAT gateway may 895 produce different translations on a per packet basis. 897 The consequence of this problem is that the GCKS can not be pre- 898 configured with NAT mappings, as the GSPD at the Group Members 899 will lose synchronization as soon as a NAT mapping changes due to 900 any of the above events. In the worst case, Group Members in 901 different sections of the network will see different NAT mappings, 902 because the multicast packet traversed multiple NAT gateways. 904 6.3.3.4 SSM Routing Dependency on Source IP Address 906 Source-Specific Multicast (SSM) routing depends on a multicast 907 packet's source IP address and multicast destination IP address to 908 make a correct forwarding decision. However, a NAT gateway alters 909 that packet's source IP address as its passes from a private 910 network into the public network. Mobility changes a Group Member's 911 point of attachment to the Internet, and this will change the 912 packet's source IP address. Regardless of why it happened, this 913 alteration in the source IP address makes it infeasible for transit 914 multicast routers in the public Internet to know which SSM sender 915 originated the multicast packet, which in turn selects the correct 916 multicast forwarding policy. 918 6.3.3.5 ESP Cloaks Its Payloads from NAT Gateway 920 When traversing NAT, application layer protocols that contain IPv4 921 addresses in their payload need the intervention of an Application 922 Layer Gateway (ALG) that understands that application layer 923 protocol [RFC3027] [RFC3235]. The ALG massages the payload's 924 private IPv4 addresses into equivalent public IPv4 addresses. 925 However, when encrypted by end-to-end ESP, such payloads are 926 opaque to application layer gateways. 928 When multiple Group Senders reside behind a NAT with a single 929 public IPv4 address, the NAT gateway can not do UDP or TCP 930 protocol port translation (i.e. NAPT) because the ESP encryption 931 conceals the transport layer protocol headers. The use of UDP 932 encapsulated ESP [RFC3948] avoids this problem. However, this 933 capability needs to be configured at the GCKS as a group policy, 934 and it needs to be supported in unison by all of the group 935 endpoints within the group, even those that reside in the public 936 Internet. 938 6.3.3.6 UDP Checksum Dependency on Source IP Address 940 An IPsec subsystem using UDP within an ESP payload will encounter 941 NAT induced problems. The original IPv4 source address is an input 942 parameter into a receiver's UDP pseudo-header checksum 943 verification, yet that value is lost after the IP header's address 944 translation by a transit NAT gateway. The UDP header checksum is 945 opaque within the encrypted ESP payload. Consequently, the checksum 946 can not be manipulated by the transit NAT gateways. UDP checksum 947 verification needs a mechanism that recovers the original source 948 IPv4 address at the Group Receiver endpoints. 950 In a transport mode multicast application GSA, the UDP checksum 951 operation requires the origin endpoint's IP address to complete 952 successfully. In IKEv2, this information is obtained from the 953 Traffic Selectors associated with the exchange [RFC4306, Section 954 2.23]. See also reference [RFC3947]. A facility that obtains the 955 same result needs to exist in a GKM protocol payload that defines 956 the multicast application GSA attributes for each Group Sender. 958 6.3.3.7 Cannot Use AH with NAT Gateway 960 The presence of a NAT gateway makes it impossible to use an 961 Authentication Header, keyed by a group-wide key, to protect the 962 integrity of the IP header for transmissions between members of 963 the cryptographic group. 965 7. IANA Considerations 967 This document has no actions for IANA. 969 8. Acknowledgements 971 The authors wish to thank Pasi Eronen and Tero Kivinen for their 972 helpful comments. 974 The "Guidelines for Writing RFC Text on Security Considerations" 975 [RFC3552] was consulted to develop the Security Considerations 976 section of this memo. 978 9. References 980 9.1 Normative References 982 [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 983 1112, August 1989. 985 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 986 Requirement Level", BCP 14, RFC 2119, March 1997. 988 [RFC3552] Rescorla, E., et. al., "Guidelines for Writing RFC Text 989 on Security Considerations", RFC 3552, July 2003. 991 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 992 Internet Protocol", RFC 4301, December 2005. 994 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 995 2005. 997 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 998 4303, December 2004. 1000 9.2 Informative References 1002 [COMPGRP] Gross G. and H. Cruickshank, "Multicast IP Security 1003 Composite Cryptographic Groups", draft- msec-ipsec- 1004 composite-group-01.txt, work in progress, February 2007. 1006 [RFC2526] Johnson, D., and S. Deering., "Reserved IPv6 Subnet 1007 Anycast Addresses", RFC 2526, March 1999. 1009 [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, 1010 September 2000. 1012 [RFC3027] Holdrege, M., and P. Srisuresh, "Protocol Complications 1013 with the IP Network Address Translator", RFC 3027, 1014 January 2001. 1016 [RFC3171] Albanni, Z., et. al., "IANA Guidelines for IPv4 1017 Multicast Address Assignments", RFC 3171, August 2001. 1019 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 1020 Application Design Guidelines", RFC 3235, January 2002. 1022 [RFC3306] Haberman B. and D. Thaler, " Unicast-Prefix-based IPv6 1023 Multicast Addresses", RFC3306, August 2002. 1025 [RFC3307] Haberman B., " Allocation Guidelines for IPv6 Multicast 1026 Addresses", RFC3307, August 2002. 1028 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1029 August 2002. 1031 [RFC3376] Cain, B., et. al., "Internet Group Management Protocol, 1032 Version 3", RFC 3376, October 2002. 1034 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 1035 Group Domain of Interpretation", RFC 3547, December 1036 2002. 1038 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1039 Multicast (SSM)", RFC 3569, July 2003. 1041 [RFC3740] Hardjono, Tl, and B. Weis, "The Multicast Group Security 1042 Architecture", RFC 3740, March 2004. 1044 [RFC3810] Vida, R., and L. Costa, "Multicast Listener Discovery 1045 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1047 [RFC3940] Adamson, B., et. al., "Negative-acknowledgment (NACK)- 1048 Oriented Reliable Multicast (NORM) Protocol", RFC 3940, 1049 November 2004. 1051 [RFC3947] Kivinen, T., et. al., "Negotiation of NAT-Traversal in 1052 the IKE", RFC 3947, January 2005. 1054 [RFC3948] Huttunen, A., et. al., "UDP Encapsulation of IPsec ESP 1055 Packets", RFC 3948, January 2005. 1057 [RFC4046] Baugher, M., Dondeti, L., Canetti, R., and F. Lindholm, 1058 "Multicast Security (MSEC) Group Key Management 1059 Architecture", RFC4046, April 2005. 1061 [RFC4082] Perrig, A., et. al., "Timed Efficient Stream Loss- 1062 Tolerant Authentication (TESLA): Multicast Source 1063 Authentication Transform Introduction", RFC 4082, June 1064 2005. 1066 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1067 RFC 4306, December 2005. 1069 [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within 1070 Encapsulating Security Payload (ESP) and Authentication 1071 Header (AH)", RFC 4359, January 2006. 1073 [RFC4534] Colegrove, A., and H. Harney, "Group Security Policy 1074 Token v1", RFC 4534, June 2006. 1076 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 1077 "GSAKMP: Group Secure Association Key Management 1078 Protocol", RFC 4535, June 2006. 1080 [RFC4601] Fenner, B., et. al., "Protocol Independent Multicast - 1081 Sparse Mode (PIM-SM): Protocol Specification 1082 (Revised)", RFC 4601, August 2006. 1084 [ZLLY03] Zhang, X., et. al., "Protocol Design for Scalable and 1085 Reliable Group Rekeying", IEEE/ACM Transactions on 1086 Networking (TON), Volume 11, Issue 6, December 2003. See 1087 http://www.cs.utexas.edu/users/lam/Vita/Cpapers/ZLLY01.p 1088 df. 1090 Appendix A - Multicast Application Service Models 1092 The vast majority of secure multicast applications can be 1093 catalogued by their service model and accompanying intra-group 1094 communication patterns. Both the Group Key Management (GKM) 1095 Subsystem and the IPsec subsystem MUST be able to configure the 1096 GSPD/SAD security policies to match these dominant usage scenarios. 1097 The GSPD/SAD policies MUST include the ability to configure both 1098 Any-Source-Multicast groups and Source-Specific-Multicast groups 1099 for each of these service models. The GKM Subsystem management 1100 interface MAY include mechanisms to configure the security policies 1101 for service models not identified by this standard. 1103 A.1 Unidirectional Multicast Applications 1105 Multi-media content delivery multicast applications that do not 1106 have congestion notification or retransmission error recovery 1107 mechanisms are inherently unidirectional. RFC 4301 only defines bi- 1108 directional unicast traffic selectors (as per sections 4.4.1 and 1109 5.1 with respect to traffic selector directionality). The GKM 1110 Subsystem requires that the IPsec subsystem MUST support 1111 unidirectional SPD entries, which cause a Group Security 1112 Associations (GSA)to be installed in only one direction. Multicast 1113 applications that have only one group member authorized to transmit 1114 can use this type of group security association to enforce that 1115 group policy. In the inverse direction, the GSA does not have a SAD 1116 entry, and the GSPD configuration is optionally setup to discard 1117 unauthorized attempts to transmit unicast or multicast packets to 1118 the group. 1120 The GKM Subsystem's management interface MUST have the ability to 1121 setup a GKM Subsystem group having a unidirectional GSA security 1122 policy. 1124 A.2 Bi-directional Reliable Multicast Applications 1126 Some secure multicast applications are characterized as one Group 1127 Sender to many receivers, but with inverse data flows required by a 1128 reliable multicast transport protocol (e.g. NORM). In such 1129 applications, the data flow from the sender is multicast, and the 1130 inverse flow from the group's receivers is unicast to the sender. 1131 Typically, the inverse data flows carry error repair requests and 1132 congestion control status. 1134 For such applications, it is advantageous to use the same IPsec SA 1135 for protection of both unicast and multicast data flows. This does 1136 introduce one risk: the IKEv2 application may choose the same SPI 1137 for receiving unicast traffic as the GCKS chooses for a group 1138 IPsec SA covering unicast traffic. If both SAs are installed in 1139 the SAD, the SA lookup may return the wrong SPI as the result of 1140 an SA lookup. To avoid this problem, IPsec SAs installed by the 1141 GKM SHOULD use the 2-tuple {destination IP address, SPI} to 1142 identify each IPsec SA. In addition, the GKM SHOULD use a unicast 1143 destination IP address that does not match any destination IP 1144 address in use by an IKE-v2 unicast IPsec SA. For example, suppose 1145 a Group Member is using both IKEv2 and a GKM protocol, and and the 1146 group security policy requires protecting the NORM inverse data 1147 flows as described above. In this case, group policy SHOULD 1148 allocate and use a unique unicast destination IP address 1149 representing the NORM Group Sender. This address would be 1150 configured in parallel to the Group Sender's existing IP 1151 addresses. The GKM subsystems at both the NORM Group Sender and 1152 Group Receiver endpoints would install the IPsec SA protecting the 1153 NORM unicast messages such that the SA lookup uses the unicast 1154 destination address as well as the SPI. 1156 The GSA SHOULD use IPsec anti-replay protection service for the 1157 sender's multicast data flow to the group's receivers. Because of 1158 the scalability problem described in the next section, it is not 1159 practical to use the IPsec anti-replay service for the unicast 1160 inverse flows. Consequently, in the inverse direction the IPsec 1161 anti-replay protection MUST be disabled. However, the unicast 1162 inverse flows can use the group's IPsec group authentication 1163 mechanism. The group receiver's GSPD entry for this GSA SHOULD be 1164 configured to only allow a unicast transmission to the sender Node 1165 rather than a multicast transmission to the whole group. 1167 If an ESP digital signature authentication is available (E.g., RFC 1168 4359), source authentication MAY be used to authenticate a receiver 1169 Node's transmission to the sender. The GKM protocol MUST define a 1170 key management mechanism for the Group Sender to validate the 1171 asserted signature public key of any receiver Node without 1172 requiring that the sender maintain state about every group 1173 receiver. 1175 This multicast application service model is RECOMMENDED because it 1176 includes congestion control feedback capabilities. Refer to 1177 [RFC2914] for additional background information. 1179 The GKM Subsystem's Group Owner management interface MUST have the 1180 ability to setup a symmetric GSPD entry and one Group Sender. The 1181 management interface SHOULD be able to configure a group to have at 1182 least 16 concurrent authorized senders, each with their own GSA 1183 anti-replay state. 1185 A.3 Any-To-Any Multicast Applications 1187 Another family of secure multicast applications exhibits a "any to 1188 many" communications pattern. A representative example of such an 1189 application is a videoconference combined with an electronic 1190 whiteboard. 1192 For such applications, all (or a large subset) of the Group Members 1193 are authorized multicast senders. In such service models, creating 1194 a distinct IPsec SA with anti-replay state for every potential 1195 sender does not scale to large groups. The group SHOULD share one 1196 IPsec SA for all of its senders. The IPsec SA SHOULD NOT use the 1197 IPsec anti-replay protection service for the sender's multicast 1198 data flow to the Group Receivers. 1200 The GKM Subsystem's management interface MUST have the ability to 1201 setup a group having an Any-To-Many Multicast GSA security policy. 1203 Author's Address 1205 Brian Weis 1206 Cisco Systems 1207 170 W. Tasman Drive, 1208 San Jose, CA 95134-1706 1209 USA 1211 Phone: +1-408-526-4796 1212 Email: bew@cisco.com 1214 George Gross 1215 IdentAware Security 1216 82 Old Mountain Road 1217 Lebanon, NJ 08833 1218 USA 1220 Phone: +1-908-268-1629 1221 Email: gmgross@identaware.com 1223 Dragan Ignjatic 1224 Polycom 1225 1000 W. 14th Street 1226 North Vancouver, BC V7P 3P3 1227 Canada 1229 Phone: +1-604-982-3424 1230 Email: dignjatic@polycom.com 1232 Full Copyright Statement 1234 Copyright (C) The IETF Trust (2007). 1236 This document is subject to the rights, licenses and restrictions 1237 contained in BCP 78, and except as set forth therein, the authors 1238 retain all their rights. 1240 This document and the information contained herein are provided on 1241 an 1242 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1243 REPRESENTS 1244 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 1245 AND 1246 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1247 EXPRESS 1248 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 1249 OF 1250 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1251 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1253 Intellectual Property 1255 The IETF takes no position regarding the validity or scope of any 1256 Intellectual Property Rights or other rights that might be claimed 1257 to 1258 pertain to the implementation or use of the technology described 1259 in 1260 this document or the extent to which any license under such rights 1261 might or might not be available; nor does it represent that it has 1262 made any independent effort to identify any such rights. 1263 Information 1264 on the procedures with respect to rights in RFC documents can be 1265 found in BCP 78 and BCP 79. 1267 Copies of IPR disclosures made to the IETF Secretariat and any 1268 assurances of licenses to be made available, or the result of an 1269 attempt made to obtain a general license or permission for the use 1270 of 1271 such proprietary rights by implementers or users of this 1272 specification can be obtained from the IETF on-line IPR repository 1273 at 1274 http://www.ietf.org/ipr. 1276 The IETF invites any interested party to bring to its attention 1277 any 1278 copyrights, patents or patent applications, or other proprietary 1279 rights that may cover technology that may be required to implement 1280 this standard. Please address the information to the IETF at 1281 ietf-ipr@ietf.org. 1283 Acknowledgement 1285 Funding for the RFC Editor function is provided by the IETF 1286 Administrative Support Activity (IASA).