See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221081649

The Internet Group Management Protocol with Access Control (IGMP-AC)

Conference Paper · November 2006

DOI: 10.1109/LCN.2006.322142 · Source: DBLP

CITATIONS READS
17 1,147

2 authors:

Salekul Islam John William Atwood

United International University Concordia University Montreal
67 PUBLICATIONS   382 CITATIONS    108 PUBLICATIONS   714 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Research of the flow-based model of hierarchical multicast routing View project

Security Protocol Analysis View project

All content following this page was uploaded by Salekul Islam on 29 January 2015.

The user has requested enhancement of the downloaded file.

 The Internet Group Management Protocol with Access Control (IGMP-AC)

Salekul Islam and J. Willam Atwood

Concordia University
Department of Computer Science and Software Engineering
Montreal, Quebec, Canada
{salek is, bill}@cse.concordia.ca

Abstract able to take the advantages of multicasting, its commer-

cial deployment is still facing obstacles due to various se-
IP Multicast is best known for its bandwidth con- curity measures. Both the Content Providers (CP) and the
servation and lower resource utilization. The classical Network Service Providers (NSP) can generate significant
model of multicast makes it difficult to permit access amounts of revenue by deploying multicast if there is a
only to authorized end users or paying customers. A mechanism for streaming revenue from the end users or
scalable, distributed and secure architecture is needed the receivers of the delivered content. To ensure revenue
where authorized end users can be authenticated before collection from the end users, we have to identify the end
delivering any data or content. In (unsecure) multicast, users and to keep a record of the content used by them.
an end user or host informs the multicast edge-router of The source of the content (the CP) should not be concerned
its interest in receiving multicast traffic using the Internet about enforcing the requirement that only the authenticated
Group Management Protocol (IGMP). To carry the end and the authorized end users are receiving the services. The
user authentication data, we have extended the IGMPv3 CP should out-source the task and delegate the NSP to per-
protocol, and called our new version the Internet Group form Authentication, Authorization and Accounting (AAA)
Management Protocol with Access Control (IGMP-AC). functionalities [19]. The generated revenue should be di-
New messages and reception states have been added to vided between the parties: the CP and the NSP. To achieve
IGMPv3, and the AAA framework is used for end user these complex tasks we have to discard the classical “any-
authentication, authorization and accounting purposes. one can send any one receive” multicast model where the
IGMP-AC is presented using state diagrams of the entities receivers remain anonymous throughout the group activity
that are involved. The proposed protocol has been modeled period. We need an architecture that will add AAA func-
in PROMELA, and has also been verified using SPIN. tionalities to the present multicast model.
A framework has been developed in [14], where the near-
Keywords— Multicasting; Internet Group Management est Access Router (AR) of an end user will perform the
Protocol (IGMP); Access control; Authentication, Autho- AAA client behaviors. The end user (receiver) or host in-
rization and Accounting (AAA) forms the AR of its interest in receiving multicast traffic
destined to a particular group using the IGMP [3] (MLD
[25] in case of IPv6). However, the present IGMP/MLD
1. Introduction Join message does not carry the identity of the user or
the host. The IGMPv3 supports “source filtering” through
IP multicast was standardized by the IETF in RFC 1112 which a system can request to receive multicast packets
[5]. It is an efficient technology to deliver data to many only from a specific list of sources, or from all but specific
recipients who may be geographically scattered. For each sources, sent to a particular multicast group. In this paper,
recipient, multicast replicates data at a point as close to we have presented the Internet Group Management Proto-
that recipient as possible. Thus, it is considered as a band- col with Access Control (IGMP-AC), a modified version of
width conservation technique with respect to unicast, es- the IGMPv3, which deploys one of the AAA protocols for
pecially when there are many recipients and large amounts end user authentication and authorization.
of data (e.g., streaming video) are being sent. Though dif- The rest of the paper is organized as follows: section 2
ferent types of applications including video-conferencing, will discuss briefly some of the existing methods, section 3
distance learning, software updates, stock quotes, etc. are will explain all the details of the IGMP-AC. In section 4, the

