idnits 2.17.1 draft-atwood-pim-sigmp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 date (July 4, 2014) is 3578 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-atwood-mboned-mrac-arch-00 == Outdated reference: A later version (-01) exists of draft-atwood-mboned-mrac-req-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM W. Atwood 3 Internet-Draft B. Li 4 Intended status: Standards Track Concordia University/CSE 5 Expires: January 5, 2015 July 4, 2014 7 Secure Internet Group Management Protocol 8 draft-atwood-pim-sigmp-01 10 Abstract 12 This document specifies a Secure Internet Group Management Protocol 13 (SIGMP), which is an extension to IGMP to enforce receiver access 14 control for secured multicast groups. In SIGMP, only the hosts 15 operated by authorized end users are permitted to report their 16 interest in secured groups. IPsec is used to filter the messages 17 that report or query the interest in secured groups. SIGMP provides 18 two working modes that are fully compatible with IGMP v2 and IGMP v3 19 respectively. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 5, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Overview of SIGMP . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Router Operations . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Router Operations Compatible with IGMP v2 . . . . . . . . 5 62 4.1.1. Router Operations for a Received Report . . . . . . . 5 63 4.2. Router Operations Compatible with IGMP v3 . . . . . . . . 7 64 4.2.1. Router Operations on a Received Report . . . . . . . 7 65 5. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. Host Operations Compatible with IGMP v2 . . . . . . . . . 8 67 5.1.1. Conditions for Unsolicited Report . . . . . . . . . . 8 68 5.1.2. Host Operations for a Received Query . . . . . . . . 8 69 5.2. Host Operations Compatible with IGMP v3 . . . . . . . . . 9 70 5.2.1. Host Operations for a Received General Query . . . . 9 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 7.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 The Internet Group Management Protocol (IGMP) is used by IPv4 systems 80 (hosts and routers) to report their IP multicast group memberships to 81 any neighboring multicast routers. There are two popular versions: 82 IGMP v2, as specified in [RFC2236] and IGMP v3, as specified in 83 [RFC3376]. However, both versions establish a fully "open" multicast 84 network, where any host can join any multicast group as a recipient 85 without receiver access control. 87 This document specifies a Secure Internet Group Management Protocol 88 (SIGMP) working in a "hybrid" multicast network. In a hybrid 89 network, multicast groups are classified into two categories: open 90 groups and secured groups. Open groups refer to multicast groups 91 that any host can join unconditionally as a receiver. Secured groups 92 refer to multicast groups with receiver access control, e.g., only 93 hosts operated by authenticated and authorized end users are 94 permitted to join as receivers. SIGMP retains most mechanisms of 95 IGMP and enforces receiver access control to secured groups in a 96 multicast network. On the one hand, any host could report its 97 interest in open groups freely as in IGMP. On the other hand, only 98 hosts operated by the authenticated and authorized end users are 99 permitted to report their interest in secured groups. 101 Instead of a new specific mechanism, SIGMP uses IPsec [RFC4301] to 102 implement receiver access control to secured groups at the IP layer. 103 Some Security Associations (SAs) are created to secure the SIGMP 104 packets that are used to report or query secured groups. The packets 105 coming from the unauthorized hosts will be discarded by the IPsec 106 subsystem if they are used to report or query interest in secured 107 groups. 109 1.1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 112 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 113 this document are to be interpreted as described in RFC 2119 114 [RFC2119]. 116 It is assumed that the reader is familiar with the defining documents 117 for IGMP [RFC2236] and [RFC3376]. Unless otherwise noted, terms 118 defined in these documents are used with the same meaning in this 119 one. 121 In addition, the following terms are used in this document. 123 open group: A multicast group without receiver access control. Any 124 host can unconditionally join any open group as a receiver, e.g. the 125 data in a open group can be received by any host. 127 secured group: A multicast group with receiver access control. Only 128 hosts operated by authenticated and authorized end users are 129 permitted to join a secured group as a receiver, e.g. the data in a 130 secured group can only be received by hosts operated by authenticated 131 and authorized end users. 133 1.2. Assumptions 135 In order to focus on the actions of group membership (e.g., joining 136 and leaving groups), the following topics are assumed to be discussed 137 elsewhere: 139 1. how to distinguish between secured groups and open groups; 141 2. how to authenticate and authorize the operators of the devices 142 (hosts and routers); 144 3. how to distribute the necessary Security Associations to 145 participant devices (hosts and routers). 147 The existence of the group property (secured or open) defines the 148 hybrid nature of the environment in which SIGMP works. A variety of 149 existing protocols (e.g., LDAP) can be used to enquire as to the 150 status of a particular multicast group. 152 The hosts that show interest in secured groups MUST be operated by 153 authenticated and authorized end users. One approach to the task of 154 authentication and authorization of end users is based on the use of 155 PANA [RFC5191] and EAP [RFC3748], and is described in 156 [I-D.atwood-mboned-mrac-req], [I-D.atwood-mboned-mrac-arch] and 157 draft-atwood-mboned-pana (not yet published). 159 A coordination protocol may be needed to manage and distribute the 160 Security Associations (SAs) for secured groups among the routers and 161 the hosts that correspond to authenticated and authorized end users. 162 One set of possible procedures for SA creation and maintenance is 163 specified in draft-atwood-pim-gsam (not yet published). 165 2. Overview of SIGMP 167 SIGMP is an extension to IGMP and performs receiver access control 168 for groups in a multicast network. It retains most mechanisms of 169 IGMP and has two working modes: 1) mode compatible with IGMP v2 and 170 2) mode compatible with IGMP v3. It works in either mode and is 171 transparent for hosts that support only IGMP, i.e., that do not 172 support SIGMP. In addition, SIGMP uses IPsec to secure part of its 173 packets. For an open group, it delivers the data to any host 174 unconditionally as IGMP does. However, for a secured group, SIGMP 175 only delivers the data to the hosts that have established SAs in the 176 IPsec subsystem in order to perform access control. 178 In a network segment, hosts show their interest in secured groups 179 using IPsec protected packets although their interest for open groups 180 is still reported using unprotected packets. Similarly, routers 181 query the membership interest for a secured group using IPsec 182 protected packets, although the general query and the query for the 183 membership of open groups are performed using unprotected packets. 185 In general, the packets in SIGMP are classified into four categories, 186 which are Query for Open Group (OGQ), Query for Secured Group (SGQ), 187 Report for Open Group (OGR) and Report for Secured Group (SGR). OGQ 188 and SGQ are sent by the the Querier and are used to learn the 189 membership of open groups (or all groups for general query) and 190 secured groups respectively. In detail, OGQ includes general query, 191 specific-group query for open group and group-and-source-specific 192 query for the source of open group. SGQ includes specific-group 193 query for secured group and group-and-source-specific query for the 194 source of secured group. OGR and SGR are sent by hosts and used to 195 report the membership of open groups and secured groups respectively. 196 In detail, OGR includes report to specific-group query for open 197 group, report to group-and-source-specific query for the source of 198 open group, unsolicited report for open group and part of reports to 199 general query. SGR includes report to specific-group query for 200 secured group, report to group-and-source-specific query for the 201 source of secured group, unsolicited report for secured group and 202 part of reports to general query. SGQ and SGR are protected by IPsec 203 at IP layer while OGQ and OGR are delivered without IPsec protection. 205 The destination address of packets in IP layer is specified as 206 follows. In SGQ and SGR, the destination address is a secured group 207 address. In OGQ, it is 224.0.0.1 if the packet is general query and 208 otherwise it is an open group address. In OGR, it is 224.0.0.22 if 209 the packet is the report to general query compatible with IGMP v3 and 210 otherwise it is an open group address. The two addresses of 211 224.0.0.1 and 224.0.0.22 are the open group addresses. NOTE: When 212 SIGMP works in the mode compatible with IGMP v3, the response to a 213 general query contains zero or one OGR and zero or more SGR. It is 214 described in detail in Section 5.2.1. 216 3. Packet Format 218 The packet format of SIGMP is identical to the packet format for 219 IGMP. In detail, the format is the same as IGMP v2 when SIGMP works 220 in the mode compatible with IGMP v2. The format is the same as IGMP 221 v3 when SIGMP works in the mode compatible with IGMP v3. 223 4. Router Operations 225 Router operations in SIGMP are based on router operations in IGMP. 226 However, some additional operations must be appended since access 227 control to secured groups is extended into SIGMP. This section 228 describes the additional operations for the two working modes. 230 4.1. Router Operations Compatible with IGMP v2 232 The additional router operations focus on the operations for a 233 received report. 235 4.1.1. Router Operations for a Received Report 237 On receiving a report, a router checks the group address in the 238 received report. If the group address indicates an open group, the 239 report is considered as an OGR. A router will process an OGR as it 240 does that in IGMP v2 directly. Otherwise, the received report is an 241 SGR that SHOULD just have been authenticated (and decrypted) by the 242 IPsec subsystem (e.g., AH [RFC4302]). For SGR, a router must perform 243 two verifications: address consistency and SA existence. 245 In the address consistency verification, a router compares two 246 addresses: the group address in the SIGMP report and the destination 247 address in the IP header. The verification fails if the two 248 addresses are not the same. In the failure case, the sender of the 249 IGMP Report has attempted to hide a request for a specific group 250 (probably a secured group) in an IGMP Report for a different group 251 (probably an open group). This will cause the IPsec subsystem to 252 deliver the IGMP Report without requiring it to be protected. 253 Therefore a router must discard the report if this address 254 consistency verification fails. 256 In the SA existence verification, a router checks whether SAs have 257 been established for the secured group whose address is contained in 258 the received report. The verification fails if there are no valid 259 SAs for the group in the router's IPsec subsystem. Since the IPsec 260 subsystem is used to enforce the access control, no access to a 261 secured group is permitted until its SAs have been established. 262 Therefore a router must discard the report if this verification 263 fails. 265 If the two verifications succeed on SGR, a router will proceed to 266 update the group memberships and refresh the timers as it does in 267 IGMP v2. In summary, the router operations for a received report are 268 shown in Table 1. 270 +---+-------------+------------------+------------+-----------------+ 271 | # | Group | Address | SA | Operations for | 272 | | Address | Consistency | Existence | Report | 273 +---+-------------+------------------+------------+-----------------+ 274 | 1 | Open | - | - | Process as IGMP | 275 | | | | | v2 | 276 | 2 | Secured | No | - | Discard | 277 | 3 | Secured | Yes | No | Discard | 278 | 4 | Secured | Yes | Yes | Process as IGMP | 279 | | | | | v2 | 280 +---+-------------+------------------+------------+-----------------+ 282 Table 1: Router Operations for a Received Report for the Mode 283 Compatible with IGMP v2 285 4.2. Router Operations Compatible with IGMP v3 287 The additional router operations still focus on the operations for a 288 received report. However, there is a little difference between the 289 operations in the mode compatible with IGMP v3 and the operations in 290 the mode compatible with IGMP v2, since the formats of received 291 reports in the two modes are different. 293 4.2.1. Router Operations on a Received Report 295 On receiving a report, a router checks the number of group records in 296 the report. If the number is more than one, it indicates that the 297 report is an OGR, but not an SGR, since only one group record is 298 included in an SGR. In this case, every group record in the report 299 must be verified further as follows. A router checks the multicast 300 address in the group record. If the multicast address is an open 301 group address, a router will process the group record as it does in 302 IGMP v3. Otherwise, a secured group address is in the group record 303 and a router must discard the group record. The OGR including more 304 than one group records is not protected by IPsec systems and is not 305 permitted to contain any information related to any secured group. 307 In contrast, if the number of the group records is just one, a router 308 still checks the multicast address in the single group record. If 309 the multicast address indicates an open group address, the received 310 report is considered as an OGR and a router will process the group 311 record as it does that in IGMP v3 directly. Otherwise, the received 312 report SHOULD be an SGR that SHOULD just be authenticated (and 313 decrypted) by the IPsec subsystem. For the single group record in 314 the SGR, a router must perform two verifications, address consistency 315 and SA existence, similar to Section 4.1. 317 In the address consistency verification, a router compares two 318 addresses: the multicast address in the group record of the SIGMP 319 report and the destination address in the IP header. A router must 320 discard the report if the two addresses are not the same. 322 In SA existence verification, a router checks whether SAs have been 323 established for the secured group whose address is contained in the 324 group record of the received report. A router must discard the 325 report if there are no SAs established in the router's IPsec 326 subsystem. 328 If the two verifications succeed on an SGR, a router will proceed to 329 update the group memberships and refresh the timers as it does in 330 IGMP v3. In summary, router operations for a received report are 331 shown in Table 2. 333 +---+---------+------------+-------------+-----------+--------------+ 334 | # | #Group | Multicast | Address | SA | Operations | 335 | | record | Address in | Consistency | Existence | for Group | 336 | | in | Group | | | Record | 337 | | report | Record | | | | 338 +---+---------+------------+-------------+-----------+--------------+ 339 | 1 | >1 | Open | - | - | Process as | 340 | | | | | | IGMP v2 | 341 | 2 | >1 | Secured | - | - | Discard | 342 | 3 | =1 | Open | - | - | Process as | 343 | | | | | | IGMP v2 | 344 | 4 | =1 | Secured | No | - | Discard | 345 | 5 | =1 | Secured | Yes | No | Discard | 346 | 6 | =1 | Secured | Yes | Yes | Process as | 347 | | | | | | IGMP v2 | 348 +---+---------+------------+-------------+-----------+--------------+ 350 Table 2: Router Operations for a Received Report for Mode Compatible 351 with IGMP v3 353 5. Host Operations 355 Host operations in SIGMP are based on host operations in IGMP. 356 However, some additional operations must be appended since access 357 control to secured group is extended into SIGMP. This section 358 describes the additional operations for the two working modes. 360 5.1. Host Operations Compatible with IGMP v2 362 The additional host operations focus on the conditions for 363 unsolicited report and the operations for a received query. 365 5.1.1. Conditions for Unsolicited Report 367 Before creating an unsolicited report, a host must check the reported 368 group. If the report group is open, a host will do as in IGMP v2. 369 If secured, a host must continue to check whether SAs have been 370 established for the secured group. If no SA is defined for this 371 group address, a host MUST return an error indication to the issuer 372 of the request that provoked the unsolicited report. [[Is this the 373 right behavior?]] 375 5.1.2. Host Operations for a Received Query 377 On receiving the query, a host does the additional operation as a 378 router does in Section 4.2.1. 380 5.2. Host Operations Compatible with IGMP v3 382 The additional host operations focus on three aspects: 1) the 383 conditions for unsolicited report, 2) the operations for a received 384 non-general query and 3) the operations for a received general query. 385 The first two are identical to those described in Section 5.1.1 and 386 Section 5.1.2. In this subsection, only the last case is explained. 388 5.2.1. Host Operations for a Received General Query 390 When it determines to respond to a general query, a host creates zero 391 or one OGR and zero or more SGR in SIGMP instead of one report in 392 IGMP v3. The OGR reports the current state of all the open groups 393 that the host is interested in. Each SGR reports the current state 394 of one secured group that the host in interested in. 396 At the IP layer, the destination address of OGR is 224.0.0.22. In 397 contrast, at the IP layer the destination addresses of SGRs are the 398 secured group addresses. Since IPsec has established SAs for secured 399 groups, SGRs will be protected and the OGR will not. 401 6. IANA Considerations 403 The protocol number of SIGMP is the same as IGMP. 405 7. References 407 7.1. Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 413 2", RFC 2236, November 1997. 415 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 416 Thyagarajan, "Internet Group Management Protocol, Version 417 3", RFC 3376, October 2002. 419 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 420 Internet Protocol", RFC 4301, December 2005. 422 7.2. Informative References 424 [I-D.atwood-mboned-mrac-arch] 425 william.atwood@concordia.ca, w., Li, B., and S. Islam, 426 "Architecture for IP Multicast Receiver Access Control", 427 draft-atwood-mboned-mrac-arch-00 (work in progress), 428 October 2013. 430 [I-D.atwood-mboned-mrac-req] 431 william.atwood@concordia.ca, w., Islam, S., and B. Li, 432 "Requirements for IP Multicast Receiver Access Control", 433 draft-atwood-mboned-mrac-req-00 (work in progress), 434 October 2013. 436 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 437 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 438 3748, June 2004. 440 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 441 2005. 443 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 444 Yegin, "Protocol for Carrying Authentication for Network 445 Access (PANA)", RFC 5191, May 2008. 447 Authors' Addresses 449 William Atwood 450 Concordia University/CSE 451 1455 de Maisonneuve Blvd, West 452 Montreal, QC H3G 1M8 453 Canada 455 Phone: +1(514)848-2424 ext3046 456 Email: william.atwood@concordia.ca 457 URI: http://users.encs.concordia.ca/~bill 459 Bing Li 460 Concordia University/CSE 461 1455 de Maisonneuve Blvd, West 462 Montreal, QC H3G 1M8 463 Canada 465 Email: leebingice@gmail.com