idnits 2.17.1 draft-ietf-msec-ipsec-extensions-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1288. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 38 characters in excess of 72. ** 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 RFC 3978 Section 5.4 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) == Missing Reference: 'MLD' is mentioned on line 258, but not defined == Missing Reference: 'RFC3740' is mentioned on line 504, but not defined == Missing Reference: 'Section 4' is mentioned on line 504, but not defined == Missing Reference: 'RFC 3948' is mentioned on line 650, but not defined == Missing Reference: 'Section 5' is mentioned on line 658, but not defined == Missing Reference: 'RFC3235' is mentioned on line 780, but not defined == Missing Reference: 'RFC1918' is mentioned on line 872, but not defined == Missing Reference: 'RFC3056' is mentioned on line 901, but not defined == Missing Reference: 'BEHAVE' is mentioned on line 932, but not defined == Missing Reference: 'TBD' is mentioned on line 1035, but not defined == Unused Reference: 'RFC3552' is defined on line 1047, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 1082, but no explicit reference was found in the text == Unused Reference: 'RFC2588' is defined on line 1093, but no explicit reference was found in the text == Unused Reference: 'RFC3547' is defined on line 1117, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2362 (Obsoleted by RFC 4601, RFC 5059) -- 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) Summary: 5 errors (**), 0 flaws (~~), 16 warnings (==), 13 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 Expires: December, 2006 G. Gross 4 IdentAware Security 5 D. Ignjatic 6 Polycom 7 June, 2006 9 Multicast Extensions to the Security Architecture for the Internet 10 Protocol 11 draft-ietf-msec-ipsec-extensions-02.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 months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The Security Architecture for the Internet Protocol [RFC4301] 44 describes security services for traffic at the IP layer. That 45 architecture primarily defines services for Internet Protocol (IP) 46 unicast packets, as well as manually configured IP multicast packets. 47 This document further defines the security services for manually and 48 dynamically keyed IP multicast packets within that Security 49 Architecture. 51 Table of Contents 53 1. Introduction........................................................3 54 1.1 Scope............................................................4 55 1.2 Terminology......................................................5 57 2. Overview of IP Multicast Operation..................................6 58 3. Security Association Modes..........................................7 59 3.1 Tunnel Mode with Address Preservation............................7 60 4. Security Association................................................8 61 4.1 Major IPsec Databases............................................8 62 4.1.1 Group Security Policy Database (GSPD)........................9 63 4.1.2 Security Association Database (SAD).........................10 64 4.1.3 Peer Authorization Database (PAD)...........................10 66 4.2 Group Security Association (GSA)................................12 67 4.3 Data Origin Authentication......................................13 68 4.4 Group SA and Key Management.....................................14 69 4.4.1 Co-Existence of Multiple Key Management Protocols...........14 70 4.4.2 New Security Association Attributes.........................14 71 5. IP Traffic Processing..............................................15 72 5.1 Outbound IP Multicast Traffic Processing........................15 74 5.2 Inbound IP Multicast Traffic Processing.........................15 75 6. IP-v4 Network Address Translation..................................15 76 6.1 GSPD Losses Synchronization with Internet Layer's State.........16 77 6.1.1 Mobile Multicast Care-Of Address Route Optimization.........16 78 6.1.2 NAT Translation Mappings Are Not Predictable................16 79 6.2 Secondary Problems Created by NAT Traversal.....................17 80 6.2.1 SSM Routing Dependency on Source IP Address.................17 81 6.2.2 ESP Cloaks Its Payloads from NAT Gateway....................17 83 6.2.3 UDP Checksum Dependency on Source IP Address................18 84 6.2.4 Cannot Use AH with NAT Gateway..............................18 85 6.3 Avoidance of NAT Using an IPv6 Over IPv4 Network................18 86 6.4 GKM/IPsec Multi-Realm IPv4 NAT Architecture.....................19 87 6.4.1 GKM/IPsec IPv4 NAT Architectural Assumptions................20 88 6.4.2 Multicast Application GSA NAT Traversal.....................21 89 6.5 ESP Encapsulated by UDP in a Multicast Group....................22 91 7. Security Considerations............................................22 92 8. IANA Considerations................................................23 93 9. Acknowledgements...................................................23 94 10. References........................................................23 95 10.1 Normative References...........................................23 96 10.2 Informative References.........................................23 97 Appendix A _ Multicast Application Service Models.....................26 98 A.1 Unidirectional Multicast Applications...........................26 100 A.2 Bi-directional Reliable Multicast Applications..................26 101 A.3 Any-To-Any Multicast Applications...............................27 103 Author's Address......................................................28 104 Intellectual Property Statement.......................................29 105 Copyright Statement...................................................29 107 1. Introduction 109 The Security Architecture for the Internet Protocol [RFC4301] 110 provides security services for traffic at the IP layer. It describes 111 an architecture for IPsec compliant systems, and a set of security 112 services for the IP layer. These security services primarily describe 113 services and semantics for IPsec Security Associations (SAs) shared 114 between two IPsec devices. Typically, this includes SAs with traffic 115 selectors that include a unicast address in the IP destination field, 116 and results in an IPsec packet with a unicast address in the IP 117 destination field. The security services defined in RFC 4301 can also 118 be used to tunnel IP multicast packets, where the tunnel is a 119 pairwise association between two IPsec devices. RFC4301 defined 120 manually keyed transport mode IPsec SA support for IP packets with a 121 multicast address in the IP destination address field. However, 122 RFC4301 did not define the interaction of an IPsec subsystem with a 123 Group Key Management protocol or the semantics of a tunnel mode IPsec 124 SA with an IP multicast address in the outer IP header. 126 This document describes extensions to RFC 4301 that further define 127 the IPsec security architecture for groups of IPsec devices to share 128 SAs. In particular, it supports SAs with traffic selectors that 129 include a multicast address in the IP destination field, and results 130 in an IPsec packet with an IP multicast address in the IP destination 131 field. It also describes additional semantics for IPsec Group Key 132 Management (GKM) subsystems. Note that this document uses the term 133 "GKM protocol" generically and therefore it does not assume a 134 particular GKM protocol. 136 1.1 Scope 138 The IPsec extensions described in this document support IPsec 139 Security Associations that result in IPsec packets with IPv4 or IPv6 140 multicast group addresses as the destination address. Both Any-Source 141 Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569] 142 [RFC3376] group addresses are supported. 144 These extensions also support Security Associations with IPv4 145 Broadcast addresses that result in an IPv4 link-level broadcast 146 packet, and IPv6 Anycast addresses [RFC2526] that result in an IPv6 147 Anycast packet. These destination address types share many of the 148 same characteristics of multicast addresses because there may be 149 multiple receivers of a packet protected by IPsec. 151 The IPsec architecture does not make requirements upon entities not 152 participating in IPsec (e.g., network devices between IPsec 153 endpoints). As such, these multicast extensions do not require 154 intermediate systems in a multicast enabled network to participate in 155 IPsec. In particular, no requirements are placed on the use of 156 multicast routing protocols (e.g., PIM-SM [RFC2362]) or multicast 157 admission protocols (e.g., IGMP [RFC3376]. 159 All implementation models of IPsec (e.g., "bump-in-the-stack", "bump- 160 in-the-wire") are supported. 162 This version of the multicast IPsec extension specification requires 163 that all IPsec devices participating in a Security Association are 164 homogeneous. They MUST share a common set of cryptographic transform 165 and protocol handling capabilities. The semantics of an "IPsec 166 composite group", a heterogeneous IPsec cryptographic group formed 167 from the union of two or more sub-groups, is an area for future 168 standardization. 170 1.2 Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 The following key terms are used throughout this document. 178 Any-Source Multicast (ASM) 179 The Internet Protocol (IP) multicast service model as defined in 180 RFC 1112 [RFC1112]. In this model one or more senders source 181 packets to a single IP multicast address. When receivers join the 182 group, they receive all packets sent to that IP multicast address. 183 This is known as a (*,G) group. 185 Group Controller Key Server (GCKS) 186 A Group Key Management (GKM) protocol server that manages IPsec 187 state for a group. A GCKS authenticates and provides the IPsec SA 188 policy and keying material to GKM group members. 190 Group Key Management (GKM) Protocol 191 A key management protocol used by a GCKS to distribute IPsec 192 Security Association policy and keying material. A GKM protocol is 193 used when a group of IPsec devices require the same SAs. For 194 example, when an IPsec SA describes an IP multicast destination, 195 the sender and all receivers must have the group SA. 197 Group Key Management Subsystem 198 A subsystem in an IPsec device implementing a Group Key Management 199 protocol. The GKM subsystem provides IPsec SAs to the IPsec 200 subsystem on the IPsec device. 202 Group Member 203 An IPsec device that belongs to a group. A Group Member is 204 authorized to be a Group Speaker and/or a Group Receiver. 206 Group Owner 207 An administrative entity that chooses the policy for a group. 209 Group Security Association (GSA) 210 A collection of IPsec Security Associations (SAs) and GKM 211 Subsystem SAs necessary for a Group Member to receive key updates. 212 A GSA describes the working policy for a group. Refer to RFC4046 213 [RFC4046] for additional information. 215 Group Security Policy Database (GSPD) 216 The GSPD is a multicast-capable security policy database, as 217 mentioned in RFC3740 and RFC4301 section 4.4.1.1. Its semantics 218 are a superset of the unicast SPD defined by RFC4301 section 219 4.4.1. Unlike a unicast SPD-S in which point-to-point security 220 associations are inherently bi-directional, multicast security 221 associations in the GSPD-S introduce a "sender only" or "receiver 222 only" or "symmetric" SA direction attribute. Refer to section 223 4.1.1 for more details. 225 Group Receiver 226 A Group Member that is authorized to receive packets sent to a 227 group by a Group Speaker. 229 Group Speaker 230 A Group Member that is authorized to send packets to a group. 232 Source-Specific Multicast (SSM) 233 The Internet Protocol (IP) multicast service model as defined in 234 RFC 3569 [RFC3569]. In this model, each combination of a sender 235 and an IP multicast address is considered a group. This is known 236 as an (S,G) group. 238 Tunnel Mode with Address Preservation 239 A type of IPsec tunnel mode used by security gateway 240 implementations when encapsulating IP multicast packets such that 241 they remain IP multicast packets. This mode is necessary for IP 242 multicast routing to correctly route IP multicast packets 243 protected by IPsec. 245 2. Overview of IP Multicast Operation 247 IP multicasting is a means of sending a single packet to a "host 248 group", a set of zero or more hosts identified by a single IP 249 destination address. IP multicast packets are UDP data packets 250 delivered to all members of the group with either "best-effort" 251 [RFC1112], or reliable delivery (e.g., NORM) [RFC3940]. 253 A sender to an IP multicast group sets the destination of the packet 254 to an IP address that has been allocated for IP multicast. Allocated 255 IP multicast addresses are defined in RFC 3171, RFC3306, and RFC3307 256 [RFC3171] [RFC3306] [RFC3307]. Potential receivers of the packet 257 "join" the IP multicast group by registering with a network routing 258 device [RFC3376] [MLD], signaling its intent to receive packets sent 259 to a particular IP multicast group. 261 Network routing devices configured to pass IP multicast packets 262 participate in multicast routing protocols (e.g., PIM-SM) [RFC2362]. 263 Multicast routing protocols maintain state regarding which devices 264 have registered to receive packets for a particular IP multicast 265 group. When a router receives an IP multicast packet, it forwards a 266 copy of the packet out each interface for which there are known 267 receivers. 269 3. Security Association Modes 271 IPsec supports two modes of use: transport mode and tunnel mode. In 272 transport mode, IP Authentication Header (AH) [RFC4302] and IP 273 Encapsulating Security Payload (ESP) [RFC4303] provide protection 274 primarily for next layer protocols; in tunnel mode, AH and ESP are 275 applied to tunneled IP packets. 277 A host implementation of IPsec using the multicast extensions MAY use 278 either transport mode and tunnel mode to encapsulate an IP multicast 279 packet. These processing rules are identical to the rules described 280 in [RFC4301, Section 4.1]. However, the destination address for the 281 IPsec packet is an IP multicast address, rather than a unicast host 282 address. 284 A security gateway implementation of IPsec using the multicast 285 extensions MUST use a tunnel mode SA, for the reasons described in 286 [RFC4301, Section 4.1]. In particular, the security gateway must use 287 tunnel mode to encapsulate incoming fragments, since IPsec cannot 288 directly operate on fragments. 290 3.1 Tunnel Mode with Address Preservation 292 New header construction semantics are required when tunnel mode is 293 used to encapsulate IP multicast packets that are to remain IP 294 multicast packets. This is due to the following unique requirements 295 of IP multicast routing protocols (e.g., PIM-SM [RFC2362]). 297 - IP multicast routing protocols compare the destination address on 298 a packet to the multicast routing state. If the destination of an 299 IP multicast packet is changed it will no longer be properly 300 routed. Therefore, an IPsec security gateway must preserve the 301 multicast IP destination address after IPsec tunnel encapsulation. 303 The GKM Subsystem on a security gateway implementing the IPsec 304 multicast extensions preserves the multicast IP address as 305 follows. Firstly, the GKM Subsystem sets the Remote Address PFP 306 flag in the GSPD-S entry for the traffic selectors. This flag 307 causes the remote address of the packet matching IPsec SA traffic 308 selectors to be propagated to the IPsec tunnel encapsulation. 309 Secondly, the GKM Subsystem needs to signal that destination 310 address preservation is in effect for a particular IPsec SA. The 311 GKM protocol MUST define an attribute that signals destination 312 address preservation to the GKM Subsystem on an IPsec security 313 gateway. 315 - IP multicast routing protocols also typically create multicast 316 distribution trees based on the source address. If an IPsec 317 security gateway changes the source address of an IP multicast 318 packet (e.g., to its own IP address), the resulting IPsec 319 protected packet may fail RPF checks on other routers. A failed 320 RPF check may result in the packet being dropped. 322 To accommodate routing protocol RPF checks, the GKM Subsystem on a 323 security gateway implementation implementing the IPsec multicast 324 extensions must preserve the original packet IP source address as 325 follows. Firstly, the GSPD-S entry for the traffic selectors must 326 have the Source Address PFP flag set. This flag causes the remote 327 address to be propagated to the IPsec SA. Secondly, the GKM 328 Subsystem needs to signal that source address preservation is in 329 effect for a particular IPsec SA. The GKM Subsystem MUST define a 330 protocol attribute that signals source address preservation to the 331 GKM Subsystem on an IPsec security gateway. 333 Some applications of address preservation may only require the 334 destination address to be preserved. For this reason, the 335 specification of destination address preservation and source address 336 preservation are separated in the above description. 338 Address preservation is applicable only for tunnel mode IPsec SAs 339 that specify the IP version of the encapsulating header to be the 340 same version as that of the inner header. When the IP versions are 341 different, tunnel processing semantics described in RFC 4301 MUST be 342 followed. 344 In summary, retaining both the IP source and destination addresses of 345 the inner IP header allow IP multicast routing protocols to route the 346 packet irrespective of the packet being IPsec protected. This result 347 is necessary in order for the multicast extensions to allow a 348 security gateway to provide IPsec services for IP multicast packets. 349 This variation of RFC4301 tunnel mode is known as "tunnel mode with 350 address preservation". 352 4. Security Association 354 4.1 Major IPsec Databases 356 The following sections describe the GKM Subsystem and IPsec extension 357 interactions with the major IPsec databases. The major IPsec 358 databases needed expanded semantics to fully support multicast. 360 4.1.1 Group Security Policy Database (GSPD) 362 The Group Security Policy Database is a security policy database 363 capable of implementing both unicast security associations as defined 364 by RFC4301 and the multicast extensions defined by this 365 specification. A new Group Security Policy Database (GSPD) attribute 366 is introduced: GSPD entry directionality. Directionality can take 367 three types. Each GSPD entry can be marked "symmetric", "sender only" 368 or "receiver only". Symmetric GSPD entries are the common entries as 369 specified by RFC 4301. Symmetric SHOULD be the default directionality 370 unless specified otherwise. GSPD entries marked as "sender only" or 371 "receiver only" SHOULD support multicast IP addresses in their 372 destination address selectors. If the processing requested is bypass 373 or discard and a sender only type is configured the entry SHOULD be 374 put in GSPD-O only. Reciprocally, if the type is receiver only, the 375 entry SHOULD go to GSPD-I only. SSM is supported by the use of 376 unicast IP address selectors as documented in RFC 4301. 378 GSPD entries created by a GCKS may be assigned identical SPIs to SPD 379 entries created by IKEv2 [RFC4306]. This is not a problem for the 380 inbound traffic as the appropriate SAs can be matched using the 381 algorithm described in RFC 4301 section 4.1. In addition, SAs with 382 identical SPI values but not manually keyed can be differentiated 383 because they contain a link to their parent SPD entries. However, the 384 outbound traffic needs to be matched against the GSPD selectors so 385 that the appropriate SA can be created on packet arrival. IPsec 386 implementations that support multicast MUST use the destination 387 address as the additional selector and match it against the GSPD 388 entries marked "sender only". 390 To facilitate dynamic group keying, the outbound GSPD MUST implement 391 a policy action capability that triggers a GKM protocol registration 392 exchange (as per [RFC4301] section 5.1). For example, the Group 393 Speaker GSPD policy might trigger on a match with a specified 394 multicast application packet. The ensuing Group Speaker registration 395 exchange would setup the Group Speaker's outbound SAD entry that 396 encrypts the multicast application's data stream. In the inverse 397 direction, group policy may also setup an inbound IPsec SA. 399 At the Group Receiver endpoint(s), the GSPD policy might trigger on a 400 match with the multicast application packet sent from the Group 401 Speaker. The ensuing Group Receiver registration exchange would setup 402 the Group Receiver's inbound SAD entry that decrypts the multicast 403 application's data stream. In the inverse direction, the group policy 404 may also setup an outbound IPsec SA (e.g. when supporting an ASM 405 service model). 407 The IPsec subsystem MAY provide GSPD policy mechanisms (e.g. trigger 408 on detection of IGMP/MLD leave group exchange) that automatically 409 initiate a GKM protocol de-registration exchange. De-registration 410 minimizes exposure of the group's secret key. It also minimizes cost 411 for those groups that incur cost on the basis of membership duration. 413 Alternatively, the GKM subsystem MAY setup the GSPD/SAD state 414 information independent of the multicast application's state. In this 415 scenario, the group's Group Owner issues management directives that 416 tells the GKM subsystem when it should start GKM registration and de- 417 registration protocol exchanges. Typically the registration policy 418 strives to make sure that the group's IPsec subsystem state is 419 "always ready" in anticipation of the multicast application starting 420 its execution. 422 4.1.2 Security Association Database (SAD) 424 The Security Association Database (SAD) can support multicast SAs, if 425 manually configured. An outbound multicast SA has the same structure 426 as a unicast SA. The source address is that of the Group Speaker and 427 the destination address is the multicast group address. An inbound 428 multicast SA must be configured with the source addresses of each 429 Group Speaker peer authorized to transmit to the multicast SA in 430 question. The SPI value for a multicast SA is provided by a GCKS, not 431 by the receiver as occurs for a unicast SA. Other than the SPI 432 assignment and the inbound packet de-multiplexing described in 433 RFC4301 section 4.1, the SAD behaves identically for unicast and 434 multicast security associations. 436 4.1.3 Peer Authorization Database (PAD) 438 The Peer Authorization Database (PAD) needs to be extended in order 439 to accommodate peers that may take on specific roles in the group. 440 Such roles can be GCKS, Group Speaker (in case of SSM) or a Group 441 Receiver. A peer can have multiple roles. The PAD may also contain 442 root certificates for PKI used by the group. 444 4.1.3.1 GKM/IPsec Interactions with the PAD 446 The RFC 4301 section 4.4.3 introduced the PAD. In summary, the PAD 447 manages the IPsec entity authentication mechanism(s) and 448 authorization of each such peer identity to negotiate modifications 449 to the GSPD/SAD. Within the context of the GKM/IPsec subsystem, the 450 PAD defines for each group: 452 . For those groups that authenticate identities using a Public Key 453 Infrastructure, the PAD contains the group's set of one or more 454 trusted root public key certificates. The PAD may also include the 455 PKI configuration data needed to retrieve supporting certificates 456 needed for an end entity's certificate path validation. 458 . A set of one or more group membership authorization rules. The 459 GCKS examines these rules to determine a candidate group member's 460 acceptable authentication mechanism and to decide whether that 461 candidate has the authority to join the group. 463 . A set of one or more GCKS role authorization rules. A group member 464 uses these rules to decide which systems are authorized to act as 465 a GCKS for a given group. These rules also declare the permitted 466 GCKS authentication mechanism(s). 468 . A set of one or more Group Speaker role authorization rules. In 469 some groups the group members allowed to send protected packets is 470 restricted. 472 Some GKM protocols (e.g. GSAKMP [GSAKMP]) distribute their group's 473 PAD configuration in a security policy token [COREPT] signed by the 474 group's policy authority, also known as the Group Owner (GO). Each 475 group member receives the policy token (using a method not described 476 in this memo) and verifies the Group Owner's signature on the policy 477 token. If that GO signature is accepted, then the group member 478 dynamically updates its PAD with the policy token's contents. 480 The PAD MUST provide a management interface capability that allows an 481 administrator to enforce that the scope of a GKM group's policy 482 specified GSPD/SAD modifications are restricted to only those traffic 483 data flows that belong to that group. This authorization MUST be 484 configurable at GKM group granularity. In the inverse direction, the 485 PAD management interface MUST provide a mechanism(s) to enforce that 486 IKEv2 security associations do not negotiate traffic selectors that 487 conflict or override GKM group policies. An implementation SHOULD 488 offer PAD configuration capabilities that authorize the GKM policy 489 configuration mechanism to set security policy for other aspects of 490 an endpoint's GSPD/SAD configuration, not confined to its group 491 security associations. This capability allows the group's policy to 492 inhibit the creation of back channels that might otherwise leak 493 confidential group application data. 495 This document refers to re-key mechanisms as being multicast because 496 of the inherent scalability of IP multicast distribution. However, 497 there is no particular reason that re-key mechanisms must be 498 multicast. For example, [ZLLY03] describes a method of re-key 499 employing both unicast and multicast messages. 501 4.2 Group Security Association (GSA) 502 An IPsec implementation supporting these extensions has a number of 503 security associations: one or more IPsec SAs, and one or more GKM SAs 504 used to download IPsec SAs [RFC3740, Section 4]. These SAs are 505 collectively referred to as a Group Security Association (GSA). 507 4.2.4.1 Concurrent IPsec SA Life Spans and Re-key Rollover 509 During a cryptographic group's lifetime, multiple IPsec security 510 associations can exist concurrently. This occurs principally due to 511 two reasons: 513 - There are multiple Group Speakers authorized in the group, each 514 with its own IPsec SA that maintains anti-replay state. A group 515 that does not rely on IP Security anti-replay services can share 516 one IPsec SA for all of its Group Speakers. 518 - The life spans of a Group Speaker's two (or more) IPsec SAs are 519 allowed to overlap in time, so that there is continuity in the 520 multicast data stream across group re-key events. This capability 521 is referred to as "re-key rollover continuity". 523 Each group re-key multicast message sent by a GCKS signals the start 524 of a new Group Speaker time epoch, with each such epoch having an 525 associated IPsec SA. The group membership interacts with these IPsec 526 SAs as follows: 528 - As a precursor to the Group Speaker beginning its re-key rollover 529 continuity processing, the GCKS periodically multicasts a Re-Key 530 Event (RKE) message to the group. The RKE multicast contains group 531 policy directives, and new IPsec SA policy and keying material. In 532 the absence of a reliable multicast transport protocol, the GCKS 533 may re-transmit the RKE a policy defined number of times to improve 534 the availability of re-key information. 536 - The RKE multicast configures the group's GSPD/SAD with the new 537 IPsec SAs. Each IPsec SA that replaces an existing SA is called a 538 "leading edge" IPsec SA. The leading edge IPsec SA has a new 539 Security Parameter Index (SPI) and its associated keying material 540 keys it. For a short period after the GCKS multicasts the RKE, a 541 Group Speaker does not yet transmit data using the leading edge 542 IPsec SA. Meanwhile, other Group Members prepare to use this IPsec 543 SA by installing the new IPsec SAs to their respective GSPD/SAD. 545 - After waiting a sufficiently long enough period such that all of 546 the Group Members have processed the RKE multicast, the Group 547 Speaker begins to transmit using the leading edge IPsec SA with its 548 data encrypted by the new keying material. Only authorized Group 549 Members can decrypt these IPsec SA multicast transmissions. The 550 time delay that a Group Speaker waits before starting its first 551 leading edge SA transmission is a GKM/IPsec policy parameter. This 552 value SHOULD be configurable at the Group Owner management 553 interface on a per group basis. 555 - The Group Speaker's "trailing edge" SA is the oldest security 556 association in use by the group for that speaker. All authorized 557 Group Members can receive and decrypt data for this SA, but the 558 Group Speaker does not transmit new data using the "trailing edge" 559 SA after it has transitioned to the "leading edge GSA". The 560 trailing edge SA is deleted by the group's endpoints according to 561 group policy (e.g., after a defined period has elapsed)" 563 This re-key rollover strategy allows the group to drain its in 564 transit datagrams from the network while transitioning to the leading 565 edge SA. Staggering the roles of each respective IPsec SA as 566 described above improves the group's synchronization even when there 567 are high network propagation delays. Note that due to group 568 membership joins and leaves, each Group Speaker time epoch may have a 569 different group membership set. 571 It is a group policy decision whether the re-key event transition 572 between epochs provides forward and backward secrecy. The group's re- 573 key protocol keying material and algorithm (e.g. Logical Key 574 Hierarchy) enforces this policy. Implementations MAY offer a Group 575 Owner management interface option to enable/disable re-key rollover 576 continuity for a particular group. This specification requires that a 577 GKM/IPsec implementation MUST support at least two concurrent IPsec 578 SA per Group Speaker and this re-key rollover continuity algorithm. 580 4.3 Data Origin Authentication 582 As defined in [RFC4301], data origin authentication is a security 583 service that verifies the identity of the claimed source of data. A 584 Message Authentication Code (MAC) is often used to achieve data 585 origin authentication for connections shared between two parties. But 586 MAC authentication methods are not sufficient to provide data origin 587 authentication for groups with more than two parties. With a MAC 588 algorithm, every group member can use the MAC key to create a valid 589 MAC tag, whether or not they are the authentic originator of the 590 group application's data. 592 When the property of data origin authentication is required for an 593 IPsec SA distributed from a GKCS, an authentication transform where 594 the originator keeps a secret should be used. Two possible algorithms 595 are TESLA [RFC4082] or RSA digital signature [RFC4359]. 597 In some cases, (e.g., digital signature authentication transforms) 598 the processing cost of the algorithm is significantly greater than an 599 HMAC authentication method. To protect against denial of service 600 attacks from device that is not authorized to join the group, the 601 IPsec SA using this algorithm may be encapsulated with an IPsec SA 602 using a MAC authentication algorithm. However, doing so requires the 603 packet to be sent across the IPsec boundary for additional inbound 604 processing [RFC4301, Section 5.2]. This use of ESP encapsulated 605 within ESP accommodates the constraint that an ESP trailer defines an 606 Integrity Check Value (ICV) for only a single authenticator 607 transform. Relaxing this constraint on the use of the ICV field is an 608 area for future standardization. 610 4.4 Group SA and Key Management 612 4.4.1 Co-Existence of Multiple Key Management Protocols 614 Often, the GKM subsystem will be introduced to an existent IPsec 615 subsystem as a companion key management protocol to IKEv2 [RFC4306]. 616 A fundamental GKM protocol IP Security subsystem requirement is that 617 both the GKM protocol and IKEv2 can simultaneously share access to a 618 common Group Security Policy Database and Security Association 619 Database. The mechanisms that provide mutually exclusive access to 620 the common GSPD/SAD data structures are a local matter. This includes 621 the GSPD-outbound cache and the GSPD-inbound cache. However, 622 implementers should note that IKEv2 SPI allocation is entirely 623 independent from GKM SPI allocation because group security 624 associations are qualified by a destination multicast IP address and 625 may optionally have a source IP address qualifier. See [RFC4303, 626 Section 2.1] for further explanation. 628 The Peer Authorization Database does require explicit coordination 629 between the GKM protocol and IKEv2. Section 4.1.3 describes these 630 interactions. 632 4.4.2 New Security Association Attributes 634 A number of new security association attributes are defined in this 635 document. Each GKM protocol supporting this architecture MUST support 636 the following list of attributes described elsewhere in this 637 document. 639 - Address Preservation (Section 3.1). This attribute describes 640 whether address preservation is to be applied to the SA on the source 641 address, destination address, or both source and destination 642 addresses. 644 - Direction attribute (Section 4.1.1). This attribute describes 645 whether the GSPD direction is to be symmetric, receiver only, or 646 sender only. 648 - Specification of UDP Encapsulation (Section 6.1.4.2). This 649 attribute declares that the UDP encapsulation of IPsec ESP packets 650 [RFC 3948] will be used as part of an ESP SA. 652 - Any of the cryptographic transform-specific parameters and keys 653 that are sent from the GCKS to the Group Members (e.g. data origin 654 authentication parameters as described in section 4.3). 656 5. IP Traffic Processing 658 Processing of traffic follows [RFC4301, Section 5], with the 659 additions described below when these IP multicast extensions are 660 supported. 662 5.1 Outbound IP Multicast Traffic Processing 664 If an IPsec SA is marked as supporting tunnel mode with address 665 preservation (as described in Section 3.1), either or both of the 666 outer header source or destination addresses is marked as being 667 preserved. If the source address is marked as being preserved, during 668 header construction the "src address" header field MUST be "copied 669 from inner hdr" rather than "constructed" as described in [RFC4301]. 670 Similarly, if the destination address is marked as being preserved, 671 during header construction the "dest address" header field MUST be 672 "copied from inner hdr" rather than "constructed". 674 5.2 Inbound IP Multicast Traffic Processing 676 If an IPsec SA is marked as supporting tunnel mode with address 677 preservation (as described in Section 3.0), the marked address (i.e., 678 source and/or destination address) on the outer IP header MUST be 679 verified to be the same value as the inner IP header. If the 680 addresses are not consistent, the IPsec system MUST treat the error 681 in the same manner as other invalid selectors, as described in 682 [RFC4301, Section 5.2]. In particular the IPsec system MUST discard 683 the packet, as well as treat the inconsistency as an auditable event. 685 6. IP-v4 Network Address Translation 687 With the advent of NAT and mobile Nodes, IPsec multicast applications 688 must overcome several architectural barriers to their successful 689 deployment. This section surveys those problems and identifies the 690 GSPD/SAD state information that the GKM protocol must synchronize 691 across the group membership. 693 6.1 GSPD Losses Synchronization with Internet Layer's State 695 The most prominent problem facing GKM protocols supporting IPsec is 696 that the GKM protocol's group security policy mechanism can 697 inadvertently configure the group's GSPD traffic selectors with 698 unreliable transient IP addresses. The IP addresses are transient 699 because of either Node mobility or Network Address Translation (NAT), 700 both of which can unilaterally change a multicast speaker's source IP 701 address without signaling the GKM protocol. The absence of a GSPD 702 synchronization mechanism can cause the group's data traffic to be 703 discarded rather than processed correctly. 705 6.1.1 Mobile Multicast Care-Of Address Route Optimization 707 Both Mobile IPv4 [RFC3344] and Mobile IPv6 provide transparent 708 unicast communications to a mobile Node. However, comparable support 709 for secure multicast mobility management is not specified by these 710 standards. The goal is the ability to maintain an end-to-end 711 transport mode group SA between a Group Speaker mobile node that has 712 a volatile care-of-address and a Group Receiver membership that also 713 may have mobile endpoints. In particular, there is no secure 714 mechanism for route optimization of the triangular multicast path 715 between the correspondent Group Receiver Nodes, the home agent, and 716 the mobile Node. Any proposed solution must be secure against hostile 717 re-direct and flooding attacks. 719 6.1.2 NAT Translation Mappings Are Not Predictable 721 The following spontaneous NAT behaviors adversely impact source- 722 specific secure multicast groups. When a NAT gateway is on the path 723 between a Group Speaker residing behind a NAT and a public IPv4 724 multicast Group Receiver, the NAT gateway alters the private source 725 address to a public IPv4 address. This translation must be 726 coordinated with every Group Receiver's inbound GSPD multicast 727 entries that depend on that source address as a traffic selector. One 728 might mistakenly assume that the GCKS could set up the Group Members 729 with an GSPD entry that anticipates the value(s) that the NAT 730 translates the packet's source address. However, there are known 731 cases where this address translation can spontaneously change without 732 warning: 734 - NAT gateways may re-boot and lose their address translation state 735 information. 737 - The NAT gateway may de-allocate its address translation state after 738 an inactivity timer expires. The address translation used by the 739 NAT gateway after the resumption of data flow may differ than that 740 known to the GSPD selectors at the group endpoints. 742 - The GCKS may not have global consistent knowledge of a group 743 endpoint's current public and private address mappings due to 744 network errors or race conditions. For example, a Group Member's 745 address may change due to a DHCP assigned address lease expiration. 747 - Alternate paths may exist between a given pair of Group Members. If 748 there are parallel NAT gateways along those paths, then the address 749 translation state information at each NAT gateway may produce 750 different translations on a per packet basis. 752 The consequence of this problem is that the GCKS can not be pre- 753 configured with NAT mappings, as the GSPD at the Group Members will 754 lose synchronization as soon as a NAT mapping changes due to any of 755 the above events. In the worst case, Group Members in different 756 sections of the network will see different NAT mappings, because the 757 multicast packet traversed multiple NAT gateways. 759 6.2 Secondary Problems Created by NAT Traversal 761 6.2.1 SSM Routing Dependency on Source IP Address 763 Source-Specific Multicast (SSM) routing depends on a multicast 764 packet's source IP address and multicast destination IP address to 765 make a correct forwarding decision. However, a NAT gateway alters 766 that packet's source IP address as its passes from a private network 767 into the public network. Mobility changes a Group Member's point of 768 attachment to the Internet, and this will change the packet's source 769 IP address. Regardless of why it happened, this alteration in the 770 source IP address makes it infeasible for transit multicast routers 771 in the public Internet to know which SSM speaker originated the 772 multicast packet, which in turn selects the correct multicast 773 forwarding policy. 775 6.2.2 ESP Cloaks Its Payloads from NAT Gateway 777 When traversing NAT, application layer protocols that contain IPv4 778 addresses in their payload need the intervention of an Application 779 Layer Gateway (ALG) that understands that application layer protocol 780 [RFC3027] [RFC3235]. The ALG massages the payload's private IPv4 781 addresses into equivalent public IPv4 addresses. However, when 782 encrypted by end-to-end ESP, such payloads are opaque to application 783 layer gateways. 785 When multiple Group Speakers reside behind a NAT with a single public 786 IPv4 address, the NAT gateway can not do UDP or TCP protocol port 787 translation (i.e. NAPT) because the ESP encryption conceals the 788 transport layer protocol headers. The use of UDP encapsulated ESP 789 [RFC3948] avoids this problem. However, this capability must be 790 configured at the GCKS as a group policy, and it must be supported in 791 unison by all of the group endpoints within the group, even those 792 that reside in the public Internet. 794 6.2.3 UDP Checksum Dependency on Source IP Address 796 An IPsec subsystem using UDP within an ESP payload will encounter NAT 797 induced problems. The original IPv4 source address is an input 798 parameter into a receiver's UDP pseudo-header checksum verification, 799 yet that value is lost after the IP header's address translation by a 800 transit NAT gateway. The UDP header checksum is opaque within the 801 encrypted ESP payload. Consequently, the checksum can not be 802 manipulated by the transit NAT gateways. UDP checksum verification 803 needs a mechanism that recovers the original source IPv4 address at 804 the Group Receiver endpoints. 806 In a transport mode multicast application GSA, the UDP checksum 807 operation requires the origin endpoint's IP address to complete 808 successfully. In IKEv2, this information is exchanged between the 809 endpoints by a NAT-OA payload (NAT original address). See also 810 reference [RFC3947]. A comparable facility must exist in a GKM 811 protocol payload that defines the multicast application GSA 812 attributes for each Group Speaker. 814 6.2.4 Cannot Use AH with NAT Gateway 816 The presence of a NAT gateway makes it impossible to use an 817 Authentication Header, keyed by a group-wide key, to protect the 818 integrity of the IP header for transmissions between members of the 819 cryptographic group. 821 6.3 Avoidance of NAT Using an IPv6 Over IPv4 Network 823 A straightforward and standards-based architecture that effectively 824 avoids the GKM protocol interaction with NAT gateways is the IPv6 825 over IPv4 transition mechanism [RFC2529]. In IPv6 over IPv4 (a.k.a. 826 "6over4"), the underlying IPv4 network is treated as a virtual 827 multicast-capable Local Area Network. The IPv6 traffic tunnels over 828 that IPv4 virtual link layer. 830 Applying GKM/IPsec in a 6over4 architecture leverages the fact that 831 an administrative domain deploying GKM/IPsec would already be 832 planning to deploy IPv4 multicast router(s). The group's IPv6 833 multicast routing can execute in parallel to IPv4 multicast routing 834 on that same physical router infrastructure. In particular, IPv6 835 multicast routers operating with 6over4 mode enabled on their network 836 interfaces replaces the NAT gateways at administrative domain 837 public/private boundaries. 839 Within the GKM subsystem, all references to IP addresses are IPv6 840 addresses for all security association endpoints and these addresses 841 do not change over the group's lifetime. This yields a substantial 842 reduction in complexity and error cases over the NAT-based 843 approaches. This reduction in complexity can translate into better 844 security. 845 Reliable scalable GKM/IPsec based on 6over4 deployment is far more 846 practical than an IPv4 with NAT deployment. In particular, new 847 GKM/IPsec multicast applications SHOULD prefer IPv6 native mode. 848 However, the GKM/IPsec architecture supports either choice. The 849 following factors may weigh against the decision to deploy GKM/IPsec 850 using 6over4: 852 - A drawback of the GKM/IPsec 6over4 approach is that the application 853 layer protocol itself must embed references to IPv6 addresses 854 rather than IPv4 addresses within its payloads. For new 855 applications, this may not be of consequence; it usually only 856 becomes an issue if the application and its protocol has an 857 embedded base. 859 - An embedded base of GKM/IPsec IPv4 multicast applications that are 860 only available in binary form will not be able to migrate to these 861 transitional IPv6 mechanisms. 863 - The secondary drawbacks of GKM/IPsec using 6over4 are that the IP 864 hosts must be upgraded to dual-stack, the attendant overlay IPv6 865 multicast network operational costs, and the perceived difficulty 866 of deploying commercial wide-area IPv6 multicast services. 868 6.4 GKM/IPsec Multi-Realm IPv4 NAT Architecture 870 In a multi-realm group, GKM/IPsec security association endpoints may 871 straddle any combination of IPv4 public addresses and private 872 addresses [RFC1918]. In such cases, transport layer endpoint 873 identifiers when resolved to their underlying private or public IPv4 874 addresses entangle the GKM protocol with NAT gateway behaviors. The 875 NAT translation of IPv4 header addresses impacts the GKM protocol 876 registration SA, the GKM protocol re-key GSA, and the secure 877 multicast application GSA. 879 This section overviews the GKM/IPsec mechanisms that partially 880 mitigate the inherent complexity spawned by IPv4 NAT and Network 881 Address Protocol Translation (NAPT) traversal. However, the attendant 882 Group Owner configuration procedures are labor-intensive, prone to 883 configuration mismatch errors between the GCKS and NAT gateways, and 884 they do not scale well to large groups. Given the large number of 885 documented NAT problems and its erosion of end-to-end security, new 886 GKM/IPsec applications and deployments SHOULD strongly prefer the use 887 of IPv6. 889 6.4.1 GKM/IPsec IPv4 NAT Architectural Assumptions 891 To make the multi-realm GKM/IPsec IPv4 NAT interaction problem 892 tractable to a solution, this specification profiles the available 893 options with the following simplifying assumptions: 895 - The secure multicast group destination address is a statically 896 allocated public IPv4 multicast address known to all group 897 endpoints. 899 - Wherever they are present in the GKM subsystem, group endpoint 900 addresses are expressed as permanent IP-v6 "6to4" addresses 901 [RFC3056] to assure that the group endpoints that refer to hosts 902 assigned private IPv4 addresses are globally unique. In this 903 context, a "permanent" 6to4 address means that the address is 904 constant for the group's lifetime. 906 - Each private IPv4 address space has one or more NAT gateways 907 directly connected to the IPv4 public Internet, and a packet does 908 not have to traverse multiple private networks to reach the public 909 Internet. This can be thought of as a "spoke and hub" configuration 910 wherein the public Internet is the hub. 912 - A GCKS may reside within one of the private networks, but it also 913 MUST have a permanent public IPv4 address on at least one of its 914 network interfaces. 916 - Since the one or more GCKS are constrained to straddle a 917 public/private network boundary, GKM/IPsec group security 918 associations effectively terminate the GSA at a combined 919 NAT/security gateway [RFC2709]. 921 - The GCKS domain name RR record should point to that public IPv4 922 address, and it is recommended that it be protected by DNS-SEC. 924 - The inbound NAT gateway will forward a Group Speaker's multicast 925 traffic from the public Internet to the private network so long as 926 at least one Group Receiver within the private network has joined 927 the Group Speaker's multicast group. The Group Receiver(s) use 928 IGMP-v3 to signal their interest in a group's traffic to the 929 administrative domain's multicast routers, at least one of which is 930 an ingress NAT gateway. Alternatively, in simple private networks 931 without multicast routers, the Group Receivers send their IGMP-v3 932 packets directly to the NAT gateway [BEHAVE] acting in the role of 933 an IGMP-v3 proxy. The NAT gateway redirects the IGMP-v3 packets to 934 a multicast router in the public Internet. 936 - Group Members also use IGMP-v3 to join the GKM protocol's re-key SA 937 multicast group if that group has been assigned a different 938 destination multicast IP address than the multicast application 939 group. 941 - In the outbound direction, NAT gateways generally translate the 942 Group Speaker packet's private source IP address into a dynamically 943 selected public IP address. Exceptions to this policy for source 944 specific multicast are noted in subsequent sections. 946 - Within each administrative domain, a multicast routing protocol 947 domain routes packets based on the group's destination multicast 948 public IPv4 address. The multicast routers will distribute the 949 group's packets to all of the group's Group Receiver endpoints 950 residing in that administrative domain. 952 - The border routers of each of the administrative domains spanned by 953 the group do cross-realm multicast routing and distribution on 954 behalf of the group. The IP-v4 multicast routers that exchange 955 reachability information regarding the group across trust 956 boundaries authenticate that information. 958 6.4.2 Multicast Application GSA NAT Traversal 960 Unlike the GKM protocol rekey message multicast to the Re-Key GSA, a 961 multicast application message sent to the group may originate from a 962 Group Speaker endpoint located behind a NAT gateway. Since the 963 application's message is encrypted within an ESP payload, the 964 transport layer protocol header port fields are concealed from NAT 965 gateways and they cannot participate in NAPT. The multicast 966 application GSA must be handled differently depending on whether the 967 application requires source-specific multicast. 969 If the application requires source-specific multicast routing, then 970 there must be a separate public IP-v4 address statically reserved at 971 the NAT gateway for each Group Speaker endpoint private/public 972 address mapping. This constraint allows the GCKS to specify at every 973 Group Member the inbound GSPD traffic selector with a pre-determined 974 public source address for each Group Speaker endpoint in the group. 975 The traffic selector's public source address in combination with the 976 group's destination multicast address and SPI selects the inbound SA. 977 Keeping the NAT gateway's source address mapping static rather than 978 dynamic also allows the multicast routers along the packet's path to 979 apply source-specific routing policies. Note that the use of a static 980 source address mapping NAT avoids the need for the group's policy 981 token to specify UDP encapsulated ESP. The drawback of this approach 982 is that the GCKS GSPD/SAD configuration database must be kept 983 synchronized with the group's NAT gateway address mapping 984 configurations. These operational procedures can be labor-intensive 985 and error-prone, making large-scale group deployments difficult. A 986 more sophisticated GKM subsystem may sidestep this problem by 987 dynamically setting the Group Receiver endpoint's GSPD/SAD entry 988 traffic selector rather than relying on static GCKS configuration. 990 If the application requires the any-source multicast service model, 991 then the NAT gateway's source address translation can use dynamically 992 allocated public IPv4 addresses rather than statically allocated IPv4 993 addresses. However, unless the group uses UDP encapsulated ESP, then 994 the NAT gateway must have a pool of public IPv4 addresses reserved 995 that is at least as large as the number of Group Speaker endpoints 996 within its private network. The public IP address pool allows the NAT 997 gateway to do a one-to-one mapping from every Group Speaker 998 endpoint's private source address to a dynamically allocated public 999 source address. In this case, the use of NAPT rather than NAT is not 1000 an option, since the transport layer protocol is within an opaque ESP 1001 payload. The GCKS specifies the SPD/SAD traffic selector as the 1002 combination of the group's destination multicast address and the SPI. 1004 In some deployments, the number of public IPv4 addresses assigned to 1005 a NAT gateway is very limited (e.g. only one public IPv4 address). 1006 Also, it may be difficult to predict how many Group Speaker endpoints 1007 will reside within the private network before the group begins its 1008 operation. For these cases, the group MAY use UDP encapsulated ESP. 1009 The NAT gateway applies NAPT to the UDP header's source port field, 1010 sidestepping the constraint of its limited public IPv4 address pool. 1011 The Group Owner modifies the group policy to specify that the 1012 outbound GSPD processing must pre-append a UDP header in front of the 1013 ESP header. When a Group Speaker endpoint originates a multicast 1014 application packet, it inserts a UDP header in front of the ESP 1015 header, as per reference [RFC3948]. 1017 6.5 ESP Encapsulated by UDP in a Multicast Group 1019 To be supplied. 1021 7. Security Considerations 1023 This document describes architecture for securing group network 1024 traffic using IPsec. As such, security considerations are found 1025 throughout this document. 1027 [BEW: Need to expand.] 1029 8. IANA Considerations 1031 This document has no actions for IANA. 1033 9. Acknowledgements 1035 [TBD] 1037 10. References 1039 10.1 Normative References 1041 [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1042 1112, August 1989. 1044 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1045 Requirement Level", BCP 14, RFC 2119, March 1997. 1047 [RFC3552] Rescorla, E., et. al., "Guidelines for Writing RFC Text on 1048 Security Considerations", RFC 3552, July 2003. 1050 [RFC3948] Huttenen, A., et. al., "UDP Encapsulation of IPsec ESP 1051 Packets", RFC 3948, January 2005. 1053 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1054 Internet Protocol", RFC 4301, December 2005. 1056 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 1057 2005. 1059 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1060 4303, December 2004. 1062 10.2 Informative References 1064 [COREPT] Colegrove, A., and H. Harney, "Group Security Policy Token 1065 v1", (work in progress), draft-ietf-msec-policy-token-sec-06.txt 1066 (work in progress), January 2006. 1068 [GSAKMP] H. Harney, Colegrove A. , U. Meth, and G. Gross.; "Group 1069 Secure Association Key Management Protocol (GSAKMP)", (work in 1070 progress), draft-ietf-msec-gsakmp-sec-10.txt, January 2006. 1072 [RFC3306] B. Haberman, D. Thaler, " Unicast-Prefix-based IPv6 1073 Multicast Addresses", RFC3306, August 2002. 1075 [RFC3307] B. Haberman, " Allocation Guidelines for IPv6 Multicast 1076 Addresses", RFC3307, August 2002. 1078 [RFC4046] M. Bauger, L. Dondeti, R. Canetti, F. Lindholm, " Multicast 1079 Security (MSEC) Group Key Management Architecture", RFC4046, April 1080 2005. 1082 [RFC4291] S. Deering, R. Hinden, " IP Version 6 Addressing 1083 Architecture", RFC4291, February 2006. 1085 [RFC2362] Estrin, D., et. al., "Protocol Independent Multicast-Sparse 1086 Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. 1087 [RFC2526] Johnson, D., and S. Deering., "Reserved IPv6 Subnet Anycast 1088 Addresses", RFC 2526, March 1999. 1090 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1091 Domains without Explicit Tunnels", RFC 2529, March 1999. 1093 [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1094 1999. 1096 [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for 1097 NAT Domains", RFC 2709, October 1999. 1099 [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, 1100 September 2000. 1102 [RFC3027] Holdrege, M., and P. Srisuresh, "Protocol Complications 1103 with the IP Network Address Translator", RFC 3027, January 2001. 1105 [RFC3171] Albanni, Z., et. al., "IANA Guideli nes for IPv4 1106 Multicast Ad dress Assign ments", RFC 3171, August 2001. 1108 [RFC3235]Senie, D., "Network Address Translator (NAT)-Friendly 1109 Application Design Guidelines", RFC 3235, January 2002. 1111 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1112 August 2002. 1114 [RFC3376] Cain, B., et. al., "Internet Group Management Protocol, 1115 Version 3", RFC 3376, October 2002. 1117 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 1118 Group Domain of Interpretation", RFC 3547, December 2002. 1120 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1121 Multicast (SSM)", RFC 3569, July 2003. 1123 [RFC3940] Adamson, B., et. al., "Negative-acknowledgment (NACK)- 1124 Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November 1125 2004. 1127 [RFC3947] Kivinen, T., et. al., "Negotiation of NAT-Traversal in the 1128 IKE", RFC 3947, January 2005. 1130 [RFC3948] Huttunen, A., et. al., "UDP Encapsulation of IPsec ESP 1131 Packets", RFC 3948, January 2005. 1133 [RFC4082] Perrig, A., et. al., "Timed Efficient Stream Loss-Tolerant 1134 Authentication (TESLA): Multicast Source Authentication Transform 1135 Introduction", RFC 4082, June 2005. 1137 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 1138 4306, December 2005. 1140 [RFC4359] Weis., B., "The Use of RSA/SHA-1 Signatures within 1141 Encapsulating Security Payload (ESP) and Authentication Header (AH)", 1142 RFC 4359, January 2006. 1144 [ZLLY03] Zhang, X., et. al., "Protocol Design for Scalable and 1145 Reliable Group Rekeying", IEEE/ACM Transactions on Networking (TON), 1146 Volume 11, Issue 6, December 2003. See 1147 http://www.cs.utexas.edu/users/lam/Vita/Cpapers/ZLLY01.pdf. 1149 Appendix A _ Multicast Application Service Models 1151 The vast majority of secure multicast applications can be catalogued 1152 by their service model and accompanying intra-group communication 1153 patterns. Both the Group Key Management (GKM) Subsystem and the 1154 IPsec subsystem MUST be able to configure the GSPD/SAD security 1155 policies to match these dominant usage scenarios. The GSPD/SAD 1156 policies MUST include the ability to configure both Any-Source- 1157 Multicast groups and Source-Specific-Multicast groups for each of 1158 these service models. The GKM Subsystem management interface MAY 1159 include mechanisms to configure the security policies for service 1160 models not identified by this standard. 1162 A.1 Unidirectional Multicast Applications 1164 Multi-media content delivery multicast applications that do not have 1165 congestion notification or retransmission error recovery mechanisms 1166 are inherently unidirectional. RFC 4301 only defines bi-directional 1167 unicast security associations (as per sections 4.4.1 and 5.1 with 1168 respect to security association directionality). The GKM Subsystem 1169 requires that the IPsec subsystem MUST support unidirectional Group 1170 Security Associations (GSA). Multicast applications that have only 1171 one group member authorized to transmit can use this type of group 1172 security association to enforce that group policy. In the inverse 1173 direction, the GSA does not have a SAD entry, and the GSPD 1174 configuration is optionally setup to discard unauthorized attempts to 1175 transmit unicast or multicast packets to the group. 1177 The GKM Subsystem's management interface MUST have the ability to 1178 setup a GKM Subsystem group having a unidirectional GSA security 1179 policy. 1181 A.2 Bi-directional Reliable Multicast Applications 1183 Some secure multicast applications are characterized as one group 1184 speaker to many receivers, but with inverse data flows required by a 1185 reliable multicast transport protocol (e.g. NORM). In such 1186 applications, the data flow from the speaker is multicast, and the 1187 inverse flow from the group's receivers is unicast to the speaker. 1188 Typically, the inverse data flows carry error repair requests and 1189 congestion control status. 1191 For such applications, the GSA SHOULD use IPsec anti-replay 1192 protection service for the speaker's multicast data flow to the 1193 group's receivers. Because of the scalability problem described in 1194 the next section, it is not practical to use the IPsec anti-replay 1195 service for the unicast inverse flows. Consequently, in the inverse 1196 direction the IPsec anti-replay protection MUST be disabled. However, 1197 the unicast inverse flows can use the group's IPsec group 1198 authentication mechanism. The group receiver's GSPD entry for this 1199 GSA SHOULD be configured to only allow a unicast transmission to the 1200 speaker Node rather than a multicast transmission to the whole group. 1202 If an ESP digital signature authentication is available (E.g., RFC 1203 4359), source authentication MAY be used to authenticate a receiver 1204 Node's transmission to the speaker. The GKM protocol MUST define a 1205 key management mechanism for the group speaker to validate the 1206 asserted signature public key of any receiver Node without requiring 1207 that the speaker maintain state about every group receiver. 1209 This multicast application service model is RECOMMENDED because it 1210 includes congestion control feedback capabilities. Refer to [RFC2914] 1211 for additional background information. 1213 The GKM Subsystem's Group Owner management interface MUST have the 1214 ability to setup a GKM Subsystem GSA having a bi-directional GSA 1215 security policy and one group speaker. The management interface 1216 SHOULD be able to configure a group to have at least 16 concurrent 1217 authorized speakers, each with their own GSA anti-replay state. 1219 A.3 Any-To-Any Multicast Applications 1221 Another family of secure multicast applications exhibits a "any to 1222 many" communications pattern. A representative example of such an 1223 application is a videoconference combined with an electronic 1224 whiteboard. 1226 For such applications, all (or a large subset) of the Group Members 1227 are authorized multicast speakers. In such service models, creating a 1228 distinct IPsec SA with anti-replay state for every potential speaker 1229 does not scale to large groups. The group SHOULD share one IPsec SA 1230 for all of its speakers. The IPsec SA SHOULD NOT use the IPsec anti- 1231 replay protection service for the speaker's multicast data flow to 1232 the Group Receivers. 1234 The GKM Subsystem's management interface MUST have the ability to 1235 setup a group having an Any-To-Many Multicast GSA security policy. 1237 Author's Address 1239 Brian Weis 1240 Cisco Systems 1241 170 W. Tasman Drive, 1242 San Jose, CA 95134-170 1243 USA 1245 Phone: +1-408-526-4796 1246 Email: bew@cisco.com 1248 George Gross 1249 IdentAware Security 1250 82 Old Mountain Road 1251 Lebanon, NJ 08833 1252 USA 1254 Phone: +1-908-268-1629 1255 Email: gmgross@identaware.com 1257 Dragan Ignjatic 1258 Polycom 1259 1000 W. 14th Street 1260 North Vancouver, BC V7P 3P3 1261 Canada 1263 Phone: +1-604-982-3424 1264 Email: dignjatic@polycom.com 1266 Intellectual Property Statement 1268 The IETF takes no position regarding the validity or scope of any 1269 Intellectual Property Rights or other rights that might be claimed 1270 to pertain to the implementation or use of the technology 1271 described in this document or the extent to which any license 1272 under such rights might or might not be available; nor does it 1273 represent that it has made any independent effort to identify any 1274 such rights. Information on the procedures with respect to rights 1275 in RFC documents can be found in BCP 78 and BCP 79. 1277 Copies of IPR disclosures made to the IETF Secretariat and any 1278 assurances of licenses to be made available, or the result of an 1279 attempt made to obtain a general license or permission for the use 1280 of such proprietary rights by implementers or users of this 1281 specification can be obtained from the IETF on-line IPR repository 1282 at http://www.ietf.org/ipr. 1284 The IETF invites any interested party to bring to its attention 1285 any copyrights, patents or patent applications, or other 1286 proprietary rights that may cover technology that may be required 1287 to implement this standard. Please address the information to the 1288 IETF at ietf-ipr@ietf.org. 1290 Disclaimer of Validity 1292 This document and the information contained herein are provided on an 1293 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1294 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1295 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1296 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1297 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1298 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1300 Copyright Statement 1302 Copyright (C) The Internet Society (2006). This document is subject 1303 to the rights, licenses and restrictions contained in BCP 78, and 1304 except as set forth therein, the authors retain all their rights. 1306 Acknowledgement 1308 Funding for the RFC Editor function is currently provided by the 1309 Internet Society.