1-4244-0419-3/06/$20.00 ©2006 IEEE 475

use of Extensible Authentication Protocol (EAP) [2] to sup- CP
port flexible authentication has been introduced. The next
section will discuss different issues related to policy frame- CS

work of AAA Server (AAAS). We have also modeled the

IGMP-AC in PROMELA [12] and verified the model using
SPIN [11]. The model and the verification results have been AR

presented in section 6. Finally, section 7 will be the conclu-

sion and the work that we have planned to accomplish in the
future. AAAS
CR
CR
2. Related work
NAS
AAA issues are not addressed well in IP multicast by AR
the researchers. We have found only a few attempts that
meet our requirements. Among these, the End User Identi-
fication and Accounting (EUIA) [24] system deploys AAA
Host 1 Host 2 Host 3
protocols for user authentication, accounting and host iden-
tification. The Internet Group Membership Authentication
Protocol (IGAP) [9] provides IGMPv2 functionalities with Figure 1. The IGMP-AC protocol architecture
the addition of user authentication and accounting. It suffers
from a serious threat due to its use of a plaintext password.
A multicast architecture has been presented in [10], where a 1. The end user authentication process should support all
centralized Multicast Manager (MM) has been introduced. sorts of authentication — from simple password based
The “source filtering” option in the IGMPv3 has been used authentication to complex certificate based authentica-
to control the access of the receivers. An architecture that tion.
uses CHAP and deploys RADIUS [22] has been proposed in 2. The IGMP version 3 is the current standard designed
[13] to authenticate both the receiver and the sender. Here, by the IETF. The modification will be based on the
we have only mentioned the methods that are similar to our IGMPv3 and must support the “source filtering” prop-
research direction. A summary of the different approaches erty as well.
regarding AAA issues is presented in [14]. A complete list 3. The IGMP-AC will not disrupt the usual function of
of receiver and sender access control mechanisms, and their the IGMPv3 and end user access control must be per-
comparisons can be found in [16, 15]. formed only if required.
4. The least functionality and minimal workload should
be added to the ARs and the hosts.
3. IGMP with Access Control (IGMP-AC) 5. Authentication is a costly process in terms of CPU cy-
cles and bandwidth. Therefore, an end user should
The Internet Group Management Protocol with Access send the authentication information to the AR as few
Control (IGMP-AC) will perform access control of the end times as possible.
users (only if required for a specific application) in addi-
tion to the IGMPv3 functionalities. The architecture of the
IGMP-AC has been presented in Figure 1. Here, “access 3.2. Assumptions
control” is used to address all the AAA functionalities: to
authenticate successfully, to verify authorization to receive It is important to clarify when the IGMP-AC protocol
group data for which IGMP-AC join message has been sent, will anticipate access control. We have assumed two types
and also to keep accounting information for each end user. of multicast groups: Open Group, to/from which a host can
In the following subsections the rationale behind the archi- join/leave any time by sending regular IGMPv3 messages,
tecture, different participats and their roles, the messages of and Secured Group, where access control mechanism of the
the protocol, and required reception states will be explained. IGMP-AC will take place to join/leave to/from the group.
While the IGMP-AC supports “source filtering” we have to
3.1. Essential properties extend the definition of Secured Group, which may be ei-
ther Group-Specific, (*, G) or Group-and-Source-Specific,
The following essential properties have been identified in (S*, G). Here, “*” by itself means absence of any specific
[14] for the modification of the IGMPv3 protocol to perform multicast source address and “S*” means one or more mul-
access control of end users: ticast source addresses.

476
 The AAA protocols (e.g., RADIUS [22]) have been de- each other using the IGMP-AC while the AR/NAS and the
