idnits 2.17.1 draft-atwood-mboned-mrac-arch-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2014) is 3584 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-atwood-mboned-mrac-req-00 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-16) exists of draft-yeung-g-ikev2-07 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED W. Atwood 3 Internet-Draft B. Li 4 Intended status: Informational Concordia University/CSE 5 Expires: January 5, 2015 S. Islam 6 United International University/CSE 7 July 4, 2014 9 Architecture for IP Multicast Receiver Access Control 10 draft-atwood-mboned-mrac-arch-01 12 Abstract 14 This document specifies the architecture of IP multicast receiver 15 access control (MRAC). The interacting components, the protocols and 16 the operations in MRAC system are specified in this document. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 5, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. MRAC Architecture Overview . . . . . . . . . . . . . . . . . 3 54 3. Multicast Architecture . . . . . . . . . . . . . . . . . . . 5 55 3.1. IGMP/MLD . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Multicast Routing Protocol (MRP) . . . . . . . . . . . . 6 57 4. AAA Architecture . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Diameter / RADIUS . . . . . . . . . . . . . . . . . . . . 6 59 4.2. EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.3. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. IP Security (IPsec) Architecture . . . . . . . . . . . . . . 8 62 6. MRAC System Operation . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Mapping the Multicast and AAA Architectures to the 64 Network Boxes . . . . . . . . . . . . . . . . . . . . . . 9 65 6.2. EAP Exchanges . . . . . . . . . . . . . . . . . . . . . . 10 66 6.3. PANA Exchanges . . . . . . . . . . . . . . . . . . . . . 10 67 6.4. Diameter/RADIUS Exchanges . . . . . . . . . . . . . . . . 10 68 6.5. IPsec Exchanges . . . . . . . . . . . . . . . . . . . . . 11 69 6.6. IGMP/MLD Exchanges . . . . . . . . . . . . . . . . . . . 11 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 10.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 Group communication at the application level usually implies IP 81 multicast at the network level. The use of IP multicast can only be 82 justified in certain environments if it is possible to authenticate 83 the receiving users, and verify their authorization to receive the 84 multicast data stream. However, the design of IP multicast [RFC1112] 85 ensures that there can be no relationship between the sender and the 86 receiving users, i.e., the sender is not aware of the identity of the 87 receivers (or even if there are any receivers at all). This can make 88 it very difficult for the sender to generate any revenue from the 89 receivers of IP multicast services. 91 An alternative to access control by the sender is access control by 92 the Network Service Provider, based on policies provided (directly or 93 indirectly) by the sender. [I-D.atwood-mboned-mrac-req] lists the 94 requirements on a set of mechanisms that allow a Network Service 95 Provider to act on behalf of a sender (since the Network Service 96 Provider has access to information from the receiving user that the 97 sender does not have access to) to meet the access control and 98 revenue generation goals, while remaining as independent as possible 99 from the specific business model in use. 101 This document assumes that the various business models could be 102 simplified into two assumptions as follows: 104 The receiving user that receives the multicast data possesses a 105 "ticket", which contains a description of the multicast group to 106 be joined and whose validity can be demonstrated. 108 The Network Service Provider that delivers the multicast data 109 possesses the "policies" that contain a description of how to 110 validate the "ticket" of a receiving user. 112 [I-D.atwood-mboned-mrac-req] has presented how to fulfill the two 113 assumptions in our business models. 115 This document proposes a Multicast Receiver Access Control (MRAC) 116 architecture that satisfies all the requirements in 117 [I-D.atwood-mboned-mrac-req]. In this draft, the above two 118 assumptions are used so that the business model in use does not have 119 to be considered. 121 2. MRAC Architecture Overview 123 The MRAC system has the interacting components as shown in Figure 1. 124 A brief description of the components is as follows: 126 _________________________ 127 | ________ ___ | _______ 128 | |AAAS | |NAS| | |EU | 129 | |______|^^^^^^^|___|^^|^^^^| ___ | 130 | ^ |AR | | ||EUD|| 131 | ^ |___|''|''''||___|| 132 | ^ | |_____| 133 | ^ ____ | _______ 134 | ^ |NAS| | |EU | 135 | ^^^^^^^^^^|___|^^|^^^^| ___ | 136 | |AR | | ||EUD|| 137 |NSP |___|''|''''||___|| 138 |________________________| |_____| 140 ^^^^ Application-level access control flow 141 '''' Network-level access control flow 142 EU End User 143 EUD End User Device 144 NSP Network Service Provider 145 AAAS Authentication, Authorization and Accounting Server 146 AR Access Router 147 NAS Network Access Server 149 Figure 1: MRAC Architecture 151 End User (EU): 153 A subscriber who wishes to receive multicast data delivered in a 154 multicast group. The EU possesses a "ticket" to verify his/her 155 subscription for a specific group. However, the way how to 156 distribute the ticket to the EU is dependent on the business model 157 so that it is out of scope for this draft. 159 End User Device (EUD): 161 A device, connected to the Network Service Provider via one or more 162 technologies, operated by an End User. 164 Network Service Provider (NSP): 166 An organization that delivers the multicast content to the End User 167 Device and implements the access control of the receiving End Users 168 for multicast groups. The NSP employs various devices to fulfill 169 its services. 171 AAA Server (AAAS): 173 A device that manages authentication, authorization and accounting 174 services for multicast groups in NSP. The AAAS possesses policies 175 to validate the EU's tickets. However, the way how to distribute 176 the policies to the AAAS is dependent on the business model so that 177 it is out of scope for this draft. 179 Access Router (AR): 181 A router, close to the EU, that is responsible for adjudicating the 182 access rights to the network and the multicast groups in the NSP. 184 Network Access Server (NAS): 186 The enforcement point for managing authentication, authorization 187 and accounting services for multicast groups in the NSP. Normally 188 the NAS is co-located with the Access Router. 190 The operations among the interacting components are generalized into 191 two levels as follows: 193 Application-level operations: 195 The EU interacts with the NAS to request joining the group to which 196 he/she has subscribed. The EU's ticket is carried in the request. 197 The NAS consults the AAAS for the EU's request. The AAAS uses the 198 policies to validate the ticket so as to authenticate the EU for 199 the network and to authorize the EU for the multicast group. Then 200 the AAAS returns the authentication and authorization result to the 201 NAS. If the EU is authorized, some cryptographic materials derived 202 from the ticket are also provided to the NAS by the AAAS. 203 Moreover, the accounting information for the authorized EU is also 204 exchanged between the NAS and the AAAS. 206 Network-level operations: 208 The EU interacts with the AR to join the data distribution tree 209 that is delivering his/her subscription content. The exchanges 210 between the EU and the AR at the network level are secured by the 211 cryptographic materials derived from those used at the application 212 level, to couple the access control for the two levels. 214 3. Multicast Architecture 216 3.1. IGMP/MLD 218 Internet Group Management Protocol (IGMP) and Multicast Listener 219 Discovery (MLD) have been standardized by the IETF for IPv4 and IPv6 220 systems (host or router) to inform the neighbouring multicast 221 router(s) about the multicast group memberships of these systems. 223 In IGMP, an IPv4 system sends a join or leave message (through 224 Membership Report) when it wants to join or leave a multicast group 225 (or some specific sources of a group). All multicast routers that 226 are directly connected to the IPv4 system receive the Membership 227 Report to learn which multicast groups are of interest to the IPv4 228 systems. Among these multicast routers, only one will be elected as 229 "Querier". Its role is to query IPv4 systems about their interest in 230 multicast groups by sending Membership Query. The other multicast 231 routers are called Non-Queriers; they just receive the Membership 232 Report messages from the IPv4 system and the Membership Query message 233 from the Querier. 235 MLD is a similar protocol but it is used by IPv6 systems. 237 The details of the IGMP/MLD architecture and operation are specified 238 in [RFC3376] and [RFC3810]. 240 3.2. Multicast Routing Protocol (MRP) 242 The multicast routing protocol (typically PIM-SM) builds a multicast 243 tree among routers to distribute multicast data to receivers. 245 One of the receiver's neighbouring routers is elected as the 246 designated router (DR) or group designated router (GDR). On 247 receiving the IGMP/MLD join message, DR/GDR will be grafted to the 248 multicast data distribution tree on behalf of the neighbouring 249 receiver. On receiving an IGMP leave Message, DR/GDR will be pruned 250 from the data distribution tree if no other neighbouring receivers 251 are interested in the group. 253 The details of PIM-SM architecture and operation are specified in 254 [RFC4601]. 256 4. AAA Architecture 258 4.1. Diameter / RADIUS 260 AAA protocols are used to support AAA communication between a AAA 261 client and AAA server(s). RADIUS and Diameter are the two AAA 262 protocols that the IETF has standardized. 264 Remote Authentication Dial In User Service (RADIUS) is a protocol for 265 carrying information related to authentication, authorization, and 266 accounting between a RADIUS Client and RADIUS Server. A RADIUS 267 Client is responsible for passing user information to designated 268 RADIUS Servers, and then acting on the response that is returned. 269 RADIUS Servers are responsible for receiving user connection 270 requests, authenticating the user, and then returning all 271 configuration information necessary for the client to deliver service 272 to the user. 274 Diameter is the successor of RADIUS. The Diameter base protocol 275 provides a AAA framework. The Diameter applications, such as NASREQ 276 and Mobile IPv4, specify how to use the base protocol within the 277 context of their applications. 279 The details of Diameter / RADIUS architecture and operation are 280 specified in [RFC6733] and [RFC2865] 282 4.2. EAP 284 Extensible Authentication Protocol (EAP) provides an authentication 285 framework for support of multiple authentication methods. 287 An EAP exchange runs between an authenticator and a peer. The 288 authenticator as an initiator uses one or more EAP methods in 289 sequence to authenticate the peer. 291 Rather than requiring the authenticator to support authentication 292 methods, EAP permits the use of a backend authentication server, 293 which implements EAP methods, with the authenticator acting as a 294 pass-through. In this case, a backend authentication server is 295 connected with the authenticator. The actual authentication will be 296 performed by the backend authentication server. The authenticator 297 forwards EAP packets received from the peer to the backend 298 authentication server; packets received from the backend 299 authentication server are forwarded to the peer. 301 EAP does not run directly over the IP layer. The PANA protocol 302 (Section 4.3) and the AAA protocol (Section 4.1) will be used to 303 carry the EAP packets. 305 The details of the EAP architecture and operation are specified in 306 [RFC3748]. 308 4.3. PANA 310 Protocol for carrying Authentication for Network Access (PANA) is a 311 network access authentication protocol that works as an EAP lower 312 layer for transmitting EAP packets. PANA carries EAP authentication 313 methods (encapsulated inside EAP packets) between a PANA Client (PaC) 314 and a PANA Authentication Agent (PAA) in the access network. 316 The PaC, as the client implement of PANA, interacts with the PAA, as 317 the server implement of PANA, in the authentication process using the 318 PANA protocol. PAA consults an Authentication Server (AS) for 319 authentication and authorization of a PaC. If the AS resides on the 320 same node as the PAA, an API is sufficient for this interaction. 321 When the PAA is separated from the AS, a AAA protocol (e.g., 322 Diameter) will be used for their communication. The AS is a 323 conventional backend AAAS that terminates the EAP and the EAP 324 methods. 326 A PANA Enforcement Point (EP) allows (blocks) data traffic of an 327 authorized (unauthorized) PaC. When the PAA and EP reside on the 328 same node, they use an API for communication; otherwise, a protocol 329 (e.g., SNMP) is required. 331 The details of the PANA architecture and operation are specified in 332 [RFC5191] and [RFC5193]. 334 5. IP Security (IPsec) Architecture 336 The IP security (IPsec) architecture is designed to provide security 337 services for traffic at the IP layer. Most of the security services 338 are provided through use of two traffic security protocols, the 339 Authentication Header (AH)[RFC4302] and the Encapsulating Security 340 Payload (ESP)[RFC4303], and through the use of cryptographic key 341 management procedures and protocols. 343 A security association (SA) is created in both sender and receiver. 344 It is a simplex "connection" that affords security services to the 345 traffic carried by it. The sender and receiver maintain their local 346 Security Association Database (SAD) to record their SAs. 348 In the unicast case, the SAs could be dynamically negotiated between 349 the sender and the receiver using IKEv2 [RFC5996]. In contrast, in 350 the multicast case, a Group Controller / Key Server (GCKS) is 351 responsible for distribution of the group SAs (GSA) to all the group 352 members (GM) in the same group. 354 The details of the IPsec architecture and its extension for multicast 355 are specified in [RFC4301] and [RFC5374]. 357 6. MRAC System Operation 359 The MRAC architecture is composed from individual elements drawn from 360 the pieces outlined in Sections 3, 4, and 5. In this way, it is 361 possible to meet the requirments as listed in 362 [I-D.atwood-mboned-mrac-req]. 364 6.1. Mapping the Multicast and AAA Architectures to the Network Boxes 366 In order to meet the requirements in [I-D.atwood-mboned-mrac-req], 367 all the functional entities that are applied in the multicast 368 routing, AAA and IPsec architectures are mapped into the participants 369 in our MRAC architecture as shown in Table 1. 371 The EU in MRAC system maps the IPv4/IPv6 system in IGMP/MLD, the 372 receiver in multicast routing protocol, PaC in PANA and EAP peer in 373 EAP. 375 The NAS in MRAC system maps the Diameter/RADIUS Client in Diameter/ 376 RADIUS, PAA in PANA and EAP Authenticator in EAP. 378 The AAAS in MRAC system maps the Diameter/RADIUS Server in Diameter/ 379 RADIUS, EAP backend authenticator server in EAP. 381 The AR in MRAC system maps the multicast router in IGMP/MLD including 382 Querier and Non-Querier, the EP in PANA. Moreover, the AR who wins 383 in DR/GDR election maps the DR/GDR in multicast routing protocol. 385 The EU and AR also map the GMs in IPsec. It depends on the specific 386 packet whether the sender is EU or AR. A special AR, called Querier, 387 may map the GCKS in IPsec. 389 +--------------------------------------+-----+------+-------+-----+ 390 | Roles | EU | NAS | AAAS | AR | 391 +--------------------------------------+-----+------+-------+-----+ 392 | IPv4/IPv6 systems in IGMP | x | | | | 393 | multicast routers in IGMP | | | | x | 394 | receiver in MRP | x | | | | 395 | DR/GDR in MRP | | | | x | 396 | Diameter/RADIUS Client | | x | | | 397 | Diameter/RADIUS Server | | | x | | 398 | PaC in PANA | x | | | | 399 | PAA in PANA | | x | | | 400 | AS in PANA | | | x | | 401 | EP in PANA | | | | x | 402 | EAP peer in EAP | x | | | | 403 | EAP authenticator in EAP | | x | | | 404 | backend authentication server in EAP | | | x | | 405 | GCKS in IPsec | | | | x | 406 | GM in IPsec | x | | | x | 407 +--------------------------------------+-----+------+-------+-----+ 409 Table 1: Mapping the Multicast and AAA Architectures to the Network 410 Boxes 412 6.2. EAP Exchanges 414 The EAP runs between an EU and an NAS, where the NAS can act as a 415 pass-through, and an AAAS is connected with the NAS. The policy is 416 used to determine whether actual authentication is performed by the 417 AAAS or the NAS. 419 In MRAC, it is recommended that the NAS use EAP-FAST as the EAP 420 authentication method to authenticate the EU. The EU carries a token 421 from his/her ticket in the EAP-FAST method. The token includes the 422 user information and group information that will be used by the NAS 423 or AAAS to make the authentication and authorization decision about 424 the EU. 426 6.3. PANA Exchanges 428 PANA carries the EAP-FAST method (encapsulated inside EAP packets) 429 between an EU and an NAS in the access network. An EU may be 430 configured with an IP address of the NAS as its PAA or dynamically 431 discover it using the default method of DHCP. 433 An EU, on receiving a request to join a multicast group while no GSAs 434 have been established for the group, initiates a PANA exchange with 435 an NAS as its PAA. During the PANA session, the NAS authenticates 436 and authorizes the EU. In addition, the re-authentication and re- 437 authorization may be required if necessary. The NAS would consult 438 the AAAS to perform the actual authentication if it is a pass-through 439 in the EAP exchange. The communication between NAS and AAAS is 440 implemented by Diameter/RADIUS exchanges explained in the next 441 subsection. Moreover, the NAS updates the filter state of the EU 442 according to the authorization result and provides the authorization 443 result and authorization attributes (mainly referring to a key 444 derived from the EAP-FAST method) to the AR(s) connected directly to 445 the EU. 447 6.4. Diameter/RADIUS Exchanges 449 When the NAS is a pass-through, the Diameter / RADIUS exchanges are 450 used between NAS and AAAS to carry information related to 451 authentication, authorization, and accounting. 453 In the Diameter / RADIUS exchanges, the NAS is responsible for 454 passing the EAP-FAST method (carrying the token of the EU's ticket) 455 to the AAAS, and then acting on the response that is returned. The 456 AAAS is responsible for authenticating and authorizing the EU, and 457 then returning the result and attributes (mainly including a key 458 derived from the EAP-FAST method) for the EU to the NAS. 460 6.5. IPsec Exchanges 462 IPsec is used to enforce the receiver access control at the network 463 level. A protocol is needed to create IPsec GSAs and then distribute 464 them to authorized EUs and their ARs dynamically. The protocol may 465 be very similar to the two existing IETF protocols, GDOI [RFC6407] 466 and G-IKEv2 [I-D.yeung-g-ikev2]. In MRAC, the Querier will become 467 the GCKS in the network segment. The authorized EUs and the other 468 ARs interact with their Querier. The Querier is responsible for 469 checking the authorized attributes of the EUs. Then the Querier 470 creates and distributes IPsec GSAs to the EUs and their ARs in the 471 same network segment. 473 However, the two existing IETF protocols (GDOI and G-IKEv2) do not 474 satisfy all the requirements for IPsec GSA creation and distribution 475 in MRAC. A new protocol has been drafted for use by MRAC. 477 6.6. IGMP/MLD Exchanges 479 IGMP/MLD is running among the EUs and their ARs. According to 480 [RFC3376] and [RFC3810], the EU uses the message of Membership Report 481 to report the current multicast reception status to its ARs. The 482 specific AR, called Querier, uses the message of Membership Query to 483 query the multicast reception status of its EUs. 485 However, in order to enforce the receiver access control at the 486 network level, the ARs and the EUs would filter out the received 487 Membership Report and Membership Query messages using their local 488 IPsec systems. The message of Membership Report that reports the 489 reception status of the subscribed group would be protected by IPsec 490 GSAs whose source address is the EU's address and whose destination 491 address is the address of the reported subscribed group. Also, the 492 Membership Query message that queries the reception status of the 493 subscribed group would be protected by IPsec GSAs whose source 494 address is the Querier's address and whose destination address is the 495 address of the queried subscribed group. 497 In order to utilize the IPsec system, IGMP and MLD must be extended. 498 However, the extension will be very small. 500 7. Security Considerations 502 TBD 504 8. IANA Considerations 506 This draft has no actions for IANA 508 9. Acknowledgements 510 10. References 512 10.1. Normative References 514 [I-D.atwood-mboned-mrac-req] 515 william.atwood@concordia.ca, w., Islam, S., and B. Li, 516 "Requirements for IP Multicast Receiver Access Control", 517 draft-atwood-mboned-mrac-req-00 (work in progress), 518 October 2013. 520 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 521 RFC 1112, August 1989. 523 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 524 "Remote Authentication Dial In User Service (RADIUS)", RFC 525 2865, June 2000. 527 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 528 Thyagarajan, "Internet Group Management Protocol, Version 529 3", RFC 3376, October 2002. 531 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 532 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 533 3748, June 2004. 535 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 536 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 538 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 539 Internet Protocol", RFC 4301, December 2005. 541 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 542 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 543 Protocol Specification (Revised)", RFC 4601, August 2006. 545 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 546 Yegin, "Protocol for Carrying Authentication for Network 547 Access (PANA)", RFC 5191, May 2008. 549 [RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and 550 A. Yegin, "Protocol for Carrying Authentication for 551 Network Access (PANA) Framework", RFC 5193, May 2008. 553 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 554 Extensions to the Security Architecture for the Internet 555 Protocol", RFC 5374, November 2008. 557 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 558 "Diameter Base Protocol", RFC 6733, October 2012. 560 10.2. Informative References 562 [I-D.yeung-g-ikev2] 563 Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key 564 Management using IKEv2", draft-yeung-g-ikev2-07 (work in 565 progress), November 2013. 567 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 568 2005. 570 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 571 4303, December 2005. 573 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 574 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 575 5996, September 2010. 577 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 578 of Interpretation", RFC 6407, October 2011. 580 Authors' Addresses 582 William Atwood 583 Concordia University/CSE 584 1455 de Maisonneuve Blvd, West 585 Montreal, QC H3G 1M8 586 Canada 588 Phone: +1(514)848-2424 ext3046 589 Email: william.atwood@concordia.ca 590 URI: http://users.encs.concordia.ca/~bill 592 Bing Li 593 Concordia University/CSE 594 1455 de Maisonneuve Blvd, West 595 Montreal, QC H3G 1M8 596 Canada 598 Email: leebingice@gmail.com 599 Salekul Islam 600 United International University/CSE 601 House 80, Road 8/A, Mirza Golam Hafiz Road 602 Dhanmondi, Dhaka 1209 603 Bangladesh 605 Email: salekul@cse.uiu.ac.bd