participant access control in ip multicasting

Participant Access Control Participant Access Control in IP Multicastingin IP Multicasting

PhD Thesis DefencePhD Thesis Defence

Project HighlightsProject Highlights

16/06/2008 Participant Access Control in IP Multicasting 2

Data Distribution Control

Policy Framework

Inter-domain Access Control Architecture

DiameterAgents

MulticastSA

Mobile Multicast: Receiver Access Control & Secured Handoff

Sender Access Control PANA, IKEv2 and IPsec SA

Receiver Access Control IGMP with Access Control (IGMP-AC)Verification by PROMELA/SPINValidation by AVISPA Access Control Architecture

Access Control: Authentication, Authorization &

Accounting

Participant:Receivers & Sender(s)

Existing Multicast Existing Multicast Service ModelService Model


AR1AR1

AR2AR2

AR3AR3CR3CR3

Sender

ReceiversEUs

Routing ProtocolBuilds DDT

IGMP MessagesEUs Join/Leave

Sends multicast data

Data forwardingusing DDT

CR1CR1

CR2CR2

CR3CR3

DDT: Data Distribution Tree

Existing Multicast Service Existing Multicast Service Model : VulnerabilitiesModel : Vulnerabilities


AR1AR1

AR2AR2

AR3AR3CR3CR3

Sender

ReceiversEUs

CR1CR1

CR2CR2

CR3CR3

AR4AR4

AR1AR1

IGMP Join

Routing Protocol Join

AdversaryReceiver

Forged data

AdversarySender

Multicast-based ApplicationsMulticast-based Applications


Number of Participants

Applications

One-to-many(single sender

multiple receivers)

• Scheduled audio/video distribution• Push media: news headlines, weather updates• File distribution and caching• Announcements: multicast session, key updates• Monitoring: stock prices, sensor equipment

Many-to-many (multiple senders multiple receivers)

• Multimedia conferencing• Synchronized resources• Distance learning with input from receivers• Multi-player games

Many-to-one (multiple senders single receivers)

• Resource discovery• Auctions• Polling

Motivation: Revenue Motivation: Revenue Generation ArchitectureGeneration Architecture

Secure Multicasting Protecting control messages—routing protocol specific Protecting multicast data—encryption and authentication

Securing multicasting only fails to happen in large scale commercial deployment

A revenue generation architecture considers Participant access control—AAA for sender(s) and

receivers Policy enforcement E-commerce communications


Why Access Control?Why Access Control?

Effects of forged IGMP messages Join message pulls distribution tree, may create DoS Leave message prunes distribution tree, prevents

legitimate users from receiving IGMP security—only authenticates IGMP messages

Attacks by a forged sender Replay attack Sender address spoofing attack May create DoS

GKM fails to prevent these attacks


How to deploy access control?How to deploy access control?

Receiver access control for a secured group While joining/leaving Changing reception state at ARs

Sender access control for a secured group Sending data


Coupling access control with IGMP

Per-packet cryptographic protection at AR

Sender Access Control

• AAA for sender(s)• Per-packet protection

Data Distribution Control

• Protects distribution tree from forged sender • Not routing protocol security

Receiver Access Control

• AAA for receivers/EUs

Overview of Our Access Overview of Our Access Control ArchitectureControl Architecture


AR1AR1

AR2AR2

AR3AR3CR3CR3

CR1CR1

CR2CR2

Sender

ReceiversEUs

Access Control and Access Control and Authentication in Unicast Authentication in Unicast Access Control is achieved by AAA framework

RADIUS—with limited functionalities Diameter—next generation AAA protocol

• Extensible• Large AVP• Agent support

For authentication IETF has designed Extensible Authentication Protocol (EAP) Protocol for carrying Authentication for Network

Access (PANA)—EAP lower layer


Authentication, Authorization and Authentication, Authorization and Accounting (AAA) FrameworkAccounting (AAA) Framework


AAA protocol

AAA ServerAuthentication

Authorization

AccountingNASAAA Client

End User

Network

End UserDatabase

Requesting access to network

EU credentials

Accept

Access is granted

NAS: Network Access Server

Extensible Authentication Extensible Authentication Protocol (EAP)Protocol (EAP)


EAP Request1