signed to control access to network resources, and are being AAAS use one of the AAA protocols. From this point,
used very successfully. Use of the AAA protocols in access whenever we use the term “AR” it will indicate both the
control of content or service should be similar to access con- AR and the NAS. In this secton, we explain the IGMP-AC
trol of network resources. The only difference is instead of protocol by using flow charts. For each entity (i.e., host,
dealing with physical resources, we are dealing with data AR and AAAS), one flow chart has been drawn and that
or packets of a network. It is assumed that the AAAS must will explain the state diagram of the corresponding entity.
be updated about the Secured Groups and end users authen- In the flow charts, two-dimensional labeled arrows are used
tication information before it receives a request for the to represent sending or receiving of messages to or from the
status of a specific group or to authenticate an end user. entity labeled inside the arrow. An incoming arrow repre-
In RFC 3376 [3], IPSec [18] in Authentication Header sents receiving of a message and an outgoing arrow repre-
mode [17] has been suggested for use to provide connec- sents sending of a message. We have adopted the phrase
tionless integrity, data origin authentication and replay pro- g or gs to indicate Group-Specific or Group-and-Source-
tection for the IGMPv3 messages. Thus, an AR will be Specific. Thus, query(g or gs) is to mean that this
certain that IGMPv3 messages are coming from a system is either a Group-Specific Query or a Group-and-Source-
(or, more specifically, a system with the proper key) on the Specific Query. The circular state, labeled as “S”, stands
LAN to which the AR is directly connected. Two types for the “Start” state. Thus an arrow towards “S” means it is
of key management are possible, a symmetric signature al- going to the “Start” state.
gorithm with a single key for the LAN or an asymmetric
signature algorithm, where a sender can be authenticated Start
individually. We are adopting the same concept of using
IPSec in Authentication Header mode for the messages of
the IGMP-AC protocol. API
join (g_or_gs,
API
leave
AR
query
id, pwd) (g_or_gs) (g_or_gs)
Finally, it is assumed that one of the multicast group key
management protocols (e.g., SIM-KM [20]) is deployed to
report (add, report (del, report
protect multicast data from unauthorized users. g_or_gs )
AR
g_or_gs )
AR
(current, AR
g_or_gs)

3.3. Participants and their roles

AR auquery S
(g_or_gs, )
There are five participants in the IGMP-AC architecture:
CP, Core Routers (CR), ARs, End Users (EU) and AAAS. areport (rstate, AR
g_or_gs, id, pwd)
The Network Access Servers (NAS) or the AAA client will
reside inside the AR.
AR aresult (g_or_gs,
The CP will deliver service or data packets through the id, result )
Content Server (CS). It will send multicast packets to the
nearest AR, and the AR will forward the packets through no result? yes
the multicast data distribution tree, which has already been
del rstate? add
constructed by the CRs. S

The AR that is directly connected to the subnet of the end del (g_or_gs, add (g_or_gs,
users will perform two tasks: it will receive and process the id, pwd ) id, pwd )

IGMP messages and will act as a NAS by communicating

with the AAAS. If an end user has to be authenticated, the S S

AR/NAS will collect this authentication information from

the IGMP Join message and forwards a request to the Figure 2. State diagram for host
AAAS. The AAAS will verify this information and send the
answer to the NAS. When an end user leaves a multicast The state diagram for a host that communicates with an
group, its group activity will be sent to the AAAS inside an AR using the IGMP-AC is shown in Figure 2. Here, API
account message. means Application Program Interface or any upper layer
protocol interface. The leave and the join messages
3.4. Protocol description are not part of the IGMP-AC protocol, they are used to ex-
press that one of the applications, running in the host is in-
The architecture in Figure 1 has three entities: hosts, terested to join or leave a multicast group. The filter mode
AR/NAS and AAAS. A host and the AR communicate with (rstate) of the reception states that a host maintains, may

477
have any of the three values: add, del or current. Start

When a host receives a join message, it creates a new

