idnits 2.17.00 (12 Aug 2021) /tmp/idnits19919/draft-ietf-msec-ipsec-multicast-issues-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([ESPbis,AHbis], [RFC2401], [RFC2402,RFC2406], [RFC3376,SSM-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) == Unused Reference: 'RFC2402' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'RFC3376' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'SSM-ARCH' is defined on line 490, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Duplicate reference: RFC2402, mentioned in 'AHbis', was also mentioned in 'RFC2402'. -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'AHbis') (Obsoleted by RFC 4302, RFC 4305) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Mark Baugher(Cisco) 3 INTERNET-DRAFT Ran Canetti (IBM) 4 draft-ietf-msec-ipsec-multicast-issues-01.txt Thomas Hardjono (Verisign) 5 Expires: June, 2003 Brian Weis (Cisco) 6 December, 2002 8 IP Multicast issues with IPsec 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working groups. 17 Note that other groups may also distribute working documents as 18 Internet Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The IPsec Architecture [RFC2401] and IPsec transform RFCs [RFC2402, 34 RFC2406] define certain mechanisms for IP multicast traffic. The 35 recent revisions to each of the protocol documents [ESPbis, AHbis] 36 propose changes to those semantics. However, neither the existing 37 nor proposed semantics are sufficiently general such that IPsec can 38 be used to protect the wide variety of IPv4 and IPv6 multicast 39 applications that are expected by the IP multicast community. In 40 particular, they are not compatible with the needs of the protocols 41 developed in the MSEC WG and for Source Specific Multicast [RFC3376, 42 SSM-ARCH]. This document reviews these semantics and proposes some 43 minor changes, which would enable IPsec to be suitable for these 44 uses. 46 IP Multicast issues with IPsec December, 2002 48 Table of Contents 50 1.0 Introduction......................................................2 51 1.1 Addressing Scope................................................3 52 1.2 Key Words.......................................................3 53 2.0 General Issues....................................................3 54 2.1 SPI allocation and SA lookup....................................4 55 2.2 Multiple sender SAs and replay protection.......................5 56 2.3 Integrity vs. Authentication....................................5 57 3.0 Proposed Changes to ESPbis........................................5 58 3.1 SPI allocation and SA lookup....................................5 59 3.2 Multiple sender SAs and replay protection.......................6 60 3.3 Integrity vs. Authentication....................................7 61 4.0 Proposed Changes to AHbis.........................................8 62 4.1 SPI allocation and SA lookup....................................8 63 4.2 Multiple sender SAs and replay protection.......................8 64 4.3 Integrity vs. Authentication....................................9 65 5.0 Conclusion........................................................9 66 6.0 Security Considerations...........................................9 67 7.0 References........................................................9 68 7.1 Normative References............................................9 69 7.2 Informative References..........................................9 70 Authors Addresses....................................................10 72 1.0 Introduction 74 At the time RFCs 2401/2402/2406 were written, use of IPsec for 75 multicast was for the most part not deployed. However the authors of 76 those RFCs and the IPsec Working Group had the vision that IPsec 77 would someday be just as useful for IP multicast as IP unicast. At 78 that time there were a number of unsolved problems, and those are 79 candidly listed in RFC 2401. 81 However, because so little attention had been focused on using IPsec 82 to protect multicast traffic, and because new methods of IP 83 multicast have been invented since that time, it is only natural 84 that what is currently documented in those RFCs do not handle all of 85 the current IP multicast needs. We are thus faced with a situation 86 where the current specification of IPSec is inconsistent with the 87 secure multicast standard that is being developed in the MSEC WG. 89 Consequently, the IPSEC and MSEC working groups now have to make a 90 decision to take one of the following to standardization paths: 92 A. Decide that ESP/AH should not be modified for the purpose of 93 accommodating the needs of MSEC. In this case, MSEC will define 94 its own version of ESP [MESP]. MESP will be similar to ESP, but 95 will be incompatible with ESP in several ways. In particular, 96 MESP will use a different protocol number than that of ESP. 98 IP Multicast issues with IPsec December, 2002 100 B. Decide that ESP/AH should be modified to accommodate the needs of 101 MSEC. In this case, both MSEC and IPSec will use the same 102 definition of ESP, with the same protocol number. (MESP will 103 define additional authentication protocols for ESP, to obtain 104 source authentication.) 106 The main advantage of option A is that there is no need to 107 coordinate between the two working groups, and each WG is free to 108 define (and subsequently modify) its own protocols. The main 109 disadvantage of option A is the extra complexity involved in 110 defining, implementing, and maintaining a separate "multicast ESP" 111 protocol. Thus, the decision between options A and B has to weigh 112 the complexity of modifying ESP to accommodate MSEC, against the 113 complexity of having a different "multicast ESP" protocol. 115 The purpose of this draft is to explain and clarify the changes 116 needed to ESP/AH in order to make it compatible with MSEC, and thus 117 start a discussion on the MSEC and IPSEC working groups. In a 118 nutshell, three modifications to the IPSec protocol suite are 119 necessary: 121 1. Allow parties to further refine the SA lookup. (That is, allow a 122 party to have two different SA's, with the same destination 123 address, same IPSEC protocol, and same SPI, but with different 124 source addresses. 126 2. Allow parties a wider range of replay protection possibilities 127 for ESP/AH. 129 3. Better describe that a variety of authentication methods can be 130 used within the IPsec protocols. 132 It is our impression that the changes required of ESP/AH to 133 accommodate the needs of MSEC are minor, and in no case will 134 existing IPsec implementations be affected. Thus, option B is the 135 better one. We solicit discussion of this question on the IPSEC and 136 MSEC WGs. 138 1.1 Addressing Scope 140 Although this document is primarily concerned with IP multicast, the 141 issues raised are not restricted to multicast; IPv4 or IPv6 142 broadcast and anycast groups are similarly affected. 144 1.2 Key Words 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 147 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 148 this document are to be interpreted as described in [RFC2119]. 150 2.0 General Issues 152 There are two distinct unrelated problems which have been 153 discovered, first by the SMuG IRTF WG and then by the IETF MSEC WG 154 IP Multicast issues with IPsec December, 2002 156 which was formed to focus on the security of IP multicast groups. 157 One other issue has arisen specifically with new wording in the 158 [ESPbis] and [AHbis] drafts. 160 2.1 SPI allocation and SA lookup 162 RFC 2401 states an SA will use the 3-tuple (destination address, 163 IPsec protocol, and SPI) to look up the SA in the SAD. That is 164 sufficient and satisfactory in many IP multicast cases. It can be 165 accomplished in those cases by using a multicast key management 166 scheme which is built around a centralized group controller. As long 167 as a single group controller synchronizes SPI values, this 3-tuple 168 is sufficient -- even as the authors of RFC 2401 predicted in 169 Section 4.7 of RFC 2401: 171 So some system or person will need to coordinate among all 172 multicast groups to select an SPI or SPIs on behalf of each 173 multicast group and then communicate the group's IPsec 174 information to all of the legitimate members of that multicast 175 group via mechanisms not defined here. 177 The text quoted above from RFC 2401 does not say that there MUST be 178 a single controller, but appears to be giving clarifying text based 179 on the expectations of the time. 181 Since the time RFC 2401 was written, Source-Specific Multicast (SSM) 182 has been specified. SSM allows for sender-specific SAs. An SSM 183 "group" is composed of a particular sender and its receivers. 184 Multiple SSM groups may use that same multicast address, but no 185 coordination between senders is assumed. Similarly, IGMP version 3 186 also operates on the basis of (Source, Group) pairs. Therefore, when 187 we wish to protect this traffic with IPsec we cannot assume any 188 security coordination between the senders. A 3-tuple is no longer 189 sufficient. 191 Section 4.7 of RFC 2401 also says 193 Specifications for other, more general multicast cases are 194 deferred to later IPsec documents. 196 Given the above two quotes it would seem that we should be able to 197 accommodate multiple multicast group controllers within the existing 198 architecture. 200 RFC 2402 and RFC 2406 did not further restrict the SA lookup as 201 described in RFC 2401. They also describe the 3-tuple to be used in 202 all cases (unicast and multicast). 204 The proposed new ESP [ESPbis] and AH [AHbis] do change the semantics 205 of SA lookup. It makes them less specific in both the unicast and 206 multicast cases. For the IP multicast case, the lookup has been 207 changed to a SPI lookup (and optionally the protocol ID) in 208 combination with the destination address. This is fine except in the 209 IP Multicast issues with IPsec December, 2002 211 case when multiple multicast group controllers are used for the 212 group. 214 In order to effectively differentiate between SAs administered by 215 different group controllers, we need a MORE specific SA lookup than 216 RFC 2406 rather than the less specific lookup as proposed in 217 [ESPbis]. 219 2.2 Multiple sender SAs and replay protection 221 RFC 2401 points out that having senders share a single SA is useful 222 under some circumstances (see Section 4.7 of [RFC2401). It 223 acknowledges that the anti-replay service provided by a sequence 224 number in the AH or ESP packet is not possible with present 225 semantics. 227 RFC 2406 agrees with this, and further states that anti-replay 228 SHOULD NOT be used with a multi-sender SA in Section 3.4.3: 230 (Note that there are no provisions for managing transmitted 231 Sequence Number values among multiple senders directing traffic 232 to a single SA (irrespective of whether the destination address 233 is unicast, broadcast, or multicast). Thus the anti-replay 234 service SHOULD NOT be used in a multi-sender environment that 235 employs a single SA.) [RFC2406]. 237 The new ESP [ESPbis] goes even further to deprecate multiple sender 238 SAs in Section 2.2. However, there are multicast applications with 239 very large numbers of senders to the same IP multicast group, where 240 the receivers are low end devices which cannot store a single SA per 241 sender. 243 2.3 Integrity vs. Authentication 245 RFC 2402 and RFC 2406 described an "Authentication Data" section as 246 providing connectionless integrity and data origin authentication. 247 However [ESPbis] and [AHbis] replaced the name of that field with 248 "Integrity Check Value" which doesn't really accurately describe the 249 field when group data origin authentication algorithms are used. 250 This is described more fully in following sections. 252 3.0 Proposed Changes to ESPbis 254 The following sections propose changes to [ESPbis] to address the 255 above general issues. 257 3.1 SPI allocation and SA lookup 259 Section 2.1 (Security Parameters Index) specifies exactly how the 260 SPI should be dealt with: 262 For multicast SAs, the SPI (and optionally the protocol ID) in 263 combination with the destination address is used to select an SA. 264 This is because multicast SAs are defined by a multicast 265 IP Multicast issues with IPsec December, 2002 267 controller, not by each IPsec receiver. (See the Security 268 Architecture document for more details) [ESPbis]. 270 As noted above, this is not sufficient for IP multicastin the case 271 of multiple multicast group controllers. We propose this section to 272 be replaced with the following wording: 274 For broadcast, multicast, and anycast SAs, the SPI and protocol 275 ID (ESP) in combination with the destination address is used to 276 select an SA. In some cases, other parameters (such as a source 277 address) MAY be used by a receiver to further identify the 278 correct SA. This is because multicast SAs may be defined by more 279 than one multicast group controller. 281 Section 3.4.2 (Security Association Lookup) of [ESPbis] would also 282 need to discuss these semantics. It currently states: 284 Upon receipt of a packet containing an ESP Header, the receiver 285 determines the appropriate (unidirectional) SA, based on the SPI 286 alone (unicast) or SPI combined with destination IP address 287 (multicast). (This process is described in more detail in the 288 Security Architecture document) [ESPbis]. 290 We propose this text be replaced as follows. 292 Upon receipt of a unicast packet containing an ESP Header, the 293 receiver determines the appropriate (unidirectional) SA, based on 294 the SPI alone. (This process is described in more detail in the 295 Security Architecture document.) 297 If the packet is a broadcast, multicast, or anycast packet, there 298 may be more than one SA pointed to by the combination of SPI, 299 security protocol and destination address. This can happen if 300 multiple non-cooperating multicast controllers are present in the 301 network. In this case the receiver MAY use other parameters (such 302 as a source address) to identify the correct SA. Key management 303 MAY indicate (e.g., with an SA attribute) that such processing is 304 necessary in order for a receiver to properly process the ESP 305 packets for a group if that is known a priori. 307 3.2 Multiple sender SAs and replay protection 309 Section 2.2 (Sequence Number) states: 311 Sharing an SA among multiple senders is deprecated, since there 312 is no general means of synchronizing packet counters among the 313 senders or meaningfully managing a receiver packet counter and 314 window in the context of multiple senders [ESPbis]. 316 It is true that with the current semantics that synchronizing packet 317 counters across multiple senders is not possible. However, there is 318 a need to provide anti-replay in this situation and there is ongoing 319 research into methods which allow anti-replay in this situation. 321 IP Multicast issues with IPsec December, 2002 323 Therefore, rather than forbid the use of multiple-sender SAs we 324 propose relaxing the multiple-sender SA restriction found in RFC 325 2406 to accommodate new methods of replay detection as they become 326 available. We propose the following replacement for the above text 327 in [ESPbis]. 329 For a multi-sender multicast SA, the anti-replay service MUST NOT 330 be used unless key management signals its use. If the anti-replay 331 service is used in this case, each receiver must keep a replay 332 window per sender. 334 This text intentionally restricts any new anti-replay functionality 335 being used unless it has been negotiated in or downloaded from key 336 management. In this way, older IPsec and hardware implementations of 337 IPsec will be shielded from having to implement or understand the 338 new semantics. 340 3.3 Integrity vs. Authentication 342 The name associated with the authentication portion of ESP is 343 "Authentication Data". However, [ESPbis] changed the name to 344 "Integrity Check Value". The rationale for this change is described 345 in Section 1: 347 Data origin authentication and connectionless integrity are joint 348 services, hereafter referred to jointly as "integrity." (This 349 term is employed because, on a per-packet basis, the computation 350 being performed provides connectionless integrity directly; data 351 origin authentication is provided indirectly as a result of 352 binding the key used to verify the integrity to the identity of 353 the IPsec peer [ESPbis]. 355 This is certainly true for a pairwise unicast connection. However 356 when ESP is used with multicast, data origin authentication can be 357 an authentication feature distinct from identity checks. At least 358 two forms of data origin authentication have been proposed: digital 359 signatures and TESLA. 361 Since this field can provide more than just integrity it is more 362 accurately named as "Authentication Data". We propose the following 363 wording changes to [ESPbis]. 365 1. The text quoted above from Section 1 should be replaced with: 367 Data origin authentication and connectionless integrity are joint 368 services, hereafter referred to jointly as "authentication." 370 2. All occurrences of "Integrity-only ESP" should be "Authentication- 371 only ESP". 373 3. The "Integrity Check Value" field in AH should be named 374 "Authentication Data", and all references to that section should 375 be updated. 377 IP Multicast issues with IPsec December, 2002 379 4.0 Proposed Changes to AHbis 381 The following sections propose changes to [AHbis] to address the 382 above general issues. 384 4.1 SPI allocation and SA lookup 386 Section 2.4 (Security Parameters Index) specifies exactly how the 387 SPI should be dealt with. It is identical to [ESPbis] wording. 389 For multicast SAs, the SPI (and optionally the protocol ID) in 390 combination with the destination address is used to select an SA. 391 This is because multicast SAs are defined by a multicast 392 controller, not by each IPsec receiver. (See the Security 393 Architecture document for more details) [AHbis]. 395 As in the case with [ESPbis], we propose this section to be replaced 396 with the following wording: 398 For broadcast, multicast, and anycast SAs, the SPI and protocol 399 ID (AH) in combination with the destination address is used to 400 select an SA. In some cases other parameters (such as a source 401 address) MAY be used by a receiver to further identify the 402 correct SA. This is because multicast SAs may be defined by more 403 than one multicast group controller. 405 Section 3.4.2 (Security Association Lookup) of [AHbis] also needs to 406 be modified to reflect these semantics. It currently states: 408 Upon receipt of a packet containing an IP Authentication Header, 409 the receiver determines the appropriate (unidirectional) SA, 410 based on the destination IP address, security protocol (AH), and 411 the SPI [AHbis]. 413 No change to this text is necessary. We propose that the following 414 text be appended to it. 416 If the packet is a broadcast, multicast, or anycast packet, there 417 may be more than one SA pointed to by the combination of SPI, 418 security protocol and destination address. This can happen if 419 multiple non-cooperating multicast controllers are present in the 420 network. In this case the receiver MAY use other parameters (such 421 as a source address) to identify the correct SA. Key management 422 MAY indicate (e.g., with an SA attribute) that such processing is 423 necessary in order for a receiver to properly process the AH 424 packets for a group if that is known a priori. 426 4.2 Multiple sender SAs and replay protection 428 Section 2.5 (Sequence Number) states the same text as [ESPbis] 429 Section 2.2. We propose the same text here as is proposed in Section 430 3.2. 432 IP Multicast issues with IPsec December, 2002 434 4.3 Integrity vs. Authentication 436 AH has the same issue as ESP regarding the use of the term 437 "Integrity" over "Authentication". We propose the "Integrity Check 438 Value" field in AHbis be named "Authentication Data", and all 439 references to that section should be updated. 441 5.0 Conclusion 443 The IPsec architecture is capable of accommodating multicast 444 applications, including source specific multicast applications, with 445 minor revisions in SA lookup and replay protection, which are 446 described in this memo. These minor changes will enable new 447 transforms for source authentication of multicast messages as well 448 as group authentication of multicast messages. 450 6.0 Security Considerations 452 This entire document discusses how multicast data packets can be 453 effectively protected within the IPsec architecture. 455 7.0 References 457 7.1 Normative References 459 [RFC2401] Kent, S., R. Atkinson, "Security Architecture for the 460 Internet Protocol", November 1998 462 [RFC2402] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 463 2402, November 1998. 465 [RFC2406] Kent, S., and R. Atkinson, "IP Encapsulating Security 466 Payload", RFC 2406, November 1998. 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Level", BCP 14, RFC 2119, March 1997. 471 [RFC3376] Cain, B., et. al., ?Internet Group Management Protocol, 472 Version 3?, RFC 3376, October 2002. 474 7.2 Informative References 476 [ESPbis] Kent, S., "IP Encapsulating Security Payload (ESP)", 477 http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt, 478 Work in progress 2002. 480 [AHbis] Kent, S., ?IP Authentication Header?, 481 http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis- 482 01.txt, Work in progress 2002. 484 [MESP] Baugher, M., et. al., ?MESP: Multicast Encapsulating Security 485 Payload?, http://www.ietf.org/internet-drafts/draft-ietf-msec-mesp- 486 00.txt, Work in progress 2002. 488 IP Multicast issues with IPsec December, 2002 490 [SSM-ARCH] Holbrook, H., Cain, B., ?Source-Specific Multicast for 491 IP?, http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-01.txt, 492 Work in progress 2002. 494 Authors Addresses 496 Mark Baugher 497 Cisco Systems 498 5510 SW Orchid Street 499 Portland, OR 97219, USA 500 (503) 245-4543 501 mbaugher@cisco.com 503 Ran Canetti 504 IBM T.J. Watson Research Center 505 30 Saw Mill River Road 506 Hawthorne, NY 10598, USA 507 canetti@watson.ibm.com 508 Tel: +1-914-784-6692 510 Thomas Hardjono 511 VeriSign 512 401 Edgewater Place, Suite 280 513 Wakefield, MA 01880 514 Tel: 781-245-6996 515 thardjono@verisign.com 517 Brian Weis 518 Cisco Systems 519 170 W. Tasman Drive, 520 San Jose, CA 95134-1706, USA 521 (408) 526-4796 522 bew@cisco.com