EAP Response1

EAP Request2

EAP ResponseNDiameter (EAP ResponseN)

Diameter (EAP Success)EAP Success

NAS/ EAP Authenticator

AAA Server EAP Server

EAP Diameter (EAP)

End UserEAP Peer

EAP summary

- Authentication framework

- Multiple authentication

- EAP methods

- Four EAP messages

Request, Response

Success, Failure

(Initiate EAP)

By peer or authenticator

Authenticator to peer

Peer to authenticator

Diameter (EAP Response1)

Diameter (EAP Request2)

Encapsulatedover Diameter

Protocol for carrying Authentication Protocol for carrying Authentication for Network Access (PANA)for Network Access (PANA)


PaC PAA AS

EP SNMP/API

PANA

IKE

PaC : PANA Client AS : Authentication ServerEP : Enforcement Point PAA : PANA Authentication Agent

PANA summary

- Network access protocol

- Works as EAP lower layer

- Four entities: PaC, PAA, AS, EP

Key Challenges for Access Key Challenges for Access Control ArchitectureControl Architecture

The most generic architecture Deployable for multi-domain distributed groups Supports wide range of authentication Independent of routing protocol Supports both ASM and SSM

A scalable solution Minimum workload for on-tree routers and end hosts A distributed solution (e.g., using AAA)

Reuse standard frameworks/protocols Fits easily in the existing Internet service model Will reduce the work of service providers


Out of the scope of the thesis

NAS

NAS

Proposed ArchitectureProposed Architecture


AR1AR1

AR2AR2

AR3AR3CR3CR3

CR1CR1

CR2CR2

Sender

EUs

AAAS

Participants Database &

Policy Server

Updates Registration

GO/MRFI

Diameter

IGMP Carrying EU auth. info

Receiver Access Control: Receiver Access Control: Related WorkRelated Work


Method IGMP version

Authentication

Authorization

Accounting

Remarks

EUIAIGMPv3 Flexible Yes Yes Initial work at HSPL, Concordia.

Does not support EAP-like framework

IGAPIGMPv2 Passwd

CHAPYes Yes Plain text password

Extends IGMPv3

IGMPv3 No specific

No No Not suitable for multiple round-trip- based authentication

IGMPv3 access control

IGMPv3 Using IP address

Source filtering

No Address spoofing attack, no advanced authentication scheme

RADIUS based

IGMPv2 CHAP No No Sender access control also, replay attack.

IGMP key based

IGMPv2 Token di-gital sign

No No Needs GKM protocol, high overhead.

Shared secret

IGMPv3 No No No AR needs shared secret to authenticate, overload for AR.

Based on IGMPv2

Specific authentication

No authorization & accounting

Suffer from common attacks

IGMP Extension: RequirementsIGMP Extension: Requirements

A generic client-server authentication An authentication framework (e.g., EAP) should be deployable Must be based on IGMPv3 and support “source filtering” Works in in parallel with IGMPv3 and Open multicast group Only authenticated/authorized EUs are allowed to modify

IGMP reception states Performs EU authentication as few times as possible Not inclined to a particular business model or to a specific

relation between NSP and CP Not restricted to single domain Reuses standard protocols and framework


NAS

Receiver Access Control Receiver Access Control using IGMP-ACusing IGMP-AC


AR1AR1

AR2AR2

AR3AR3

CR1CR1

CR2CR2

CR3CR3

EUs

Sender

IGMP-AC (EAP)

IGMP with Access Control (IGMP-AC)• Extended version of IGMPv3• Encapsulates EAP packets

• Verification using SPIN• Validation using AVISPA

AAA ServerParticipants Database

Diameter (EAP)

IGMP-AC ProtocolIGMP-AC Protocol

State Diagrams for Host, AR and AAAS Additional messages

Authentication Unicast Query (auquery) Authentication Report(areport) Authentication Result(aresult)

Required reception states Host: (G, S, EU id, authentication info, filter mode) AR: (G, S, EU id, authorization and accounting info,

filter mode)


IGMP-AC Verification by IGMP-AC Verification by PROMELA/SPINPROMELA/SPIN