reception state and assigns the filter mode with the value
add. When it receives a leave message for a g or gs, querytimer H report (rstate,
(g_or_gs) expires g_or_gs)
the filter mode is changed from current to del. The
filter mode is assigned with the value current for the pe- del (g_or_gs, id) g is in
riod of time the host maintains membership for a group. no
database?
In Figure 2, query and report messages are standard S
request
IGMPv3 messages; auquery, areport and aresult (g_or_gs)
AAAS
yes
have been created for the IGMP-AC protocol. In this dia-
gram, a simple password based authentication mechanism is
illustrated. In section 4, we have explained how this mech- answer answer
AAAS AAAS
anism can be extended for advanced authentication mech- (open) (secured)

anisms (e.g., CHAP, certificate, etc.) where more than one Do nothing,
round-trip may be required for a successful authentication. IGMPv3 will be used
current rstate?
add/del
To minimize the number of times authentication data has to S
be sent by the host, only in response to an auquery, the
host will send an areport to the AR carrying the iden- refresh (g_or_gs) auquery (g_or_gs) H
tity and the password of the end user. The AR will inform
the host of the result of the authentication process by reset querytimer
H
areport (rstate,
(g_or_gs) g_or_gs, id, pwd)
sending an aresult message. On successful authentica-
tion, if the value of rstate was add, the host will add a request (g_or_gs,
S AAAS
new reception state for (g or gs, id, pwd) by chang- id, pwd)

ing the filter mode from add to current. If the value of

rstate was del, the host will delete the reception state
answer answer
(g or gs, id, pwd) for which the filter mode was as- AAAS AAAS
(yes, time) (no)
signed del before.
aresult (g_or_gs, aresult (g_or_gs,
H H
id, yes) id, no)
Start

add rstate? S
del

request request (g_or_gs, account add (g_or_gs, id) del (g_or_gs, id)
AR AR
(g_or_gs) id, pwd) AR (g_or_gs,
id, data)
S account (g_or_gs, id, data) AAAS
secured? valid?
yes update
yes
(id, data) query (g_or_gs) H
no no
answer answer
AR AR
(secured) (yes, time)
set querytimer (g_or_gs)
S

answer answer S
S AR S AR
(open) (no)

Figure 4. State diagram for Access Router

S S

Figure 3. State diagram for AAA Server defining new Attribute Value Pairs (AVP). (All data are
delivered by Diameter in the form of AVPs.) There are
The state diagram for the AAAS that communicates with two types of request messages: one for the status of a
the AR using one of the AAA protocols is presented in Fig- group and the other for a specific end user. By sending a
ure 3. We have assumed that, request, answer and request(g or gs), the AR wants to know if the type
account are messages of the Diameter [4] protocol. The of the group for g or gs is Secured or Open. The pur-
constructions of these messages are out of the scope of pose of sending a request(g or gs, id, pwd) is to
this paper and are included in our future study. We men- verify the identity and the password of the end user and
tion that it is possible to extend the Diameter protocol by also if he/she is authorized to join the group g or gs. In

