Internet DRAFT - draft-atwood-mboned-mrac-arch
draft-atwood-mboned-mrac-arch
MBONED W. Atwood
Internet-Draft B. Li
Intended status: Informational Concordia University/CSE
Expires: January 5, 2015 S. Islam
United International University/CSE
July 4, 2014
Architecture for IP Multicast Receiver Access Control
draft-atwood-mboned-mrac-arch-01
Abstract
This document specifies the architecture of IP multicast receiver
access control (MRAC). The interacting components, the protocols and
the operations in MRAC system are specified in this document.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Atwood, et al. Expires January 5, 2015 [Page 1]
Internet-Draft MRAC Architecture July 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. MRAC Architecture Overview . . . . . . . . . . . . . . . . . 3
3. Multicast Architecture . . . . . . . . . . . . . . . . . . . 5
3.1. IGMP/MLD . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Multicast Routing Protocol (MRP) . . . . . . . . . . . . 6
4. AAA Architecture . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Diameter / RADIUS . . . . . . . . . . . . . . . . . . . . 6
4.2. EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IP Security (IPsec) Architecture . . . . . . . . . . . . . . 8
6. MRAC System Operation . . . . . . . . . . . . . . . . . . . . 8
6.1. Mapping the Multicast and AAA Architectures to the
Network Boxes . . . . . . . . . . . . . . . . . . . . . . 9
6.2. EAP Exchanges . . . . . . . . . . . . . . . . . . . . . . 10
6.3. PANA Exchanges . . . . . . . . . . . . . . . . . . . . . 10
6.4. Diameter/RADIUS Exchanges . . . . . . . . . . . . . . . . 10
6.5. IPsec Exchanges . . . . . . . . . . . . . . . . . . . . . 11
6.6. IGMP/MLD Exchanges . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Group communication at the application level usually implies IP
multicast at the network level. The use of IP multicast can only be
justified in certain environments if it is possible to authenticate
the receiving users, and verify their authorization to receive the
multicast data stream. However, the design of IP multicast [RFC1112]
ensures that there can be no relationship between the sender and the
receiving users, i.e., the sender is not aware of the identity of the
receivers (or even if there are any receivers at all). This can make
it very difficult for the sender to generate any revenue from the
receivers of IP multicast services.
An alternative to access control by the sender is access control by
the Network Service Provider, based on policies provided (directly or
indirectly) by the sender. [I-D.atwood-mboned-mrac-req] lists the
requirements on a set of mechanisms that allow a Network Service
Provider to act on behalf of a sender (since the Network Service
Provider has access to information from the receiving user that the
sender does not have access to) to meet the access control and
Atwood, et al. Expires January 5, 2015 [Page 2]
Internet-Draft MRAC Architecture July 2014
revenue generation goals, while remaining as independent as possible
from the specific business model in use.
This document assumes that the various business models could be
simplified into two assumptions as follows:
The receiving user that receives the multicast data possesses a
"ticket", which contains a description of the multicast group to
be joined and whose validity can be demonstrated.
The Network Service Provider that delivers the multicast data
possesses the "policies" that contain a description of how to
validate the "ticket" of a receiving user.
[I-D.atwood-mboned-mrac-req] has presented how to fulfill the two
assumptions in our business models.
This document proposes a Multicast Receiver Access Control (MRAC)
architecture that satisfies all the requirements in
[I-D.atwood-mboned-mrac-req]. In this draft, the above two
assumptions are used so that the business model in use does not have
to be considered.
2. MRAC Architecture Overview
The MRAC system has the interacting components as shown in Figure 1.
A brief description of the components is as follows:
Atwood, et al. Expires January 5, 2015 [Page 3]
Internet-Draft MRAC Architecture July 2014
_________________________
| ________ ___ | _______
| |AAAS | |NAS| | |EU |
| |______|^^^^^^^|___|^^|^^^^| ___ |
| ^ |AR | | ||EUD||
| ^ |___|''|''''||___||
| ^ | |_____|
| ^ ____ | _______
| ^ |NAS| | |EU |
| ^^^^^^^^^^|___|^^|^^^^| ___ |
| |AR | | ||EUD||
|NSP |___|''|''''||___||
|________________________| |_____|
^^^^ Application-level access control flow
'''' Network-level access control flow
EU End User
EUD End User Device
NSP Network Service Provider
AAAS Authentication, Authorization and Accounting Server
AR Access Router
NAS Network Access Server
Figure 1: MRAC Architecture
End User (EU):
A subscriber who wishes to receive multicast data delivered in a
multicast group. The EU possesses a "ticket" to verify his/her
subscription for a specific group. However, the way how to
distribute the ticket to the EU is dependent on the business model
so that it is out of scope for this draft.
End User Device (EUD):
A device, connected to the Network Service Provider via one or more
technologies, operated by an End User.
Network Service Provider (NSP):
An organization that delivers the multicast content to the End User
Device and implements the access control of the receiving End Users
for multicast groups. The NSP employs various devices to fulfill
its services.
AAA Server (AAAS):
Atwood, et al. Expires January 5, 2015 [Page 4]
Internet-Draft MRAC Architecture July 2014
A device that manages authentication, authorization and accounting
services for multicast groups in NSP. The AAAS possesses policies
to validate the EU's tickets. However, the way how to distribute
the policies to the AAAS is dependent on the business model so that
it is out of scope for this draft.
Access Router (AR):
A router, close to the EU, that is responsible for adjudicating the
access rights to the network and the multicast groups in the NSP.
Network Access Server (NAS):
The enforcement point for managing authentication, authorization
and accounting services for multicast groups in the NSP. Normally
the NAS is co-located with the Access Router.
The operations among the interacting components are generalized into
two levels as follows:
Application-level operations:
The EU interacts with the NAS to request joining the group to which
he/she has subscribed. The EU's ticket is carried in the request.
The NAS consults the AAAS for the EU's request. The AAAS uses the
policies to validate the ticket so as to authenticate the EU for
the network and to authorize the EU for the multicast group. Then
the AAAS returns the authentication and authorization result to the
NAS. If the EU is authorized, some cryptographic materials derived
from the ticket are also provided to the NAS by the AAAS.
Moreover, the accounting information for the authorized EU is also
exchanged between the NAS and the AAAS.
Network-level operations:
The EU interacts with the AR to join the data distribution tree
that is delivering his/her subscription content. The exchanges
between the EU and the AR at the network level are secured by the
cryptographic materials derived from those used at the application
level, to couple the access control for the two levels.
3. Multicast Architecture
3.1. IGMP/MLD
Internet Group Management Protocol (IGMP) and Multicast Listener
Discovery (MLD) have been standardized by the IETF for IPv4 and IPv6
Atwood, et al. Expires January 5, 2015 [Page 5]
Internet-Draft MRAC Architecture July 2014
systems (host or router) to inform the neighbouring multicast
router(s) about the multicast group memberships of these systems.
In IGMP, an IPv4 system sends a join or leave message (through
Membership Report) when it wants to join or leave a multicast group
(or some specific sources of a group). All multicast routers that
are directly connected to the IPv4 system receive the Membership
Report to learn which multicast groups are of interest to the IPv4
systems. Among these multicast routers, only one will be elected as
"Querier". Its role is to query IPv4 systems about their interest in
multicast groups by sending Membership Query. The other multicast
routers are called Non-Queriers; they just receive the Membership
Report messages from the IPv4 system and the Membership Query message
from the Querier.
MLD is a similar protocol but it is used by IPv6 systems.
The details of the IGMP/MLD architecture and operation are specified
in [RFC3376] and [RFC3810].
3.2. Multicast Routing Protocol (MRP)
The multicast routing protocol (typically PIM-SM) builds a multicast
tree among routers to distribute multicast data to receivers.
One of the receiver's neighbouring routers is elected as the
designated router (DR) or group designated router (GDR). On
receiving the IGMP/MLD join message, DR/GDR will be grafted to the
multicast data distribution tree on behalf of the neighbouring
receiver. On receiving an IGMP leave Message, DR/GDR will be pruned
from the data distribution tree if no other neighbouring receivers
are interested in the group.
The details of PIM-SM architecture and operation are specified in
[RFC4601].
4. AAA Architecture
4.1. Diameter / RADIUS
AAA protocols are used to support AAA communication between a AAA
client and AAA server(s). RADIUS and Diameter are the two AAA
protocols that the IETF has standardized.
Remote Authentication Dial In User Service (RADIUS) is a protocol for
carrying information related to authentication, authorization, and
accounting between a RADIUS Client and RADIUS Server. A RADIUS
Client is responsible for passing user information to designated
Atwood, et al. Expires January 5, 2015 [Page 6]
Internet-Draft MRAC Architecture July 2014
RADIUS Servers, and then acting on the response that is returned.
RADIUS Servers are responsible for receiving user connection
requests, authenticating the user, and then returning all
configuration information necessary for the client to deliver service
to the user.
Diameter is the successor of RADIUS. The Diameter base protocol
provides a AAA framework. The Diameter applications, such as NASREQ
and Mobile IPv4, specify how to use the base protocol within the
context of their applications.
The details of Diameter / RADIUS architecture and operation are
specified in [RFC6733] and [RFC2865]
4.2. EAP
Extensible Authentication Protocol (EAP) provides an authentication
framework for support of multiple authentication methods.
An EAP exchange runs between an authenticator and a peer. The
authenticator as an initiator uses one or more EAP methods in
sequence to authenticate the peer.
Rather than requiring the authenticator to support authentication
methods, EAP permits the use of a backend authentication server,
which implements EAP methods, with the authenticator acting as a
pass-through. In this case, a backend authentication server is
connected with the authenticator. The actual authentication will be
performed by the backend authentication server. The authenticator
forwards EAP packets received from the peer to the backend
authentication server; packets received from the backend
authentication server are forwarded to the peer.
EAP does not run directly over the IP layer. The PANA protocol
(Section 4.3) and the AAA protocol (Section 4.1) will be used to
carry the EAP packets.
The details of the EAP architecture and operation are specified in
[RFC3748].
4.3. PANA
Protocol for carrying Authentication for Network Access (PANA) is a
network access authentication protocol that works as an EAP lower
layer for transmitting EAP packets. PANA carries EAP authentication
methods (encapsulated inside EAP packets) between a PANA Client (PaC)
and a PANA Authentication Agent (PAA) in the access network.
Atwood, et al. Expires January 5, 2015 [Page 7]
Internet-Draft MRAC Architecture July 2014
The PaC, as the client implement of PANA, interacts with the PAA, as
the server implement of PANA, in the authentication process using the
PANA protocol. PAA consults an Authentication Server (AS) for
authentication and authorization of a PaC. If the AS resides on the
same node as the PAA, an API is sufficient for this interaction.
When the PAA is separated from the AS, a AAA protocol (e.g.,
Diameter) will be used for their communication. The AS is a
conventional backend AAAS that terminates the EAP and the EAP
methods.
A PANA Enforcement Point (EP) allows (blocks) data traffic of an
authorized (unauthorized) PaC. When the PAA and EP reside on the
same node, they use an API for communication; otherwise, a protocol
(e.g., SNMP) is required.
The details of the PANA architecture and operation are specified in
[RFC5191] and [RFC5193].
5. IP Security (IPsec) Architecture
The IP security (IPsec) architecture is designed to provide security
services for traffic at the IP layer. Most of the security services
are provided through use of two traffic security protocols, the
Authentication Header (AH)[RFC4302] and the Encapsulating Security
Payload (ESP)[RFC4303], and through the use of cryptographic key
management procedures and protocols.
A security association (SA) is created in both sender and receiver.
It is a simplex "connection" that affords security services to the
traffic carried by it. The sender and receiver maintain their local
Security Association Database (SAD) to record their SAs.
In the unicast case, the SAs could be dynamically negotiated between
the sender and the receiver using IKEv2 [RFC5996]. In contrast, in
the multicast case, a Group Controller / Key Server (GCKS) is
responsible for distribution of the group SAs (GSA) to all the group
members (GM) in the same group.
The details of the IPsec architecture and its extension for multicast
are specified in [RFC4301] and [RFC5374].
6. MRAC System Operation
The MRAC architecture is composed from individual elements drawn from
the pieces outlined in Sections 3, 4, and 5. In this way, it is
possible to meet the requirments as listed in
[I-D.atwood-mboned-mrac-req].
Atwood, et al. Expires January 5, 2015 [Page 8]
Internet-Draft MRAC Architecture July 2014
6.1. Mapping the Multicast and AAA Architectures to the Network Boxes
In order to meet the requirements in [I-D.atwood-mboned-mrac-req],
all the functional entities that are applied in the multicast
routing, AAA and IPsec architectures are mapped into the participants
in our MRAC architecture as shown in Table 1.
The EU in MRAC system maps the IPv4/IPv6 system in IGMP/MLD, the
receiver in multicast routing protocol, PaC in PANA and EAP peer in
EAP.
The NAS in MRAC system maps the Diameter/RADIUS Client in Diameter/
RADIUS, PAA in PANA and EAP Authenticator in EAP.
The AAAS in MRAC system maps the Diameter/RADIUS Server in Diameter/
RADIUS, EAP backend authenticator server in EAP.
The AR in MRAC system maps the multicast router in IGMP/MLD including
Querier and Non-Querier, the EP in PANA. Moreover, the AR who wins
in DR/GDR election maps the DR/GDR in multicast routing protocol.
The EU and AR also map the GMs in IPsec. It depends on the specific
packet whether the sender is EU or AR. A special AR, called Querier,
may map the GCKS in IPsec.
+--------------------------------------+-----+------+-------+-----+
| Roles | EU | NAS | AAAS | AR |
+--------------------------------------+-----+------+-------+-----+
| IPv4/IPv6 systems in IGMP | x | | | |
| multicast routers in IGMP | | | | x |
| receiver in MRP | x | | | |
| DR/GDR in MRP | | | | x |
| Diameter/RADIUS Client | | x | | |
| Diameter/RADIUS Server | | | x | |
| PaC in PANA | x | | | |
| PAA in PANA | | x | | |
| AS in PANA | | | x | |
| EP in PANA | | | | x |
| EAP peer in EAP | x | | | |
| EAP authenticator in EAP | | x | | |
| backend authentication server in EAP | | | x | |
| GCKS in IPsec | | | | x |
| GM in IPsec | x | | | x |
+--------------------------------------+-----+------+-------+-----+
Table 1: Mapping the Multicast and AAA Architectures to the Network
Boxes
Atwood, et al. Expires January 5, 2015 [Page 9]
Internet-Draft MRAC Architecture July 2014
6.2. EAP Exchanges
The EAP runs between an EU and an NAS, where the NAS can act as a
pass-through, and an AAAS is connected with the NAS. The policy is
used to determine whether actual authentication is performed by the
AAAS or the NAS.
In MRAC, it is recommended that the NAS use EAP-FAST as the EAP
authentication method to authenticate the EU. The EU carries a token
from his/her ticket in the EAP-FAST method. The token includes the
user information and group information that will be used by the NAS
or AAAS to make the authentication and authorization decision about
the EU.
6.3. PANA Exchanges
PANA carries the EAP-FAST method (encapsulated inside EAP packets)
between an EU and an NAS in the access network. An EU may be
configured with an IP address of the NAS as its PAA or dynamically
discover it using the default method of DHCP.
An EU, on receiving a request to join a multicast group while no GSAs
have been established for the group, initiates a PANA exchange with
an NAS as its PAA. During the PANA session, the NAS authenticates
and authorizes the EU. In addition, the re-authentication and re-
authorization may be required if necessary. The NAS would consult
the AAAS to perform the actual authentication if it is a pass-through
in the EAP exchange. The communication between NAS and AAAS is
implemented by Diameter/RADIUS exchanges explained in the next
subsection. Moreover, the NAS updates the filter state of the EU
according to the authorization result and provides the authorization
result and authorization attributes (mainly referring to a key
derived from the EAP-FAST method) to the AR(s) connected directly to
the EU.
6.4. Diameter/RADIUS Exchanges
When the NAS is a pass-through, the Diameter / RADIUS exchanges are
used between NAS and AAAS to carry information related to
authentication, authorization, and accounting.
In the Diameter / RADIUS exchanges, the NAS is responsible for
passing the EAP-FAST method (carrying the token of the EU's ticket)
to the AAAS, and then acting on the response that is returned. The
AAAS is responsible for authenticating and authorizing the EU, and
then returning the result and attributes (mainly including a key
derived from the EAP-FAST method) for the EU to the NAS.
Atwood, et al. Expires January 5, 2015 [Page 10]
Internet-Draft MRAC Architecture July 2014
6.5. IPsec Exchanges
IPsec is used to enforce the receiver access control at the network
level. A protocol is needed to create IPsec GSAs and then distribute
them to authorized EUs and their ARs dynamically. The protocol may
be very similar to the two existing IETF protocols, GDOI [RFC6407]
and G-IKEv2 [I-D.yeung-g-ikev2]. In MRAC, the Querier will become
the GCKS in the network segment. The authorized EUs and the other
ARs interact with their Querier. The Querier is responsible for
checking the authorized attributes of the EUs. Then the Querier
creates and distributes IPsec GSAs to the EUs and their ARs in the
same network segment.
However, the two existing IETF protocols (GDOI and G-IKEv2) do not
satisfy all the requirements for IPsec GSA creation and distribution
in MRAC. A new protocol has been drafted for use by MRAC.
6.6. IGMP/MLD Exchanges
IGMP/MLD is running among the EUs and their ARs. According to
[RFC3376] and [RFC3810], the EU uses the message of Membership Report
to report the current multicast reception status to its ARs. The
specific AR, called Querier, uses the message of Membership Query to
query the multicast reception status of its EUs.
However, in order to enforce the receiver access control at the
network level, the ARs and the EUs would filter out the received
Membership Report and Membership Query messages using their local
IPsec systems. The message of Membership Report that reports the
reception status of the subscribed group would be protected by IPsec
GSAs whose source address is the EU's address and whose destination
address is the address of the reported subscribed group. Also, the
Membership Query message that queries the reception status of the
subscribed group would be protected by IPsec GSAs whose source
address is the Querier's address and whose destination address is the
address of the queried subscribed group.
In order to utilize the IPsec system, IGMP and MLD must be extended.
However, the extension will be very small.
7. Security Considerations
TBD
Atwood, et al. Expires January 5, 2015 [Page 11]
Internet-Draft MRAC Architecture July 2014
8. IANA Considerations
This draft has no actions for IANA
9. Acknowledgements
10. References
10.1. Normative References
[I-D.atwood-mboned-mrac-req]
william.atwood@concordia.ca, w., Islam, S., and B. Li,
"Requirements for IP Multicast Receiver Access Control",
draft-atwood-mboned-mrac-req-00 (work in progress),
October 2013.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
[RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and
A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA) Framework", RFC 5193, May 2008.
Atwood, et al. Expires January 5, 2015 [Page 12]
Internet-Draft MRAC Architecture July 2014
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, November 2008.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
10.2. Informative References
[I-D.yeung-g-ikev2]
Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key
Management using IKEv2", draft-yeung-g-ikev2-07 (work in
progress), November 2013.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, October 2011.
Authors' Addresses
William Atwood
Concordia University/CSE
1455 de Maisonneuve Blvd, West
Montreal, QC H3G 1M8
Canada
Phone: +1(514)848-2424 ext3046
Email: william.atwood@concordia.ca
URI: http://users.encs.concordia.ca/~bill
Bing Li
Concordia University/CSE
1455 de Maisonneuve Blvd, West
Montreal, QC H3G 1M8
Canada
Email: leebingice@gmail.com
Atwood, et al. Expires January 5, 2015 [Page 13]
Internet-Draft MRAC Architecture July 2014
Salekul Islam
United International University/CSE
House 80, Road 8/A, Mirza Golam Hafiz Road
Dhanmondi, Dhaka 1209
Bangladesh
Email: salekul@cse.uiu.ac.bd
Atwood, et al. Expires January 5, 2015 [Page 14]