Verification ResultsVerification Results PROMELA model from the state diagrams Simple model, but satisfies all states/transition of state diagrams First, random simulation runs and no error reported Simulator generates Message Sequence Chart (MSC) Next, SPIN produces the Verifier (C program) from PROMELA

model Different search techniques: Exhaustive, Depth-first, Breadth-

first, Bit-state storage and Hash compact. Search for errors: Assert violation, Invalid end-state, Non-

progress cycle, Never claim and Unreachable state Reaches depth up to > 800 Output confirms free from error, no unreachable state


EAP authEAP auth

End User Authentication using End User Authentication using Extensible Authentication Protocol (EAP)Extensible Authentication Protocol (EAP)


EAP methodEAP method

EAP peerEAP peer

EAP layerEAP layer

IGMP-ACIGMP-AC

Lower layersLower layers

EAP peerEAP peer

IGMP-AC IGMP-AC EAP layerEAP layer

Lower layersLower layers

EAP authEAP auth

EAP layerEAP layer

AAA/IPAAA/IP

EAP methodEAP method

EAP authEAP auth

EAP layerEAP layer

AAA/IPAAA/IP

EU/ Peer

AR/Authenticator/NAS

AAA Server

EAP Encapsulation over IGMP-AC

EAP Method Example EAP Method Example


1. P <- S: EAP-Request/Identity

2. P -> S: EAP-Response/Identity(Id)

3. P <- S: EAP-Req (HDR, SAs, KEs, Ns)

4. P -> S: EAP-Res (HDR, SAp, KEp, Np, [SK{IDp}])

5. P <- S: EAP-Req (HDR, SK{IDs, AUTH})

6. P -> S: EAP-Res (HDR, SK{IDp, AUTH})

7. P <- S: EAP-Success

1. P <- S: EAP-Request/Identity

2. P -> S: EAP-Response/Identity(Id)

3. P <- S: EAP-Req (HDR, SAs, KEs, Ns)

4. P -> S: EAP-Res (HDR, SAp, KEp, Np, [SK{IDp}])

5. P <- S: EAP-Req (HDR, SK{IDs, AUTH})

6. P -> S: EAP-Res (HDR, SK{IDp, AUTH})

7. P <- S: EAP-Success

EAP Internet Key Exchange (EAP-IKEv2) MethodEAP Internet Key Exchange (EAP-IKEv2) Method

P : Peer/EU N : Nonce HDR : HeaderS : Server/AAAS ID : Identity SA : Cryptographic AlgorithmKE : Deffie-Hellman component AUTH : Authentication payloadSK{x} : x is encrypted and authenticated

Standard EAP messages

D-H exchange

Mutual auth.by AUTH

Security Properties Validation Security Properties Validation of EAP-IKEv2 of EAP-IKEv2


1. P <- S: request_id

2. P -> S: respond_id.P

3. P <- S: SA.KEs.Ns

4. P -> S: SA.KEp.Np.[{IDp}_SKp]

5. P <- S: {S.{AUTHs}_inv(Ks)}_SKs

6. P -> S: {P.{AUTHp}_inv(Kp)}_SKp

7. P <- S: success

1. P <- S: request_id

2. P -> S: respond_id.P

3. P <- S: SA.KEs.Ns

4. P -> S: SA.KEp.Np.[{IDp}_SKp]

5. P <- S: {S.{AUTHs}_inv(Ks)}_SKs

6. P -> S: {P.{AUTHp}_inv(Kp)}_SKp

7. P <- S: success

Simplified AVISPA Model of EAP-IKEv2Simplified AVISPA Model of EAP-IKEv2

1. Mutual authentication2. Key establishment3. Confidentiality4. Replay protection

1. Mutual authentication2. Key establishment3. Confidentiality4. Replay protection

Security GoalsSecurity Goals

