An AAA Framework for IP Multicast Communication in Next Generation Networks

Introduction

When an end user wants to access multicast content, he or she needs to send an Internet Group Management Protocol (IGMP) (Cain, 2002) Join message to its next hop router. Upon receiving the request, this router uses a multicast protocol such as Protocol Independent Multicast (PIM) (Estrin, 1998) for setting up a distribution tree so that the multicast data can be routed from the source to the receiver. As stated by Cain (2002), joining a multicast group is an “unprivileged operation”, or in other words, in standard multicast operation, any end user (i.e. host device) is allowed to join any multicast group and gain access to multicast traffic without authentication. This implies that there is not a single mechanism defined to restrict access of the multicast traffic only to an authenticated and authorised set of users, or to inhibit un-authenticated users gaining access to multicast traffic, which are meant only for a specific user group. Hence NPs cannot limit or control the access to the multicast content making it impossible to account the users for their multicast service usages. In addition, these protocols do not enable the sender i.e. the Content Provider (CP) to know who is accessing the multicast data at any given time. Hence the sender cannot account users for the multicast usage, leading to an unclear business model for both the NP and the CP (Savola, 2005).

The traditional method of providing any form of accounting for multicast services is to associate it with security. In this mechanism, the multicast content is encrypted by the CP before transmission and the users who require access to this content have to request the security keys from the CP to decrypt the transmitted content. The CP may then charge these users to disclose the security keys to them. Though this provides a simple method in which the CP may charge users accessing the multicast content, it is merely a method to charge users once for providing the keys. This method does not provide the flexibility offered by standard Authentication, Authorisation and Accounting (AAA) protocols to allow access control by the NP, nor does it provide time and/or volume based pre-paid and post-paid charging. The Group Security Association and Key Management Protocol (GSAKMP) (Harney, 2006) and the Group Domain of Interpretation (GDOI) (Baugher, 2003) multicast security protocols based on the multicast security architecture (Baugher, 2005) defined by Internet Engineering Task Force (IETF) Multicast Security (MSEC) working group also use this traditional method for securing the multicast traffic. The biggest drawback with such a mechanism is that only the CP has the ability to control and charge the users. In a distributed architecture, the NP to which the user may be connected, has no control on the multicast usage and hence cannot charge the user for their network usage, making IP multicast service provision unattractive to the NP for commercial deployment. Since the NP has no control, a malicious user may send an IGMP Join message to join any multicast group with the intention to launch a Denial-of-Service attack.