478
response to request, the AAAS will send an answer. destination address of 224.0.0.1, the all-system multi-
If the end user is successfully authenticated and also au- cast address. A Group-Specific or Group-and-Source-
thorized for the group g or gs, the AAAS will send an Specific Query is sent with an IP destination address
answer(yes, time) where time is to indicate the pe- equal to the multicast address of interest. An Authen-
riod of time up to which the end user is allowed to re- tication Unicast Query, denoted as auquery in the
ceive data for the multicast group g or gs. The AAAS diagrams, is sent with a unicast destination address.
will update its database indexed by (g or gs, id) on Whenever the AR receives a report from a host with
receiving an account message. This database can be ac- the value of filter mode as either add or del, the
cessed later by the CP as described in [14]. AR gets the IP address of the host from that report,
The state diagram for the AR has been presented in Fig- and uses that IP address as the IP destination address
ure 4. We have already explained all the messages of this of the auquery message. This query is sent with
diagram. We have summarized the functionalities of the AR g or gs, hence it has either Group-Specific or Group-
in the following: and-Source-Specific type.
• The AR will maintain a list of Secured groups of 2. Authentication Report– In the above diagrams, Au-
type g or gs and whenever a report with a new thentication Report is presented by areport. It car-
g or gs is received, it will request the AAAS to ries end user authetication information. This report
inform about it. If this is an Open group, the IGMPv3 is sent by a host in response to auquery only. An
protocol will be followed, otherwise, the group will be areport contains the end user’s reception state fil-
added to the list. ter mode, identity and password. When any other au-
• If the AR receives a report with the reception state’s thentication mechanism is used it will carry the corre-
filter mode as current, it will refresh the reception sponding authentication information. This issue will
state and reset the timer, querytimer for that group be discussed in detail in the next section.
only. No authentication information will be exchanged 3. Authentication Result– The AR forwards authentica-
at that time. tion information of the end user to the AAAS and gets
• The AR will send an auquery if it receives a back the result from the AAAS. This result is relayed
report with the reception state’s filter mode as ei- to the host by an Authentication Result or aresult
ther add or del. Thus, authentication is only neces- message. It consists of (g or gs, id, result),
sary during joining or leaving of an end user. where result is a flag (value of yes/no) type data.
• The actual authentication will be performed by
the AAAS, the AR receives authentication informa- 3.6. Required reception states
tion (here, user identity and password) through the
areport message, extracts this information and for- To operate the IGMP-AC successfully a set of extra re-
wards it to the AAAS by sending a request mes- ception states should be maintained by the AR and the hosts
sage. in addition to the IGMP reception states. The AR and the
• If the authentication is successful and the filter mode hosts will have to maintain different sets of reception states.
was add the AR will add a new reception state for A host will be informed through the Application Pro-
(g or gs, id). gram Interface (API) or upper-layer protocol interface that
• For successful authentication, with filter mode value as it should perform a join operation to a multicast group.
del, an account message will be sent to the AAAS The host will be able to differentiate between an Open
and an IGMPv3 query will be sent to all the hosts Group and a Secured Group by checking the information
inside the subnet. A timer named querytimer for received from the API or upper-layer protocol interface as
the group g or gs will be set. some authentication information must be present for a Se-
• In case the querytimer for the group g or gs cured group. If it is an Open Group the host will follow the
is expired, all the entries with g or gs in reception IGMPv3 standard [3]. In case of a Secured Group, the host
states will be deleted. will have to maintain
(group address, source address,
3.5. Additional messages identity of end user, authentication
information, filter mode).
The IGMP-AC has added three messages to the existing
For Group-Specific membership the source address
ones of the IGMP protocol.
field will be empty and for Group-and-Source-Specific
1. Authentication Unicast Query– In IGMPv3, all types membership this field will contain one or more source ad-
of query messages are sent with an IP multicast des- dress(es). The filter mode will be any value of add,
tination address. A General Query is sent with an IP del or current.

479
 The AR always maintains a list of multicast groups of an end user is using.