KEs : exp(G, DHs) AUTHs : SA.KEs.Ns.NpKEp : exp(G, DHp) AUTHp : SA.KEp.Np.Ns SKp : hash(Ns.Np.exp(exp(G,DHs),DHp)SKs : hash(Ns.Np.exp(exp(G,DHp),DHs)

MitM Attack on P2P ModelMitM Attack on P2P Model


ATTACK TRACE (s,10) -> i: request_id i -> (p,3) : request_id (p,3) -> i : respond_id.p i -> (s,10): respond_id.i (s,10) -> i: SA(3).exp(g,DHs(3)).Ns(3) i -> (p,3) : SA(3).exp(g,DHs(3)).Ns(3) (p,3) -> i : SA(3).exp(g,DHp(4)).Np(4) i -> (s,10): SA(3).exp(g,DHp(4)).Np(4) (s,10) -> i: {s.{SA(3).exp(g,DHs(3)).Ns(3).Np(4)}_inv(ks)}

_(f(Ns(3).Np(4).exp(exp(g,DHp(4)),DHs(3)))) i -> (p,3) : {s.{SA(3).exp(g,DHs(3)).Ns(3).Np(4)}_inv(ks)}

_(f(Ns(3).Np(4).exp(exp(g,DHs(3)),DHp(4))))

ATTACK TRACE (s,10) -> i: request_id i -> (p,3) : request_id (p,3) -> i : respond_id.p i -> (s,10): respond_id.i (s,10) -> i: SA(3).exp(g,DHs(3)).Ns(3) i -> (p,3) : SA(3).exp(g,DHs(3)).Ns(3) (p,3) -> i : SA(3).exp(g,DHp(4)).Np(4) i -> (s,10): SA(3).exp(g,DHp(4)).Np(4) (s,10) -> i: {s.{SA(3).exp(g,DHs(3)).Ns(3).Np(4)}_inv(ks)}

_(f(Ns(3).Np(4).exp(exp(g,DHp(4)),DHs(3)))) i -> (p,3) : {s.{SA(3).exp(g,DHs(3)).Ns(3).Np(4)}_inv(ks)}

_(f(Ns(3).Np(4).exp(exp(g,DHs(3)),DHp(4))))

Peer Intruder Server

Replaces “p” with “i” Intruder convinced

P he was talking with S!

Intruder convinced P he was talking

with S!

Fixing the AttacksFixing the Attacks First modification


5. P <- S: hash{MID.SKs}.{S.

{AUTHs}_inv(Ks)}_SKs

6. P -> S: hash{MID.SKp}.{P.

{AUTHp}_inv(Kp)}_SKp

5. P <- S: hash{MID.SKs}.{S.

{AUTHs}_inv(Ks)}_SKs

6. P -> S: hash{MID.SKp}.{P.

{AUTHp}_inv(Kp)}_SKp

Still AVISPA could find the attacks Second modification fixed the attacks

4. P -> S: SA.KEp.Np.{IDp}_SKp % for symmetric key authentication

4. P -> S: SA.KEp.Np.{P}_SKp % for asymmetric key/password

% authentication

4. P -> S: SA.KEp.Np.{IDp}_SKp % for symmetric key authentication

4. P -> S: SA.KEp.Np.{P}_SKp % for asymmetric key/password

% authentication

AVISPA reported the pass-through model attack free

Developed from the P2P model by adding authenticator

between peer and server

Newly added

Specified as mandatory

Sender Access Control: Sender Access Control: Related WorkRelated Work


MethodAAA functions

Authentication

AttacksOver- head

Routing Protocol

Intra or Inter domain

Authen.Stamp

Authentication Authorization

Digital signature

DoS High CBT Both

CHAPAuthentication Authorization

CHAP using password

Dictionary, source address spoof

LowAny protocol

Intra domain

KHIPAuthentication Authorization

Digital signature + encryption

DoS MediumCBT, OCBT

Both

SACL AuthorizationNo explicit method

Replay, source address spoof

MediumAny bidir-ectional

Both

Lack of accounting

Specific authentication

Suffer from common attacks

Dependent on specific protocol

Sender Access ControlSender Access Control


AR1AR1

AR2AR2

AR3AR3

CR1CR1

CR2CR2

CR3CR3Diameter (EAP)

PANA (EAP)

AAA Server

EUs

Sender

IKEv2

IPsec SA

NAS

AAA-Key

IKE-pre-shared-Key

1. Anti-replay2. Prevents

source address

spoofing3. Minimizes

DoS

AAA-Key

PaC-EP-Master-Key

IKE-pre-Shared-Key

Benefits of Sender Benefits of Sender Access ControlAccess Control Provides AAA functionalities Per-packet cryptographic protection Minimum overhead and fast packet processing Independent of routing protocol Serves both ASM and SSM groups Security services by IPsec SA

Anti-replay Prevents source address spoofing Minimizes DoS


Policy Framework: Policy Framework: RequirementsRequirements

Extends the proposed access control architecture Entities of MSEC FW will be present Based on IETF Policy FW, should have

PDP: Policy Decision Point PEP: Policy Enforcement Point Policy repository

Divides policy into Data Control Policy and Access Control Policy

Independent of policy specification language and transport protocol


Policy Framework


AR2AR2AR4AR4

AR1AR1AR3AR3

AAAServer

AAAServer

GC/KSPDP

NAS/PEP

NAS/PEP

NAS/PEP

NAS/PEP

Policy Protocol (SAML)

Policy Repository (XACML)

Policy Management Tool

Group Owner

Sender

ReceiversReceivers

Sender

PDP: Policy Decision PointPEP: Policy Enforcement Point

Inter-domain Communication: Inter-domain Communication: Diameter AgentsDiameter Agents


DRDDRD

DRLDRLNASNAS HMSHMS4. Request

2. Request

6. Answer

5. Answerexample.net example.net example.com

NAS: Network Access ServerDRL: Diameter ReLay AgentDRD: Diameter ReDirect AgentHMS: HoMe AAA Server

1. Request

Network Access Identifier (NAI)

(e.g., [email protected])Network Access Identifier (NAI)

(e.g., [email protected])

3. Redirect Notification

Contains route to

reach example.comContains route to

reach example.com

Performs route lookup in Realm Routing Table

Performs route lookup in Realm Routing Table

No route for HMSNo route for HMS

Inter-domain Receiver Inter-domain Receiver Access ControlAccess Control


AR1AR1

EUs

AR1AR1BR1BR1 BR2BR2MBGP

NW1NW1 NW2NW2

NW3NW3

Participants’ Database

Group Owner

Home AAAS AAA

Redirect Relay

Sender

AAA (EAP)

IGMP-AC (EAP)

AAA (EAP)Sends

NAI of EU

Inter-domain Sender Inter-domain Sender Access ControlAccess Control


AR1AR1MBGP

EUs

AR1AR1BR1BR1 BR2BR2

Participants’ Database

Group Owner

NW1NW1 NW2NW2

NW3NW3

Home AAASAAA

(EAP) AAA

RedirectRelaySender

AAA (EAP)

PANA (EAP)

IKEv2

IPsec SA

Checkpoint at entrance of NW1

CRCR

Data Distribution ControlData Distribution Control


AR1AR1

EUs

AR2AR2

BR1BR1

BR2BR2

NW1NW1

NW2NW2

Sender

EUs

AR3AR3BR3BR3

NW3NW3

MBGP

DRDR

Data Distribution

Multicast SA (MSA)

Checkpoints

Multicast Security Multicast Security Association (MSA)Association (MSA)


MSA SS

R1R1 R2R2 RnRn

GCKSConstructs MSA

MSA provides:• Multicast data integrity • Anti-replay• Prevention of source address spoofing

Get MSA parameters

Transports Transports datadata



AR1AR1

EUs

AR2AR2

BR1BR1

BR2BR2

NW1NW1

NW2NW2

Sender

EUs

AR3AR3BR3BR3

NW3NW3

MBGP

DRDR

SenderSenderReceivers

Centralized MSA



AR1AR1

EUs

AR2AR2

BR1BR1

BR2BR2

NW1NW1

NW2NW2

Sender

EUs

AR3AR3BR3BR3

NW3NW3

MBGPDRDR

Distributed MSA

MSA1

MSA2

MSA3

Sender Sender Receivers

Only BRs and ARs are member

of MSA

Only BRs and ARs are member

of MSA

Receiver of MSA1Sender of MSA2

Establishing the MSA: Establishing the MSA: Extended PIM (S, G) JoinExtended PIM (S, G) Join


S

DRDR

S

DRDR

BR11BR11BR12BR12

AR21 AR23AR22 AR24

MSA MSA1

MSA2 MSA3

11hd

dd

AR22AR21

BR11BR11

AR23 AR24

BR12BR12

PIM (S, G) Join

1hd Cost for a d-ary

height h tree:

Cost for a d-ary height h tree:

Centralized MSA

Distributed MSA

Comparison of PerformanceComparison of Performance


Summary of Two MethodsSummary of Two Methods


Features Centralized MSA Distributed MSAs

Establish-ment cost

High, in worst-case , in best-case .

Low, in best-case , in worst-case .

MaintenanceAll members maintain a single MSA.

Only the root and the leaves maintain a single MSA. Internal nodes maintain two MSAs.

UpdatingLess scalable and flexible. Updates all members if needed.

Scalable and flexible. A small MSA might be updated independently.

Delivery timeLow. BRs need not create IPsec encapsulated packet.

High. BRs have to create IPsec encapsulated packet.

Security features

Less flexible. All routers use same authentication and keys.

Flexible. Individual MSA deploys different authentication and keys.

hdh.dh.

11

hdd

d

dh.

Low for distributed

Low for centralized

Scalable & flexible for distributed

Low forcentralized

Flexible for distributed

Receiver Mobility and Secured Receiver Mobility and Secured Handoff: Related WorkHandoff: Related Work

Aggregating many multiple IGMP messages Advanced joining the DDT Deploying Handoff Agent—proxy for MN and replies IGMP query Allowing MN to go into sleep mode Sending unsolicited join without IGMP query Tuning IGMP query timer


Researchers have concentrated in two issues:

1.Reducing handoff time

2.Optimizing communication between mobile host and IGMP router

Receiver access control and secured handoff are absent!

Researchers have concentrated in two issues:

1.Reducing handoff time

2.Optimizing communication between mobile host and IGMP router

Receiver access control and secured handoff are absent!

Mobile Receiver Access Control Mobile Receiver Access Control and Secured Handoffand Secured Handoff


Domain3Domain3

DRDR

CR1CR1 CR2CR2

NASNAS

IGMP-AC (EAP)

Domain2Domain2

NASNAS

MN (EU)

Domain1Domain1

NASNAS

AAA (EAP)AAA (EAP)

Source

Multicast DDT

LAAAS

HAAAS

MN (EU)Handoff

Routing Protocol Join

MR

MR

MR

MR: Multicast RouterMN: Mobile NodeLAAAS: Local AAASHAAAS: Home AAAS

Multiple ro

und-trips

EAP Re-authentication (ERP)EAP Re-authentication (ERP)


Peer ER Authenticator Local ER Server

EAP-Initiate/Re-auth-Start

EAP-Initiate / Re-authAAA(EAP-Initiate / Re-auth)

AAA(rMSK, EAP-Finish / Re-auth)EAP-Finish / Re-auth)

Single Round-trip from Peer to Local ER Server

Optional message

MN/EU MR/AR Local AAAS

ERP Key HierarchyERP Key Hierarchy


Peer/EU AuthenticatorMR/NAS

Local ER Server EAP Server

DSRKDSRK DSRKDSRKDSRKDSRK

rMSKrMSK

DS-rRKDS-rRK

rMSKrMSK DS-rIKDS-rIK

DS-rRKDS-rRK

DS-rIKDS-rIKrMSKrMSK

MSK : Master Session KeyEMSK : Extended Master Session KeyDSRK : Domain Specific Root KeyDS-rRK: Domain Specific re-authentication Root KeyrMSK : re-authentication Master Session KeyDS-rIK : Domain Specific root Integrity Key

MSKMSK EMSKEMSK MSKMSK EMSKEMSK

Established at the end of EAP session

Mutual authentication

Mobile Receiver Access Mobile Receiver Access Control in Wireless NetworksControl in Wireless Networks


NAS1NAS1

Domain1Domain1

Home Home DomainDomain

Home EAP Server

NAS2NAS2

Local ER Server1

AAA (EAP)

AAA (EAP)

IGMP-AC (EAP)

DSRK1

IGMP-AC (ERP)

AAA (ERP)

NAS3NAS3

Domain2Domain2

NAS4NAS4

Local ER Server2

AAA (ERP)

IGMP-AC (ERP)

IGMP-AC (ERP)

AAA (ERP)

DSRK2

Peer Peer Peer PeerMicro MobilityMicro Mobility Macro MobilityMacro Mobility

ER : EAP Re-authenticationERP: EAP Re-authentication Protocol

Conclusion: Major ContributionsConclusion: Major Contributions

Developing a participant access control architecture A complete access control architecture Provides policy enforcement and acknowledges e-commerce Supports inter-domain multicast groups for the first time

Receiver access control using IGMP-AC Verification using PROMELA/SPIN Validation of EAP-IKEv2 by AVISPA, fixing MitM attack Successfully overcome limitations of previous IGMP extensions

Sender access control Per-packet cryptographic protection Prevents anti-replay, sender address spoofing, minimizes DoS


Conclusion: Major ContributionsConclusion: Major Contributions

Developing access control policy framework Unique FW—both fits with MSEC FW and follows IETF Policy

FW

A novel inter-domain data distribution control Two alternate ways to deploy MSAs: Centralized and Distributed MSA construction methods—explained in depth Compared the two methods

Mobile Multicast Receiver access control by IGMP-AC Secured handoff with low latency


Conclusion: Conclusion: Impacts of Our ResearchImpacts of Our Research Access control is acknowledged as key component to be

solved by IETF MBONED Working Group ITU-T IPTV Focus Group

We have projected Missing components in MBONED framework The additional problems to be addressed

Mobile multicast architecture will open new horizon of wireless networks for IP multicast

Will facilitate the e-commerce researchers with an extendible framework


Conclusion: Future WorkConclusion: Future Work

Complete the development of the protocols Define the packet format Specify timers’ values

Presented our architecture in MBONED Meeting during 69th IETF Meeting, 2007

Actively working on writing Internet Drafts Explaining the IGMP-AC protocol Describing the EAP/ERP encapsulation over IGMP-AC for mobile

multicast

Moreover, inter-domain DDT control for ASM groups Extend mobile multicast architecture for source mobility


PublicationsPublicationsJournal/Magazine Papers1. S. Islam and J.W. Atwood, “Multicast Receiver Access Control by IGMP-AC”, Submitted to Computer Networks.

2. S. Islam and J.W. Atwood, “Sender Access and Data Distribution Control for Inter-domain Multicast Groups”, will be submitted to Computer Networks.

3. S. Islam and J.W. Atwood, “A Novel Inter-domain Access Control Architecture for IP Multicasting”, in preparation.

Conference Papers4. S. Islam and J.W. Atwood, "Receiver Access Control and Secured Handoff in Mobile Multicast using IGMP-AC",

submitted to 33rd IEEE Conference on Local Computer Networks.

5. S. Islam and J.W. Atwood, "Sender Access Control in IP Multicast", in 32nd IEEE Conference on Local Computer Networks, Dublin, Ireland, 2007 October 15-18, pp. 79-86.

6. S. Islam and J.W. Atwood, "A Policy Framework for Multicast Group Control", in IEEE CCNC--Workshop on Peer-to-Peer Multicasting, Las Vegas, NV, 2007 January 11, pp. 1103-1107.

7. S. Islam and J.W. Atwood, "The Internet Group Management Protocol with Access Control (IGMP-AC) ", in 31 st IEEE Conference on Local Computer Networks, Tampa, Florida, U.S.A., 2006 November 14-16, pp. 475-482.

8. S. Islam and J.W. Atwood, "A Framework to Add AAA Functionalities in IP Multicast'', in Advanced International Conference on Telecommunications (AICT'06), Guadeloupe, French Caribbean, 2006 February 19-22.

Internet Drafts9. “Internet Group Management Protocol with Access Control (IGMP-AC)”, in preparation.

10. “Receiver Access Control and Secured Handoff in Mobile Multicast using IGMP-AC”, in preparation.


Project FundingProject Funding

FQRNT Doctoral Research Scholarship

NSERC Discovery Grant (received by Dr. Atwood)

Concordia University Concordia University Graduate Fellowship Concordia University Graduate Entrance Fellowship Campaign for Concordia Graduate Award Concordia University External Award Holder Doctoral

Scholarships


Thank You!Thank You!


Questions?

participant access control in ip multicasting

Documents

arssender access control

receiver access control

unicast access control

ip multicastingaccess

network access serverparticip

ip multicastingmotivation

ip multicastingauthentication

ip multicastingoverview