g or gs format. Whenever a report with unknown
group (which is not present in the existing group list) ar- Next, we present an authentication framework, the Ex-
rives, the AR will communicate with the AAAS to update tensible Authentication Protocol [2] that can be deployed
its list. This list is very simple and consists of with the IGMP-AC protocol to facilitate the authentication
process by adding flexibility.
(group address, source address, status).
Here, the group address and the source address 4.1. Extensible Authentication Protocol
are same as for the reception states of a host, and the
status is either Open or Secured.
AAA
The AR should collect accounting information for each End
NAS Server
User
end user and when an end user leaves a multicast group, (initiate Eap)
the AR should forward accounting information to the
EAP Request #1 (Identity)
AAAS by sending an account message. Moreover, for
EAP Response #1 (Identity)
each successful authentication, the AAAS will send the
Diameter-EAP-Request
authorization information to the AR. In Figure 3 EAP-Payload (EAP Response #1)
and 4, this authorization information is the du- Diameter-EAP-Answer
EAP-Payload (EAP Request #2)
ration of time up to which point the end user is authorized
EAP Request #2
to receive multicast group data. Though, it can be any thing
depending on a specific application. It is to be noted that
the AR will never maintain authentication information of
EAP Response #N
an end user. To meet all these requirements the AR should
Diameter-EAP-Request
maintain the reception states of EAP-Payload (EAP Response #N)

Diameter-EAP-Answer
(group address, source address, EAP-Payload (EAP Success)
(authorization AVPs)
identity of end user, authorization EAP Success
information, accounting information,
filter mode).
Figure 5. EAP and Diameter messages

4. Authentication protocol The Extensible Authentication Protocol (EAP) supports

multiple authentication mechanisms. It has been used be-
We have presented the basic and simplest authentication tween a host and a router connected via switched circuit
scheme, password based authentication in the previous sec- or dial-up line that uses PPP [23]. It has also been used
tion. Our goal is to develop a framework that will be much between a switch and an access point that uses IEEE 802
more flexible to support all types of authentication methods. [1]. The EAP runs between an authenticator and a peer,
Authentication is not free of cost and is not even required where the authenticator can act as a pass-through, and a
for every application. Most of the time, when we expect backend authentication server (or EAP server) may be con-
a revenue stream from the end users, we need authentica- nected with the authenticator. The actual authentication will
tion. In some cases, in a closed environment, for example, be performed by the backend server. The pass-through au-
a videoconference among the policy makers of a giant com- thenticator is nothing but a NAS and the backend server is
pany, authentication is required. However, the framework an AAAS. In such an environment, the EAP will be used by
we want to develop must support a large variety of authen- the end user (host) and the NAS, and one of the AAA pro-
tication schemes. Some of the key factors that dominate to tocols will be used by the NAS and the AAAS. The EAP
decide the preferable authentication scheme are: packets that arrive at the NAS are sent to the AAAS by en-
capsulating them inside the AAA packets, and the NAS will
1. The specific application using IP multicast to deliver decapsulate the AAA packets received from the AAAS and
data to the end users. forward the EAP packets to the end user. The Diameter
2. The value of the information we want to distribute EAP application that carries the EAP packets inside the Di-
among the end users. It may be valuable in terms of ameter packets between a NAS (EAP authenticator) and an
revenue (e.g., pay-per-view) or sensitive information AAAS (backend authentication server) is already standard-
(e.g., company secret, military intelligence). ized by the IETF in RFC 4072 [7].
3. The resources of the network, including AAAS, ARs There are four types of EAP messages: Request, Re-
and the links among these entities. sponse, Success and Failure. The Request is always sent
4. The hardware and software resources of the machine by the authenticator to the peer, and the peer replies to it

480
by sending a Response to the authenticator. The sequence dard policy for the AAA protocols. Three areas have been
of different messages between the NAS and the end user, identified for the multicast security policy in the multicast
and between the NAS and the AAAS is shown in Figure 5. group security architecture: policy creation, high-level pol-
The EAP Request and Response messages are sent inside icy translation, and policy representation [8]. To develop
the Diameter messages. Depending on the authentication a policy framework, we have to deal with the AAA pol-
method used, more than one round-trip may be required. In icy as well as with the multicast security policy. The IETF
this scenario, after N round-trips, the AAAS authenticates has standardized the Common Open Policy Service (COPS)
the end user and sends an EAP Success message inside an protocol [6], a simple query and response protocol that can
EAP-Payload. If authorization is requested appropriate au- be used to exchange policy information between a policy
thorization AVPs are sent also. server (Policy Decision Point or PDP) and its clients (Pol-
icy Enforcement Points or PEPs). In the IGMP-AC archi-
4.2. Use of EAP in IGMP-AC tecture, the AAAS will be the Policy Decision Point and
the NAS will be Policy Enforcement Points. Another way
to represent the policy in the IGMP-AC architecture is to
use the Extensible Markup Language (XML), one such rep-
End NAS
User resentation for secure multicast can be found in [21].
auquery (EAP Request #1 (Identity))
6. Verification using SPIN
areport (EAP Response #1 (Identity))

auquery (EAP Request #2) We have used the formal verification language,
PROMELA (PROcess MEta LAnguage) [12] to specify
the verification model, and used the tool, SPIN (Simple
areport (EAP Response #N) PROMELA INterpreter) [11], to verify our model. SPIN
aresult (EAP Success)
is a generic verification system, which can simulate the ex-
ecution of a verification model by interpreting PROMELA
statements on the fly. It can detect many types of logical
design error in distributed systems and it checks the logi-
Figure 6. EAP inside IGMP-AC protocol cal consistency of a specification. It reports on deadlock,
livelock and improper termination.
The EAP framework exactly resembles the IGMP-AC ar-
chitecture when the authenticator acts as pass-through. The 6.1. Description of the model
AR/NAS in Figure 1 can perform the tasks of the pass-
through authenticator, the AAAS will act as backend server, We have developed the PROMELA model from the state
and the Diameter protocol [4, 7] must be used for the com- diagrams of the IGMP-AC protocol presented in section 3.
munication of the AR (NAS) and the AAAS. The only dis- We have designed the model in such a way that it is as sim-
crepancy we have to solve is in the IGMP-AC, a host com- ple as possible, but at the same time, it satisfies all the states
municates with the AR (NAS) using the IGMP-AC proto- and transitions of the diagrams. Our model consists of three
col, whereas in the EAP framework, a host communicates processes: host for a host, ar for the AR and aaas for
with the NAS using the EAP protocol. We are not present- the AAAS. Before the starting of the processes, aaas is
ing the solution of this problem in detail. One possible so- initialized with the AAAS database, which consists of the
lution is to send the EAP packets inside the IGMP-AC mes- membership information (e.g., group and source addresses,
sages. In Figure 6, the sequence of the messages is shown, user id and password, etc.). At the beginning, the reception
where an EAP Request is encapsulated inside an auquery state of ar is empty. We have invoked multiple instances of
message, and an EAP Response is encapsulated inside an host, through which end users can join/leave dynamically
areport message. An EAP Success or Failure is encap- to/from different multicast groups. In the runtime, the ar
sulated inside an aresult message. For N round-trips of will buildup its reception states according to the behavior of
the EAP messages, N pairs of (auquery, areport) mes- the hosts.
sages will be exchanged.
6.2. Verification results
5. Policy framework for AAAS
SPIN can be used for either simulation or verification.
The multicast security policy is still an open issue for Once we are sure that our model is free from syntax er-
the research community. Even to date, there is no stan- ror, different random simulation runs are performed with

481
 various SPIN options, and no errors were reported by the [5] S. Deering. Host Extensions for IP Multicasting, RFC 1112,
simulator. These simulation runs are not intended to mea- August, 1989.
sure performance, but rather to build our confidence that our [6] D. Durham, et al. COPS (Common Open Policy Service)
model is behaving as expected. Protocol. RFC 2748, January 2000.
[7] P. Eronen, et al. Diameter Extensible Authentication Proto-
The verifier is compiled several times with different
col (EAP) Application. RFC 4072, August 2005.
search techniques: exhaustive or full state exploration, par- [8] T. Hardjono and B. Weis. The Multicast Group Security
tial order reduction, depth-first and breadth-first search. Architecture. RFC 3740, March 2004.
When the verifier is executed it looks for different errors [9] T. Hayashi, et al. Internet Group membership Authentica-
such as assertion violation, invalid end state, non-progress tion Protocol (IGAP). Internet Draft, work in progress.
cycles and never claim. In different verification runs, it goes [10] B. Hilt and J. Pansiot. Using IGMPv3 to manage multicast
up to the depth of 642 levels, generates from 70 to 200 thou- access. 4th Conference on Security and Network Architec-
sand states and uses 225 to 634 Mbytes of memory while tures, Batz sur Mer, France, June 2005.
searching for an error. [11] G. J. Holzmann. The Model Checker SPIN. IEEE Transac-
tions on Software Engineering, 23(5):279–295, May 1997.
The outputs confirm that our model is free from any type
[12] G. J. Holzmann. The SPIN Model Checker. Addison-Wesley,
of error. From the outputs, it is also established that there September 2003.
is no unreachable state in our design. The working of the [13] N. Ishikawa, et al. An Architecture for User Authentication
ar, the aaas and the host processes are observed and are of IP Multicast and Its Implementation. IEEE/APAN Internet
found to function as expected. Workshop, Japan, February 1999.
[14] S. Islam and J. William Atwood. A Framework to Add AAA
Functionalities in IP Multicast. Proceedings of the Advanced
7. Conclusion and future work International Conference on Telecommunications, Guade-
loupe, French Caribbean, February 2006.
We are not very far from the deployment of IP multicast [15] P. Judge and M. Ammar. Security Issues and Solutions in
to deliver content to the end users on a commercial basis. Multicast Content Distribution: A Survey. IEEE Network,
The IGMP-AC protocol will take the whole process one 17(1):30–36, January/February 2003.
step forward. It will add minimum workload to the ARs [16] M. Kellil, et al. Multicast Receiver and Sender Access Con-
without interfering the usual operation of the IGMPv3. At trol and Its Applicability to Mobile IP Environments: A Sur-
the same time, if the EAP is used, it will provide a flexible vey. IEEE Communications Surveys and Tutorials, 7(2):46–
70, 2005.
authentication framework.
[17] S. Kent and R. Atkinson. IP Authentication Header. RFC
In future, we have to develop the incorporation of the 4302, December 2005.
EAP protocol with the IGMP-AC protocol. Moreover, a [18] S. Kent and K. Seo. Security Architecture for the Internet
policy framework of the AAAS for the IGMP-AC architec- Protocol. RFC 4301, December 2005.
ture must be developed. [19] C. Metz. AAA Protocols: Authentication, Authorization,
and Accounting for the Internet. IEEE Internet Computing,
3(6):75–79, December 1999.
8. Acknowledgements [20] R. Mukherjee and J. William Atwood. SIM-KM: Scalable
Infrastructure for Multicast Key Management. Proceedings
J.W. Atwood acknowledges the support of the Natural of Local Computer Networks, November 2004.
Sciences and Engineering Research Council of Canada, [21] R. Mukherjee and J. William Atwood. XML Policy Rep-
through its Discovery Grants program. resentation for Secure Multicast. Proceedings of the IEEE
S. Islam acknowledges the support of Quebec Govern- SoutheastCon 2005 Conference, Fort Lauderdale, FL, April
ment through its FQRNT scholarship program and of Con- 2005.
[22] C. Rigney, et al. Remote Authentication Dial In User Ser-
cordia University.
vice (RADIUS). RFC 2865, June 2000.
[23] W. Simpson. The Point-to-Point Protocol (PPP). RFC 1661,
References July 1994.
[24] N. Sultana and J. William Atwood. Secure Multicast Com-
[1] Local and Metropolitan Area Networks: Overview and Ar- munication: End User Identification and Accounting. Pro-
chitecture. Institute of Electrical and Electronics Engineers, ceedings of the IEEE Canadian Conference on Electrical
IEEE Standard 802, 1990. and Computer Engineering, Saskatoon, SK, May 2005.
[2] B. Aboba, et al. Extensible Authentication Protocol (EAP). [25] R. Vida, et al. Multicast Listener Discovery Version 2
RFC 3748, June 2004. (MLDv2) for IPv6, RFC 3810, June, 2004.
[3] B. Cain, et al. Internet Group Management Protocol, Ver-
sion 3, RFC 3376, October, 2002.
[4] P. Calhoun, et al. Diameter Base Protocol. RFC 3588, Sep-
tember 2003.

482

View publication stats